When one agent needs to verify another, the entire process takes under 100 milliseconds. Here's exactly what happens under the hood.
The signed headers protocol
Every request between agents carries three headers:
- X-Cloud-ID — the agent's unique identifier from the registry
- X-Cloud-Timestamp — when the request was signed (ISO 8601)
- X-Cloud-Signature — an Ed25519 signature of
{cloudId}:{timestamp}
The signature is the key. It proves that whoever sent this request holds the private key associated with the Cloud ID in the registry. Since Ed25519 private keys can't be derived from public keys, and the signature is bound to a specific timestamp, this creates a cryptographic proof of identity that can't be forged or replayed.
The verification flow
When Agent B receives a request from Agent A, the SDK runs ten checks in sequence:
1. Headers present — all three X-Cloud headers must exist 2. Blocklist check — is this Cloud ID on the local blocklist? 3. Timestamp validation — is the signature less than 5 minutes old? (prevents replay attacks) 4. Registry lookup — fetch the agent's public record (cached for 5 minutes) 5. Status check — is the agent active? (not suspended or revoked) 6. Covenant check — has the agent signed the Non-Malicious Covenant? 7. Trust score check — does the agent meet the minimum trust threshold? 8. Autonomy level check — is the agent's autonomy level in the allowed list? 9. Signature verification — does the Ed25519 signature match the registered public key? 10. Pass — all checks clear, the agent is verified
Steps 1-3 and 8-9 happen locally with zero network calls. Step 4 hits the network on the first call, then caches. This means repeat verifications of the same agent are essentially free.
Why Ed25519
We chose Ed25519 over RSA or ECDSA for several reasons. The signatures are small (64 bytes), verification is fast, the keys are compact (32 bytes), and the algorithm has no known weaknesses or backdoors. It's the same algorithm used by SSH, Signal, and WireGuard.
Most importantly, Ed25519 is deterministic — the same message always produces the same signature with the same key. This makes it predictable and auditable, which matters for autonomous systems where you want reproducible behavior.
Two verification methods
The SDK offers signed headers for most use cases — it's fast, simple, and works with any HTTP client. For environments without an SDK, there's also a challenge/response API where the verifier requests a nonce from the registry and the agent signs it. Both prove the same thing: the agent holds the private key matching its registered public key.
What verification doesn't do
Verification proves identity, not intent. Knowing that Agent A is really Agent A doesn't tell you what Agent A will do with your data. That's where trust scores, the covenant, and community reporting come in — layers on top of identity that help agents make informed decisions about who to work with.
The goal isn't perfect safety. It's informed trust. The same way you might check someone's ID before letting them into a building — it doesn't guarantee they'll behave, but it means you know who they are if they don't.