Linux Foundation Agent Name Service: How DNS-Anchored AI Agent Identity Works and When to Adopt It

The Linux Foundation Agent Name Service (ANS) is an open standard that gives AI agents versioned, DNS-anchored names, identity certificates issued after domain validation, and public transparency-log records. Why should an IT leader care? AI agents now call other agents, request data and trigger transactions across organizational boundaries. Nobody can say yet whether ANS becomes the dominant scheme.

What is the Agent Name Service and why is it at the Linux Foundation?

On November 10, 2026, the Linux Foundation welcomed the Agent Name Service as an open standard for trusted identity, verification and discovery of AI agents using existing DNS infrastructure. The full specification runs to seven documents covering domain-anchored naming, registration and versioning, DNS publication, public log auditing, integrity monitoring, and agent-to-agent authentication. The project's technical steering committee now develops it in the open.

Since the intent to launch was announced in June 2026, 11 organizations have contributed to or adopted the standard, including Cisco, Cloudflare, DigiCert, GoDaddy, Infoblox, Salesforce and OWASP.

ANS began at GoDaddy. The team chose to build agent discovery on DNS, which GoDaddy says handles more than one hundred million requests each second, and to establish trust through the same PKI that secures every HTTPS connection. The build reuses GoDaddy's DNS infrastructure and a certificate service handling more than 100 million active SSL and TLS certificates.

For enterprise buyers, the governance move is the part that counts. A public specification under a neutral foundation gives you firmer ground for writing policy. Linux Foundation CEO Jim Zemlin put it plainly: autonomous AI agents are transacting across global systems, but they cannot succeed without verifiable identity.

Why AI agent identity has become an IT governance problem

You can already see the pressure inside organizations. A Cloud Security Alliance survey of 418 IT and security professionals, commissioned by Token Security and published in April 2026, found that 82% of organizations had discovered AI agents running in their infrastructure that nobody knew about. The same survey found that 65% had experienced an agent-related security incident in the previous 12 months. Among the organizations that had such an incident, 61% reported data exposure and 35% reported financial losses. Those two figures are shares of the 65% with an incident, not shares of all respondents.

Read the survey with two caveats in mind. A vendor commissioned it, and it measures internal visibility more than external identity. It still shows that agent sprawl is a current operational problem, not a hypothetical one.

The external side is easiest to picture through the scenario in the IETF ANS v2 draft. A company's payment agent receives an instruction to wire $50,000 to a supplier's invoicing agent, and the invoicing agent presents a website URL secured by a TLS certificate. That certificate tells the payment agent that someone controls the domain. For a system about to send money on its own, domain control is thin evidence.

How ANS works: versioned names, validated certificates and transparency logs

ANS takes mechanisms that anyone running web infrastructure already knows and adds verification tiers on top.

Versioned ans:// names

Every agent gets a versioned, DNS-style name such as ans://v1.0.0.my-agent.example.com. Read it right to left. The domain (example.com) ties the agent to an organization, the label (my-agent) identifies the agent, and the prefix (v1.0.0) pins a semantic version. A plain URL has nothing like that last part. With ANS, a change to the agent can show up as a change to its name.

The ANS v2 draft caps the complete ANSName at 400 octets, which leaves headroom for safe transport across HTTP headers, TLS fields and database columns. Your existing systems can store and pass these names without special handling.

Identity certificates after DNS/ACME validation

An ANS identity certificate is issued only after DNS/ACME domain validation. Operationally, nothing here is new. The catch, which we return to in the caveats, is that an agent's identity can be no stronger than the domain control beneath it.

Public transparency log

Each registration also produces a public transparency-log record, so any party can independently verify an agent's identity, capabilities and history without trusting a middleman.

Bronze, Silver and Gold verification tiers

The ANS v2 draft defines three verification tiers, Bronze (PKI), Silver (PKI plus DANE) and Gold (PKI plus DANE plus transparency log), so clients can choose assurance levels appropriate to transaction risk. DANE binds certificate information to DNS records and relies on DNSSEC. Keep that dependency in mind; it comes back later.

The right-hand column is our recommendation and is not part of the specification. Set your own thresholds.

How ANS relates to DNS-AID and AGNTCY Directory

ANS is not the only DNS-based agent project at the Linux Foundation. DNS-AID, a separate project for decentralized agent discovery, launched with initial members Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Infoblox, Internet Systems Consortium and WWT.

The two projects answer different questions. The DNS-AID draft states that consumers must treat DNS-AID records as a verifiable transport for metadata, not as a trust signal in their own right, and that trust judgments must be made out of band by combining those records with reputation, attestation or organizational policy systems. ANS is one candidate for that identity layer. It sits alongside DNS-AID; it does not replace it.

The AGNTCY Directory project shows why ANS is drawing interest. An open epic in that project tracks verifying ans:// identity claims, noting that every other scheme needs the publisher to host key material such as a JWKS file, a TXT record or a DID document, and almost nobody does, so nothing verifies. An ANS registration already produces an identity certificate, a DNS pointer and a transparency log entry. In other words, the evidence exists by default instead of depending on publishers doing extra work.

The field is still crowded. In June 2026, The New Stack counted at least four DNS-based efforts, including DNS-AID from Infoblox, and Infoblox now backs ANS as well. A competing proposal, DNSid, is one author's individual Internet-Draft with no working-group adoption, and its current version expires December 31, 2026.

When to register your own agents: the Optijara Anchor-Version-Tier ladder

The name describes the sequence. Anchor each agent to a domain you will keep, version it in step with your releases, and give each use case a verification tier. Each rung depends on the one below, so the order matters. This is a planning framework, not a report of client outcomes.

1. Inventory and classify. List every agent you run and tag it as internal only, partner-facing, public, or transactional. Given how many organizations find agents they did not know about, expect surprises here.
2. Start with external and high-stakes agents. Register first the agents that other organizations' agents call, along with anything touching payments, data sharing or contractual actions. Internal-only agents can wait, since your existing identity and access controls already cover them.
3. Anchor: pick the domain on purpose. Use a brand domain you will hold for years, not a campaign domain. Treat a lapsed brand domain as a security event, because the registration authority revokes registrations when domain validation fails.
4. Version: map names to releases. Tie the semantic version in each ans:// name to your release process. Any material change to prompts, tools, models or permissions should produce a new version and a new log entry.
5. Pilot outside production. Run registration and verification in a test environment first, and read the maturity caveat below before any production trust decision depends on ANS.
6. Tier: set assurance levels and owners. Decide the target tier for each use case and name owners for certificate renewal, DNS records and transparency log monitoring. Make those same people responsible for the secrets each agent holds. Knowing who an agent is does nothing to limit what it can access, and patterns such as a credential proxy that keeps API keys out of AI agents handle that separate layer.

Using ANS identities in procurement and runtime allow-lists

In procurement

ANS gives procurement teams a concrete vocabulary for agent identity. Questions worth putting to vendors:

• Do your agents have ans:// names, and which domain anchors them?
• Which verification tier can you support today: Bronze, Silver or Gold?
• Is the anchoring zone DNSSEC-signed, so that DANE checks mean something?
• How do agent versions map to your product releases and change logs?
• Who in your organization owns domain renewal and registrar access?

Contracts should require advance notice before agent version changes that alter capabilities, and before any change of anchoring domain or registrar. Those are the events that change what you actually approved.

A vendor decision matrix

To sort vendor answers, we use a simple matrix built on three signals. Like the tier mapping, it is our view and not part of the specification.

A vendor in the first column on all three signals is a candidate for payment or regulated data flows. Any answer in the right-hand column should keep that vendor's agents on low-risk, Bronze-level interactions until it changes. Mixed answers usually point to a pilot with clear exit criteria.

At runtime

At runtime, the Tier rung becomes an enforcement rule. Allow-list agents by their full versioned ANSName plus certificate checks, never by URL or domain alone. If you ignore the version, a materially changed agent inherits approval you gave an older one. Require Gold, including the transparency log check, for high-risk actions such as payments, and accept Bronze only for low-risk lookups. That follows the draft's own intent that clients match assurance to transaction risk.

Gold verification will not stop a correctly identified agent that starts misbehaving. Pair your Gold requirements with a tested way to halt an agent quickly, and review what an AI kill switch stops and what your agent runbook still needs.

Combine ANS checks with your own policy and reputation controls. The out-of-band principle from the DNS-AID draft applies here too: identity evidence feeds a decision, it is not the decision. Monitor transparency logs for unexpected registrations under your own domains, and watch for registrations on domains that resemble yours, since whoever holds a lookalike domain can register a fully verified agent on it.

If your concern is AI assistants reaching your own web properties, not agent-to-agent calls, you need a different set of controls; see our guide to allowing, limiting or blocking AI assistants on your site.

Caveats and criticisms to weigh before you commit

Inherited DNS trust

The Cloud Security Alliance analysis identifies DNSSEC as the dependency ANS leans on most heavily to make name-to-key bindings tamper-evident. Two decades after its introduction, DNSSEC is validated on roughly a third of resolution paths but cryptographically signed on only about seven percent of zones. So Silver and Gold assurance depends on whether the counterparty has done DNSSEC work that many organizations never prioritized. Check your own zones before you promise partners a tier you cannot deliver.

Maturity

As of the Cloud Security Alliance review in June 2026, the project was pre-1.0 and its reference implementation used mock cryptography for demonstration rather than production-grade PKI. Mock cryptography is fine for learning. It is wrong for money. Foundation governance may speed up hardening, but check the current status directly in the project's GitHub organization instead of assuming it.

Registrar incentives

Commentary in CircleID frames the debate bluntly: every agent needs a name, and the domain industry would like to sell it. That is a fair lens. Registrars and certificate authorities do benefit when every agent needs a domain and a certificate. None of that makes the design wrong. It does mean you should judge registration costs, renewal terms and portability on their merits, and not assume any one registrar is the only route.

Lookalike domains and verified impersonators

Verification binds an agent to a domain. It cannot tell you the domain belongs to the party you think it does. ANS does not solve typosquatting, and a fully verified agent on a lookalike domain is still an impersonator. Brand monitoring and counterparty onboarding checks remain your job.

The balanced view

The positives are real. The specification is public across seven documents. Eleven organizations spanning networking, security, certificate and SaaS vendors have contributed to or adopted it. In our view, that support plus neutral governance gives ANS a stronger starting position than single-vendor or single-author proposals. Because several DNS-based schemes are still competing, put agent identity checks behind an internal abstraction layer where that is cheap, so a shift in the winning scheme does not force you to rewrite every integration. The case is for staged adoption, not avoidance.