Agent Name Service Ships: DNS Is Now Your Agent's Passport

Last Updated: November 12, 2026

What Actually Shipped on November 10

The Linux Foundation moved ANS from intent to a governed project at KubeCon + CloudNativeCon North America. The announcement describes a complete specification in seven documents covering domain-anchored naming, registration and versioning, DNS publication, public log auditing, integrity monitoring and agent-to-agent authentication, now under a technical steering committee.

Concretely: an ANS name looks like ans://v1.0.0.payments.example.com, and the version is part of the identity — a new version is a new registration, not a mutation of an existing one. That single design decision kills a whole class of silent-swap attacks where an agent keeps its name and changes its behaviour. The operator proves domain control to a Registration Authority, publishes the DNS records the RA returns, and the RA signs a lifecycle event that a Transparency Log seals before activation succeeds.

On the verifying side, ANS resolves to three proofs: identity (is this certificate bound to this agent in the log), current status (is the registration still valid, with bounded freshness), and possession (does this peer actually hold the private key). ANS-6 defines two caller authentication methods with equal standing — mutual TLS, where the caller presents its ANS Identity Certificate in the handshake, and application-layer DPoP, a signed single-use proof bound to the request method, URL and content that can pass through gateways that terminate TLS. Remember that second one; it is the difference between ANS being implementable on your stack and not.

The Inbound Half Nobody Is Writing About

Every write-up this week framed ANS as outbound credentialing: register your agents, publish your records, get discovered. That is the easy half, and it is the half that benefits the vendors who shipped it. The half that actually hurts is inbound.

Your n8n webhook endpoints, your support inbox, your partner APIs and your public MCP servers are already being hit by autonomous software you cannot attribute to any legal entity. The current attribution stack is a user-agent string that anyone can forge, an IP range that anyone can rent, and a shared bearer token that proves only that the caller possesses the token — not who is running the process that holds it. When a token leaks into a prompt, a log line or a forked workflow template, your authentication model has silently become "whoever found it".

ANS is the first widely-backed mechanism that binds a calling agent to a domain, and therefore to someone who passed a CA's validation and pays a registrar. DigiCert's Brian Trzupek framed it the way buyers will hear it:

Think of it as a passport for AI agents, which is a concept ANS helps advance across platforms and organizational boundaries by bringing together DNS and certificate-based identity.

— Brian Trzupek, SVP Product Management, DigiCert, Linux Foundation

Be precise about what a passport proves. Domain control is not legal-entity verification. Anyone can register a domain in twenty minutes. ANS supports optional Verified Identities, and the June announcement notes the framework accommodates decentralized identifiers and Legal Entity Identifiers — but those are opt-in profiles your Registration Authority has to support, not the default. A bare ANS verification tells you the caller controls a domain and holds a key bound to that domain in a public log. For abuse response that is enormously more than you have today. For KYC it is not enough on its own.

Which Seams in Your Stack Can Enforce an ANS Check Today

An identity standard is only as real as the place in your request path where a failed check returns a 403. The ANS project is unusually blunt about this: a framework can call an SDK or a gateway verifier, but an integration must enforce the verification result in the request path, and adding a verification tool to an agent's tool list does not guarantee it gets used. That one sentence invalidates most of the "we added ANS support" announcements you will see over the next six months.

The published discovery profiles give you something to look at right now. The default V2 registration model uses ANS_DNSAID, an SVCB record at the agent host, with ANS_TXT at _ans.<agentHost> as an explicit opt-in, a required badge record at _ans-badge.<agentHost>, and an optional DANE TLSA record — where a DNSSEC-authenticated mismatch must not be accepted.

# Does this vendor publish anything resolvable at all?
dig +short agents.vendor.example SVCB
dig +short _ans.agents.vendor.example TXT
dig +short _ans-badge.agents.vendor.example TXT

# Run the reference RA and Transparency Log locally before you trust anyone else's
git clone https://github.com/agentnameservice/ans

Run that against the agent vendors in your stack this week. The answers will be empty, and that emptiness is the honest baseline for every adoption conversation you are about to have. If you are mapping where verification gates belong across an existing integration estate, that inventory is the same exercise we run at the start of any integration engagement: enumerate the ingress points, then ask which ones can actually return a 403.

ANS Does Nothing for the Agents Inside Your Own Tenant

This is the question technical buyers are actually asking: we just signed an agent-identity renewal, did we buy the wrong thing? No. You bought a different thing.

The consolidation wave this month maps cleanly onto the second and third questions. Clutch Security, the startup Palo Alto Networks is reported to be in talks to acquire for roughly $500 million, builds software to map non-human identities — API keys, service accounts, tokens and passwords — and find excessive or exposed permissions. That is question two, and no DNS record will ever answer it, because the agents in question hold your credentials inside your perimeter where domain anchoring is meaningless.

Question three went to CrowdStrike, which signed a definitive agreement to acquire Fiddler AI on 3 November 2026, with the capability shipping as Falcon Observe and general availability stated for Q4 FY27. The framing in that release is the one that should shape your architecture: an agent can hold valid credentials and approved tools and still make unsupported decisions or claim work it never completed. Identity verification does not catch that. Nothing in ANS catches that.

So the stack is three layers deep and no single vendor covers it. If you already own non-human identity tooling, ANS is additive at your edge, not a replacement anywhere. If you own neither, start with the one that governs your own blast radius — the agent with your database credentials is a bigger problem than the unattributed one knocking on your webhook. Our build write-ups consistently hit the internal layer first for exactly that reason.

Eleven Supporters Is a Supply Side, Not Coverage

Read the list of eleven: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP and Trustmodel.ai. That is a registrar, two DNS infrastructure companies, a certificate authority, a CDN, a standards body, the original spec authors, a trust-scoring startup, and two enterprise platforms. It is a near-complete coalition of the people who would issue and resolve agent identities.

It is not a list of the companies whose agents are hitting your endpoints. The frontier model labs whose assistants generate most third-party agent traffic are not among the eleven named supporters. Until the organisations operating the agents publish records, a verifier at your edge has nothing to verify, and "reject unverified callers" is a policy that rejects everything.

There is real early signal on the resolution side. The AGNTCY Agent Directory Service, itself a Linux Foundation project, supports verification of ANS identities, and ANS Finder implements the Agentic Resource Discovery specification and passes its registry conformance tests. Salesforce says it is aligning Agent Fabric to the standard. That is genuine interoperability work, not a logo slide. But the ANS project itself labels the published specifications drafts under active development, and one of the listed integrations — the NVIDIA OpenShell research preview — does not implement ANS-6 binding to the actual TLS peer certificate. Read the security notes on every integration before you treat it as a control.

What to Actually Do This Quarter

Nothing about ANS requires an emergency. Everything about it rewards being early in two cheap places: contracts and logging.

One: add the clause. Procurement language costs nothing and compounds. It is the only lever that creates demand-side pressure before runtime coverage exists.

Agent Identity. Where Supplier operates autonomous or semi-autonomous
software agents that initiate requests to Customer systems, Supplier
shall, within 90 days of such capability becoming available from its
infrastructure providers, publish and maintain an Agent Name Service
(ANS) identity anchored to a domain Supplier controls, and shall present
that identity on each such request using an ANS-6 caller authentication
method. Supplier shall notify Customer within 2 business days of any
revocation, deprecation or version change of a registered agent identity.
Until ANS identities are presented, Supplier shall provide and keep
current the source IP ranges and user-agent strings used by its agents.

Two: log the absence. Add a field to your ingress logs for the ANS identity presented, defaulting to null. Do not act on it. In three months you will have the only honest adoption curve anyone has, measured on your own traffic rather than on press releases, and you will know when enforcement stops being self-harm.

Three: run the reference implementation locally. The Go reference Registration Authority and Transparency Log include local demos and an offline verifier, with SDKs in Go, Rust and Java. An afternoon spent registering a fake agent and verifying its badge teaches you more about the failure modes — clock skew on status tokens, stale DNS caches, what happens when a transparency log is unreachable mid-request — than any spec reading.

The underlying judgement call is the one worth stating plainly: ANS is the right shape for the problem and it is not yet a control you can rely on. Domain anchoring is the correct primitive, the version-as-identity model is good design, and putting it under neutral governance alongside MCP removes the obvious capture risk. But a verification layer with no one to verify is infrastructure, not security. Treat the next two quarters as instrumentation and paperwork. If you are deciding where agent-identity work sits against everything else on your automation roadmap, talk it through before you buy another tool for it.