Agent Name Service: can AI agents finally prove who they represent?
The Linux Foundation welcomes Agent Name Service. We assess DNS-anchored identity, certificate signals, public logs and the limits of agent verification.
What the Linux Foundation announced on November 10
On November 10, 2026, the Linux Foundation welcomed Agent Name Service (ANS) as an open project. Its purpose is to provide verifiable identity and discovery for software agents interacting across domains and platforms. The foundation says the specification consists of seven documents and has support from eleven organizations. This is a standards-governance development, not evidence of universal adoption or blanket certification.
The distinction matters as agents start interacting with third-party tools, A2A endpoints and external data sources. Before allowing an agent to act for a company, a receiving system must establish which organization or domain claims it. ANS attempts to standardize that identification step, but it cannot independently establish whether the agent is honest or reliable.
How DNS, certificates and audit records fit together
ANS uses the Domain Name System as a naming anchor. Organizations can publish agent identity records associated with domains they control, while certificate-based signals support verification. The specifications address registration, versioning, DNS publication, public log auditing, integrity monitoring and agent-to-agent authentication. These are separate pieces of an identity lifecycle rather than one magic verification flag.
An implementation should discover an agent, verify its domain and accompanying signals, examine freshness and changes, and then make a separate access decision. DNS visibility does not itself provide safe transport or permission to transfer confidential information. A certificate proves only the claims and scope encoded and correctly validated by the relevant scheme.
Identity is not authorization, performance or trustworthiness
Verified ownership answers who a client is dealing with. Authorization determines what that identity may do in this environment. An authentic corporate agent can still be misconfigured, accept malicious instructions or request inappropriate access. Sensitive actions need independent policy checks, least-privilege tools, transaction limits and sometimes explicit human approval.
AgentenCode assessment: identity verification becomes valuable when it is enforced before access is granted. An ANS record must not be marketed as a security grade, a compliance certificate or independent evidence that agent outputs are correct.
The early integrations: AGNTCY and ANS Finder
The Linux Foundation identifies two concrete interoperability milestones. AGNTCY Agent Directory Service can verify ANS identities. ANS Finder also works with Agentic Resource Discovery (ARD), with the project reporting conformance tests for the relevant registry interface. These statements cover discovery and identity interfaces—not a comprehensive audit of every possible agent behavior.
A directory listing should not automatically make an endpoint trusted inside a customer organization. Registered identities may point to outdated versions or changed configurations, while permissions within a particular organization may have been revoked. Runtime controls need to complement registry evidence.
A five-stage pilot that does not assume trust
For a limited deployment, first establish the real domain owner and responsible operator. Second, resolve the specified DNS and certificate records through an independently observable verification path. Third, check identity version, change history and revocation. Fourth, grant only the exact tools and datasets needed. Finally, log the evidence used to authorize each material action.
Start with harmless read-only tasks. Test a wrong-domain claim, an expired or rotated credential, stale directory information and DNS outages before enabling writes or payments. Only then consider expanding scope, with measurable rollbacks and a named human owner.
The attack surfaces that do not disappear
Domain takeover, DNS tampering, lost keys and stale caches remain possible. Real deployments also need dependable handling of renamed agents, subagent delegation and registry outages. ANS outlines components intended to make identity auditable, but actual security depends on correct deployment, monitoring and enforcement.
More fundamentally, an agent with a genuine identity can still fall for prompt injection. Authentication cannot replace sandbox isolation, permission checks, tool policies or action-level auditing. Operator identity and behavioral trust remain distinct layers.
How mature is the new standard?
Neutral governance and eleven named supporters are meaningful signals of ecosystem coordination. Open specifications make independent implementations possible. However, the announcement does not provide broad production adoption figures or reproducible independent security results for participating software. The maturity of each implementation needs to be assessed separately.
Procurement teams should therefore ask which specification version is supported, who maintains the verification service, how revocation works and whether the identity is interoperable with their gateway and IAM systems. ANS should be treated as an evolving infrastructure option, not a mandatory pass mark.
AgentenCode decision: when ANS has practical value
The clearest use case is cross-organization discovery: external supplier agents, third-party MCP servers, A2A transactions and marketplaces. For agents confined to one private environment, established enterprise PKI and workload identity may already solve much of the identity problem. Adopting a new naming layer should have an observable integration benefit.
Our recommended pilot compares a fixed set of external agents using ANS and the current controls. Measure correct and incorrect identity validation, revocation detection time, unauthorized tool calls rejected and operational complexity. Those results—not the number of names in a registry—should decide whether to deploy broadly.
Supporters named by the foundation include Cloudflare, Cisco, GoDaddy, DigiCert and other organizations spanning identity, DNS, security and agent infrastructure. Their participation shows ecosystem interest but does not tell us how many independent systems currently validate ANS identities automatically. Neutral governance and AGNTCY integration are demonstrable milestones; widespread interoperability will still require open conformance testing and operational evidence.
AgentenCode decision matrix
| Scenario | Starting point | Release condition |
|---|---|---|
| External agent | Check ANS/DNS and certificate binding | Allow only with explicit tool policy |
| Internal agent | Compare existing PKI/workload identity | Avoid duplicate systems without measurable value |
| Agent marketplace | Verify registry records and revocation | Directory listing is not certification |
| Payment or data export | Use identity as one prerequisite | Require approval and action audit |
Primary sources and evidence limitations
Sources reviewed November 11, 2026. Editorial analysis of primary disclosures; no independent implementation, effectiveness study or security audit.
Further reading: AgentenCode Trust · AI agent security · OpenShell architecture
Frequently asked questions
Does ANS certify that an AI agent is safe?
No. It provides identity and discovery mechanisms. Authorization, security and output quality require separate checks.
Is ANS mandatory for AI agents?
No. It is an open emerging standard, not a universal adoption requirement.
Which infrastructure does ANS use?
It anchors names in DNS and domains, supported by certificate-based signals and auditable records.
How does it differ from an agent directory?
Directories make agents discoverable. ANS addresses verifiable identity; access policy and behavior remain separate.