Linux Foundation Launches Agent Name Service for AI Agent Identity

The Linux Foundation formally launched the Agent Name Service (ANS) as a foundation project on November 10, 2026, bringing domain-anchored identity, discovery and authentication to AI agents through an open specification and open-source tools. The system lets a receiving service establish which registered agent it is dealing with before applying its own security policy. Eleven organizations have contributed to or adopted ANS since the foundation first announced its intent on June 23, 2026: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP and Trustmodel.ai.

The stakes are straightforward. As AI agents increasingly call other agents across organizational boundaries, the internet lacks a standard way to answer a basic question: who is this agent, and can I prove it? ANS attempts to answer that by reusing existing internet infrastructure rather than requiring a single proprietary agent registry. Whether that lightweight approach survives contact with real deployments, where agents are compromised and credentials stolen, remains untested.

How does ANS registration work?

The specification spans seven layers: identity, registration, versioned naming, DNS publication, transparency, integrity monitoring and agent authentication. An ANS name binds a specific version to a domain controlled by the agent's operator, in the form ans://v1.0.0.payments.example.com. A new version requires a new registration, so identity claims do not silently carry forward across updates.

Registration follows a defined sequence. The operator submits the agent host, version, endpoints and certificate material to a Registration Authority, which verifies domain control and the required proofs. The operator then publishes the returned DNS records, and the authority checks them before activation. It signs the lifecycle event and has the Transparency Log seal it, producing public artifacts that bind the registration to authorized certificates.

Peers locate endpoints using a supported discovery profile and find transparency evidence through the shared _ans-badge DNS record. Discovery alone does not authenticate the caller — a distinction the project draws deliberately. Authentication requires three checks: the certificate is bound to the registered identity, the registration remains valid, and the caller holds the corresponding private key. The takeaway: ANS treats discovery and proof of identity as separate problems, and conflating them is a verifier's error, not the protocol's.

What does the ANS-6 authentication draft specify?

The ANS-6 authentication draft gives two mechanisms equal standing: mutual TLS (mTLS, a protocol where both sides of a connection present certificates) and application-layer Demonstrating Proof of Possession (DPoP, which binds a single-use cryptographic proof to an HTTP request). mTLS suits an end-to-end TLS path, while DPoP can survive gateways that terminate TLS — a common reality in enterprise networks.

Verification comes in two tiers. A badge-tier verifier queries the Transparency Log for current evidence. A SCITT tier (Supply Chain Integrity, Transparency and Trust, an IETF-style framework for verifiable receipts) verifies a receipt and status token locally without per-request network calls. DPoP requires the SCITT binding.

The draft status deserves attention. The launch release describes the specification as formalized, but the project documentation labels the published specifications as drafts under active development. ANS-6 is marked DRAFT v1.0, version 0.2.0, dated November 3, 2026 — one week before the launch announcement. The gap between launch language and document labels is worth monitoring for anyone planning production adoption.

What software is available, and what does it prove?

The released software includes:

• A Go reference implementation of the Registration Authority, Transparency Log and offline verifier
• Go, Rust and Java SDKs, with differing APIs and feature coverage
• The ans-cli tool, supporting registration, discovery, certificate management and Transparency Log queries on macOS, Linux and Windows

The local quickstart carries an explicit limitation. It uses development keys and a noop DNS verifier, meaning a passing receipt check does not test public DNS, production certificate issuance or a live deployment. Developers who run the quickstart and see green checks have not, in fact, validated anything close to a production path.

What interoperability exists so far?

The Linux Foundation reports two concrete interoperability points. AGNTCY's Agent Directory Service supports verification of ANS identities, and ANS Finder implements Agentic Resource Discovery (ARD) and passes that registry's conformance tests. ARD's own specification addresses discovery before invocation rather than execution, and it allows many discovery services with different trust, ranking and access policies instead of prescribing a central catalog. The design connects verifiable identity evidence to discovery without creating a universal agent directory — a deliberate architectural choice, and one that leaves ranking and trust judgments fragmented by design.

Who governs the project?

The initial technical steering committee has five voting members: Scott Courtney, Keith Perry and Connor Snitker of GoDaddy, Ken Huang of DistributedApps.AI, and Michael Kantor of Hashgraph Online. The committee sets technical direction, while repository maintainers review changes, manage releases and handle security reports. GoDaddy holding three of five voting seats gives the domain-registrar industry outsized influence over the specification's direction — unsurprising given ANS's dependence on DNS, but a concentration worth noting.

What does ANS not protect against?

The security model establishes identity, not permissions. Authorization, delegation across a call chain and trust scoring are all outside ANS-6, leaving each application to decide what an authenticated agent may do. A verified identity is not a verified actor: sealed metadata digests do not attest the code running on a remote machine or guarantee agent behavior.

Clients still carry operational obligations: trusted log keys, correct signature and proof verification, freshness checks and a failure policy. Public badges, receipts and status tokens can be replayed if a verifier omits possession checking. A receipt proves log history rather than current validity, and it can continue verifying after an agent is revoked — so it must be paired with a current status check. Skip that pairing, and a revoked agent keeps passing.

Integration maturity also varies. The NVIDIA OpenShell work is labeled a research preview, and its destination-registration checks do not implement ANS-6 binding to the actual TLS peer certificate. In plain words: an early integration already diverges from the authentication binding the specification requires.

What happens next?

ANS now has foundation governance, published drafts and reference implementations. Its practical security value depends on deployments enforcing identity, current status and key possession together, while keeping authorization and judgments about agent behavior outside the identity claim. Until implementations prove they can enforce all three simultaneously, ANS remains a well-specified promise rather than a tested guarantee.