GoDaddy Don’t Trust. Verify. Offline, Sub-Millisecond Agent Verification with ANS

[godaddygodaddy is verified member.]

• ANS verifies an agent’s identity offline in well under a millisecond, in both directions, before anything sensitive is sent.
• Identity, proof of possession, and authorization are three separate questions, answered by ANS, by mTLS or DPoP, and by OAuth 2.0, with only two extra headers on ordinary HTTPS.
• A short-lived status token means revoking an agent version takes effect within one TTL, an hour by default, instead of whenever a certificate happens to expire.

How easily can you identify your agents inside your organization or at your edge? Can you name every agent authorized to call your systems or get in the front door today? Can you prove that list to an auditor? An identity is useless if you can’t verify it. That’s one of the reasons we built Agent Name Service (ANS). Don’t trust. Verify your agents with cryptography.

In past blog posts, we have talked about ANS and how an identity is issued, what it was built on, and how it was built using a one-system approach. ANS was born from an OWASP GenAI Security Project paper and an IETF draft. This wasn’t an idea from GoDaddy. We liked the ideas presented so much that we created a proof of concept. Based on our learnings from the proof of concept, our VP Scott Courtney, co-authored v2 of the ANS IETF draft with the original authors. Then, we iterated on the original proof of concept and implemented those ideas. Since the IETF v2 draft, we created open source reference implementations and announced our intent to submit the open source Agent Name Service organization and repositories to the Linux Foundation.

Software and websites were built with people in the loop, and that slows things down. With agents running autonomously, for hours at a time, they can perform millions of actions. The game has changed with AI agents. We need to start building for the now. ANS allows you to gate identity at the door. With ANS and the associated SDKs, we provide many different ways to verify an agent’s identity. The ANS identity verification complements other authorization frameworks like OAuth 2.0.

When registering with ANS, your agent gains:

• A unique identity name that is versioned (for example: ans://v1.0.0.mysuperagent.example.com).
• Discoverability by DNS and via search across the entire ANS registry.
• An identity (client) certificate that is also tied to the registered version and ANS name. ANS uses a dual-certificate model, but you can bring your own server certificate.
• A transparency log badge that is open to the public so other users can see that you’re registered and are still in good standing.
• A way for your agents to get verified by ANS verifiers, and a way for other agents to verify yours, which is what the rest of this post is about.

Step zero: don’t hand over your credentials to just anyone​

Reader question: Before your agent hands over credentials, how are you verifying the thing on the other end?

You’re at home on a Sunday when suddenly you get an urgent text from your credit card company explaining there was fraud on your account. They need the code coming in the next text to help you solve it. What do you do? Ideally, you call your credit card company directly using the number on the back of your card and report this fraud. Before sending your sensitive “code” to an untrusted entity, you verify with the real credit card company.

ANS offers a similar avenue for agents to check the callee before handing over credentials. Many times before making an authenticated call, users would inspect the agent card or MCP tool list. An ANS-registered server can return its receipt and status token in the response headers, so the client can verify before sending anything sensitive.

Don’t connect and pray. Verify, then connect!

The client can run three checks first. Let’s use the credit card verification example to illustrate the three checks ANS uses:

• Check 1 (Real identity) – Is this a real bank? The client can validate that the server has a real identity by verifying the Supply Chain Integrity, Transparency, and Trust (SCITT) receipt. Proof that the agent’s identity was registered in ANS. It is cryptographically bound to the ANS transparency log. The log is append-only and its checkpoints are public. An operator like GoDaddy can’t rewrite history or hand one vendor a different story than another without it showing up to anyone comparing checkpoints. If a receipt itself was altered, the signature fails and anyone verifying it would see that. And before any of this, the registry ran an ACME challenge at registration to prove you control the domain.
• Check 2 (Good standing) – In the analogy, is the bank in good standing? In ANS, this is the ANS Status Token. How recent is this status token? Is it expired? Has it been revoked in the last hour? In ANS, you can revoke a single agent by version.
• Check 3 (Right channel) – Is this really the bank’s phone line? You know it is because you used the number on the back of the card. Does the TLS certificate on the actual server match what is in the transparency log that was sealed at registration?

Verification usually starts on the server side once the credentials have already left the client’s hands. The web already ran a similar experiment. Email never verified the sender and that burden fell on humans. What if you could verify the server before you sent any credentials along? If the server had been revoked or went rogue since the last time you called it, you would want to know. One of the cool things in ANS, is that this can be done by the client even if the client isn’t registered in ANS.

The following illustration shows the three checks the client runs before sending credentials:

The response the venue returns looks like this:

HTTP/1.1 200 OK # the agent card, proof attached

X-SCITT-Receipt: <the venue's registration> # check 1: really them
X-ANS-Status-Token: <the venue's status token> # check 2: in good standing
# check 3 rides on TLS itself: the certificate presented must match the registration

Four stops, three layers​

Reader question: You know the request is authorized. Do you know which agent made it?

You head to the airport for travel to another country, and after checking your bags, you head to the airport security line. The security agent is going to check your passport to see if it is real (Checkpoint 1), and then they also check to make sure it is not expired or revoked, and still in good standing (Checkpoint 2). Next, they ask you to stand in front of the camera to take a picture. Here they are making sure that this passport document matches the real face of the person standing in front of them (Checkpoint 3). Next, you take your boarding pass to the gate. They will make sure you have a valid boarding pass and that boarding pass is for the correct flight (Boarding Gate).

On the server side, verifying an incoming agent’s request looks like this. Let’s use the airport security example to illustrate the checks ANS uses:

• Checkpoint 1 – Who does this passport belong to? The SCITT Receipt is the passport in this analogy, cryptographically tied to the transparency log as mentioned above.
• Checkpoint 2 – Is this passport in good standing? The Status Token answers that: is the agent identity expired, revoked, or still valid? This is different from an OAuth token. It’s the agent’s identity in good standing.
• Checkpoint 3 – Does this real person in front of me match this document? Demonstrating Proof of Possession (DPoP) or Mutual Transport Layer Security (mTLS) answers that in ANS by proving possession of the key. This is the bridge that links the identity with OAuth 2.0.
• Boarding Gate – Do you have a real, valid token (unexpired, right audience) and authorization to access this particular resource? OAuth 2.0 handles that layer. ANS already settled which agent is asking; the token says what that agent may do and, when it’s acting for a person, on whose behalf.

The following table illustrates what this looks like:

Layer	Stops	Question	Mechanism
Identity	Checkpoints 1–2	Who is this agent? Is it registered, current, and anchored to a domain?	ANS: the SCITT receipt and the status token. This is the piece that was missing.
Proof of possession	Checkpoint 3	Does the caller hold the key that goes with that identity? This is the bridge between identity and OAuth.	An mTLS handshake or a DPoP proof. Both are existing standards. ANS just binds its identity to them.
Authorization	Boarding Gate	May it do this, here, now?	OAuth 2.0 token and scope

The following illustration shows the four stops ANS makes to verify an incoming request:

What’s actually on the wire​

What does this actually look like once it’s on the wire? The following raw HTTP illustrates both scenarios: direct connection and through an intermediary:

# Direct connection — possession is the mTLS handshake which uses the identity cert issued by ANS
POST /a2a/task HTTP/1.1
X-SCITT-Receipt: <inclusion proof> # identity (ANS)
X-ANS-Status-Token: <TTL status token> # standing (ANS)
Authorization: Bearer <access token> # permission (OAuth 2.0, cert-bound)

# Through gateways and load balancers — possession travels with the request
POST /a2a/task HTTP/1.1
X-SCITT-Receipt: <inclusion proof> # identity (ANS)
X-ANS-Status-Token: <TTL status token> # standing (ANS)
DPoP: <per-request signature> # possession (RFC 9449) - signed by ANS Identity Key
Authorization: DPoP <access token> # permission (OAuth 2.0, key-bound)

Together, these headers carry two ANS-specific fields (the SCITT receipt and status token) plus a possession proof and standard OAuth Authorization header, all sent over normal HTTPS. The DPoP header is an IETF OAuth standard, not an ANS header. ANS composes with these existing standards.

The following table describes what each header is and where it’s defined:

Header	What it is	Spec
X-SCITT-Receipt	Signed proof of inclusion in the transparency log	COSE Receipts, RFC 9942 (the SCITT architecture is RFC 9943)
X-ANS-Status-Token	Expiring signed good-standing statement listing the agent’s currently valid certificates	Agent Name Service organization
DPoP	Per-request signature proving control of a private key	RFC 9449
mTLS binding	Access token bound to the client certificate	RFC 8705

All of this can be verified offline against published root keys: no callback, no central service to fall over, no per-request dependency on us.

Note: Each agent refreshes its own status token from the transparency log in the background, well inside the TTL. That goes for the server in step zero as much as the caller here. The verifier never calls anyone.

Where each request stops​

The following image illustrates seven scenarios. How are your agents stacking up to these checks?

What verification actually costs​

We measured this across benchmarks in Go and Rust. We ran both benchmarks on one 16-vCPU (Intel) RHEL 9 virtual machine using the distribution’s toolchains (Go 1.26.7, Rust 1.92), sequentially, never concurrently. Go benchmarks ran one per process, ten samples of five seconds each, medians. Rust ran under the opt-in fast-verify feature, which routes signature verification through ring. The following table shows the results:

Benchmark	Signatures	Go	Rust ring
raw ECDSA P-256 verify	1	102.4 µs	77.8 µs
SignProof — caller mints a DPoP proof	1 (sign)	65.3 µs	66.3 µs
VerifyStatusToken	1	126.6 µs	85.9 µs
VerifyReceipt (2²⁰-entry log)	1 + Merkle walk	147.5 µs	92.3 µs
VerifyProof (DPoP)	1	138.8 µs	109.0 µs
VerifyCaller — all three	3	422.0 µs	292.5 µs
VerifyCaller, no receipt	2	281.1 µs	196.0 µs
VerifyCaller, all 16 vCPUs (wall time per request)	3	39.1 µs	30.6 µs

Note: In a real world scenario, servers would need to fetch the root keys from the transparency log once at startup. Since this is not on the per-request path, this was not included in the measurements.

Conclusion​

Agent Name Service is a security framework that lets you register, discover, and verify agents. It composes with what you already run. Every request carries proof that answers three separate questions. The SCITT receipt and status token answer the identity question: who is this agent and is it still in good standing? These are the two pieces that didn’t exist before. An mTLS handshake or a DPoP proof answers the proof of possession question: does the caller actually hold the key ANS issued? This stops copied receipts and tokens from passing verification. OAuth 2.0 answers the authorization question: what the agent may do and, when it acts for a person, on whose behalf?

None of it calls home. The checks verify offline against published root keys, and all three cost under half a millisecond on a single server core. Because the status token expires on a short TTL, revoking an agent version takes effect within the hour rather than at certificate expiry. The caller can run the same checks against the venue before it sends anything sensitive. Naming, in ANS, is more than a label. It is something you can verify cryptographically.

We can’t do this alone. Let’s build the agentic internet together. Come help us build it! Open Issues, Create PRs, Review the Specs!

Resources​

• Agent Name Service Organization on GitHub
  • ANS Reference Implementation
  • CLI and Go SDK
  • Rust SDK
  • Java SDK
  • Agent Trust Discovery – Search for ANS Reference Implementation
• RFC 9943, An Architecture for Trustworthy and Transparent Digital Supply Chains: the SCITT architecture the receipt follows.
• RFC 9942, COSE Receipts: the receipt format itself.
• RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• RFC 6749, The OAuth 2.0 Authorization Framework
• RFC 8555, Automatic Certificate Management Environment (ACME): how domain control is proven at registration.
• Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity: the IETF draft.
• Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability: the OWASP GenAI Security Project paper ANS grew out of.

The post Don’t Trust. Verify. Offline, Sub-Millisecond Agent Verification with ANS appeared first on GoDaddy Blog.

Continue reading...