Linux Foundation Launches Agent Name Service for AI Agent Identity

The Linux Foundation announced on November 10, 2026, that Agent Name Service (ANS) has formally launched as a foundation project, bringing domain-anchored identity, discovery and authentication to AI agents through an open specification and open-source tools.

ANS is designed to let a system establish which registered agent it is dealing with before applying its own security policy. It binds a versioned name to a domain controlled by the agent’s operator, uses the Domain Name System (DNS) to publish discovery information, and records signed lifecycle events in a transparency log. The approach reuses existing internet infrastructure instead of requiring a single proprietary agent registry.

The launch advances the foundation’s June 23, 2026 announcement of intent into a governed project. The foundation says 11 organizations have contributed to or adopted ANS since then: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP and Trustmodel.ai.

How ANS Registration and Authentication Work

The seven-layer specification covers identity, registration, versioned naming, DNS publication, transparency, integrity monitoring and agent authentication. An ANS name binds a version to a domain, as in ans://v1.0.0.payments.example.com; a new version requires a new registration.

During registration, 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 publishes the returned DNS records, and the authority checks them before activation. It then signs the lifecycle event and has the Transparency Log seal it, producing public artifacts that bind the registration to authorized certificates.

Peers use a supported discovery profile to locate endpoints and the shared _ans-badge record to find transparency evidence. Discovery alone does not authenticate the caller. 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 ANS-6 authentication draft gives mutual TLS (mTLS) and application-layer Demonstrating Proof of Possession (DPoP) equal standing. mTLS suits an end-to-end TLS path, while DPoP binds a single-use proof to an HTTP request and can survive gateways that terminate TLS. A badge-tier verifier queries the Transparency Log for current evidence; the SCITT tier verifies a receipt and status token locally without per-request network calls. DPoP requires the SCITT binding.

Software and Early Interoperability

The available software includes a Go reference implementation of the Registration Authority, Transparency Log and offline verifier, plus Go, Rust and Java SDKs with different APIs and feature coverage. The ans-cli tool supports registration, discovery, certificate management and Transparency Log queries on macOS, Linux and Windows. The local quickstart 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.

For interoperability, the Linux Foundation reports that AGNTCY’s Agent Directory Service supports verification of ANS identities and that ANS Finder implements Agentic Resource Discovery (ARD) and passes its registry conformance tests. ARD’s own specification addresses discovery before invocation rather than execution and allows many discovery services with different trust, ranking and access policies instead of prescribing a central catalog. The work connects verifiable identity evidence to discovery without creating a universal agent directory.

Draft Specifications and Security Boundaries

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. It sets technical direction, while repository maintainers review changes, manage releases and handle security reports. Although the launch release describes the specification as formalized, the project documentation labels the published specifications drafts under active development; ANS-6 is marked DRAFT v1.0, version 0.2.0, dated November 3, 2026.

The security model establishes identity rather than permissions. Authorization, delegation across a call chain and trust scoring are outside ANS-6, leaving each application to decide what an authenticated agent may do. Sealed metadata digests do not attest code running on a remote machine or guarantee agent behavior, and clients still need trusted log keys, correct signature and proof verification, freshness checks and a failure policy. Public badges, receipts and status tokens can also be replayed if a verifier omits possession checking.

A receipt proves log history rather than current validity and can continue verifying after an agent is revoked, so it must be paired with a current status check. 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.

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.