News · DiggingBeagle record

Agent Name Service moves to Linux Foundation, identity proof remains distinct from authorization

Cross-registry agent identity standardization adds verifiability and discovery but not user action consent.

Published
Nov 13, 2026

The report

Agent Name Service became a Linux Foundation project on November 10, offering a DNS-anchored approach to naming, verifying and discovering AI agent identities across directories. Its published work can help identify which agent principal is presenting itself. It cannot by itself establish who asked that agent to act, which permission was granted or whether that permission is still valid.

What the standard proposes

The Linux Foundation announcement describes seven specification documents covering names, registration, versioning, DNS publication, public logs, integrity monitoring and authentication, with eleven organizations publicly supporting the effort. It notes early integrations with agent-directory and discovery projects. Those are project and interoperability claims, not a measured adoption rate, an independent revocation test or proof that agents using the same domain are authorized to exchange any particular user data.

Domain control and cryptographic verification can make an identity harder to misrepresent, but do not remove application-level permission decisions. An agent could present a valid name while acting through a delegated token with excessive scope. A directory could also retain a correct historic registration after the relevant credential has been revoked. Identity, authentication, consent, delegated authority and effect authorization need individually inspectable records.

A verified name can still create the wrong descendants

The BluePhishing blueprint demonstration shows why that distinction matters. A tenant consenting to a manager application may enable creation of child agent identities, whose grants and lifetimes are not proved safe merely by verifying the original manager's name. The ANS standard did not cause that vulnerability; it addresses a different part of the trust chain. The corresponding descendant identity pattern concerns permission survival and revocation.

A useful interoperability test would register an agent across two directories, rotate its certificate, disable its manager, and then attempt previously authorized protected tool calls from a descendant. It should record discovery state, credential validation, the user's grant and the executor's decision separately. Until such results are available, the new project is best understood as identity infrastructure with important integration questions, not a universal agent authorization system.

Research behind this