AI agents are gaining autonomy without gaining identity.
On November 10, 2026, the Linux Foundation announced the formal launch of Agent Name Service (ANS) as a foundation project. ANS brings domain-anchored identity, discovery, and authentication to AI agents through an open specification and open-source tools—an attempt to replace vague assurances with something systems can verify.
The project 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.
What ANS actually establishes
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.
That design reuses existing internet infrastructure instead of requiring a single proprietary agent registry. A domain offers an anchor, the version identifies a specific release, and the transparency record creates an auditable history of changes. The basic idea is refreshingly unglamorous: before trusting an agent, identify it.
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, and a new version requires a new registration—because “the same agent” is not a useful security claim when its software has changed.
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, the authority checks those records before activation, and the authority signs the lifecycle event.
The Transparency Log seals that event. 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, so locating an endpoint is only the beginning of the security process.
Authentication, software, and the trust gap
Authentication requires three checks: the certificate must be bound to the registered identity, the registration must remain valid, and the caller must hold 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. DPoP binds a single-use proof to an HTTP request and can survive gateways that terminate TLS, giving deployments a route around a common problem in modern application networks.
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, although DPoP requires the SCITT binding. In other words, ANS offers both a network lookup model and a locally checked evidence model.
The available software includes a Go reference implementation of the Registration Authority, Transparency Log, and offline verifier. Go, Rust, and Java SDKs provide different APIs and feature coverage, while 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. A passing receipt check does not test public DNS, production certificate issuance, or a live deployment—because a tutorial environment is not a production environment, despite the number of demos that would like to disagree.
The need for this machinery is visible in the surrounding security data. Arkose Labs’ State of Agentic AI Trust Report for Q3 2026 classified 77.4% of AI agent sessions as legitimate and 7.9% as known bot sessions, while 97.7% carried no verified disclosure of what the agent was or whom it represented.
An earlier Arkose survey of 300 enterprise leaders, conducted in February, found that 97% expected a material AI-agent-driven security or fraud incident within 12 months. The survey also found that 6% of security budgets go to AI-agent risk, only 26% of respondents were very confident they could prove an agent caused an incident, and 68% could not reliably tell agent activity from human activity in logs.
That gap is the territory ANS is targeting. It does not decide what an agent may access, nor does it replace an organization’s security policy; it gives that policy a verified identity to evaluate before access is granted.
Whether ANS becomes common infrastructure will depend on adoption and interoperability. For now, the Linux Foundation has supplied a governed specification, open tooling, and a practical answer to a question the agent boom keeps postponing: who, exactly, is acting?
Based on
- Linux Foundation Launches Agent Name Service for AI Agent Identity — unite.ai
- Why Certified AI Agents Still Get Turned Away — forbes.com
- AI Agents Are Moving Faster Than Trust: Why Security Needs A New Foundation — forbes.com
- When an AI agent acts on its own, sho answers for it? | VentureBeat — venturebeat.com
- Can We Trust AI Agents When Zero Trust Isn’t Really Zero — spectrum.ieee.org
