From IAM to ANS: How DNS Aims to Secure the Era of Autonomous Agents

Enterprise access management systems—or IAM architectures—were designed for two specific situations. On one side, a human logging in. This person must prove their identity with a password, sometimes backed by multi-factor authentication (MFA). On the other side, service accounts or static API keys tailored for highly predictable workloads.

Autonomous AI agents fit into neither category. These systems can interpret a high-level goal, plan the steps to reach it, and call third-party tools through APIs. They can then interact directly with other systems or agents on the company’s behalf. The catch is that this autonomy blurs the boundaries of traditional IAM.

So how do you assign an identity to an agent? How do you confirm it really is who it claims to be, and grant it access rights with confidence? Granted, protocols such as MCP or Agent-to-Agent (A2A) already organize exchanges between machines. However, strictly speaking, these protocols were never meant to manage identity.

This challenge is becoming more pressing as generative AI adoption changes in nature. According to the World Economic Forum, 82% of executives plan to deploy AI agents within the next three years. Yet only 11% of technology leaders surveyed by IBM’s Institute for Business Value feel ready to govern them at scale. Agent autonomy is therefore advancing faster than the mechanisms meant to keep them in check.

This is precisely the governance gap we analyzed in our white paper, « “AI Agents: The IAM Governance Gap.” Since then, the landscape has changed. The Linux Foundation announced the launch of the Agent Name Service (ANS), an open standard. It applies to AI agents the principles of DNS, the directory that reliably identifies websites on the internet. It assigns them a verifiable, discoverable identity linked to an organisation. ANS thus gives IAM solutions a new tool to secure the identity of autonomous agents. This first step is essential to govern access and apply Zero Trust security principles. It also helps organisations better control the risks of agentic AI.

The Agent Name Service (ANS): A Trust Layer Modelled on DNS

Faced with this protocol gap, the Linux Foundation shared its plans on June 23, 2026. It intends to launch the Agent Name Service (ANS). This directory service for artificial intelligence agents is being developed with support from major players in internet infrastructure and cybersecurity. These include Cloudflare, GoDaddy, Salesforce, Cisco, and Infoblox. ANS is an open standard. It applies principles already proven by DNS to the identification of AI agents.

No centralized registry, no proprietary solution in the hands of a single giant.

An organisation can therefore link its agents’ identity to a domain it controls (for example, ans://v1.0.0.agent-finance.company.com).

ANS does much more than certify an identity. It locates an agent, identifies its organisation, and exposes its technical characteristics.

This capability meets the security challenge posed by shadow AI. This refers to AI agents that appear without the knowledge of the teams responsible for securing them. Identity, verification, and discovery are therefore the three building blocks necessary to establish a climate of trust.

Proving an identity, guaranteeing the integrity of a history, linking an agent to an accountable organisation… Technically, ANS transposes trust mechanisms already used to secure digital exchanges to AI agents. To do this, it relies on several existing cryptographic standards and protocols:

 

•  Identity Verification and Issuance: Each agent receives a versioned name. Its identity certificate, however, is only issued after the domain passes DNS and ACME checks. These are the same checks a website undergoes to obtain a standard TLS certificate. The issuance process is therefore proven, not experimental.µ
• Transparency: Registrations, renewals, and revocations are recorded in an immutable log based on Merkle technology. This prevents an agent’s history from being rewritten after the fact.
• Offline Verification: The ans-verify tool instantly validates an agent’s code signature and integrity without an active connection to the global registry.
• Provenance Verification: Signed identity certificates enable secure machine-to-machine communication (mTLS) between agents.
• Support for Enterprise Standards: ANS also supports decentralized identifiers (DIDs) and Legal Entity Identifiers (LEIs). This dual support allows existing identity systems to be integrated into a unified verification model. This model, in turn, links the software entity to the legal entity accountable for it.

Technical teams will care about one detail: the reference implementation is a Go repository under an MIT license. It bundles the entire stack (registry, logging, verifier). One caveat, though: this is still just an intention to launch, and at an early stage. By design, DNS remains poorly suited to carrying highly sensitive identities, hence the need for additional mechanisms against impersonation. Moreover, ANS is entering a field already occupied by other frameworks.

These include AGNTCY, a project led by Cisco to enable discovery and interaction between agents. Also worth mentioning is DNS-AI Discovery, an approach that relies on DNS mechanisms to let applications find available AI agents. A promising building block, then, but one to adopt with full awareness, not as a standard already set in stone.

ANS: A Trust Building Block, Not a Governance Solution

The wrong reflex would be to treat ANS as an access control system. That is not its role. ANS does not say whether an agent has the right to read an SAP table. Nor does it manage any approval process. It answers a single question, and that question is strictly infrastructural: “Can I cryptographically prove who this agent is and who it belongs to?”

In other words, ANS proves who is speaking, never what it is authorized to do. Everything else (authorizations, access reviews, least privilege) is built on top of it, within a genuine governance architecture. This is why ANS should position itself as a cross-cutting trust infrastructure layer (“Trust Infrastructure”) that feeds all the modules of Identity and Access Governance (IAG).

Upstream, the IAM solutions already in place feed the registry, acting as owners of agents and tools. They also expose to agents the application access rights that can be granted. Downstream, agentic governance is structured around four capabilities that hand off to one another:

• Agent discovery: continuously scan environments to detect agents present on execution platforms.
• Agent identity governance: maintain an enriched registry of agents and their controls, including agent access management.
• Agent access governance: precisely define each agent’s access (tools, memory, RAG, and more).

   

• Fine-grained authorization and policy engine: apply these principles in real time (at runtime) and at the most granular level. Factor in both the agent’s own access and the access inherited from the user it acts on behalf of. This is also where policy-as-code takes hold. Rather than scattering authorization rules across each application’s configuration, they are expressed as code. That code is versioned, tested, auditable, and replayable. Each rule explicitly links the “who” (the identity verified upstream) to the “what” (the action requested on a given resource). Every change leaves a trace. An access decision then stops being a buried setting and becomes a governable artifact. It is reviewed like any other piece of critical code.

 

A final thread runs through these four capabilities without merging with any of them: observability. It is the capacity to continuously observe what agents actually do once in action. (This includes which resources they request, which actions they perform, and how often.)

Everything described above is preventive (who exists, who can access what, and under which rule). But an agent is non-deterministic. What it actually does in production does not always match what was expected.

This is where observability comes in. It continuously collects execution traces. This includes logs of the actions performed: tool calls, exchanges via MCP, or data actually accessed. MCP is a protocol that allows AI agents to access external resources.

It then centralizes these traces in a SIEM. A SIEM is a security information and event management platform that analyzes these events.

It highlights the gap between potential access and actual access, and flags abnormal action sequences. These signals then feed into governance: adjusting security rules (policies), revoking a digital identity, or triggering a human review. Without it, governance remains declarative. With it, governance becomes a loop that corrects itself in real time.

 

From ANS to Agentic Zero Trust

The rise of autonomous agents is redefining the boundaries of enterprise productivity. But autonomy without control creates a systemic risk that traditional security infrastructure cannot contain. By offering a standardized, decentralized, and secure identity protocol at Internet scale, ANS marks a real turning point.

Still, identity is only the starting point. Proving who an agent is says nothing about what it should be allowed to do. And that is precisely the founding principle of Zero Trust: never grant trust by default, always verify.

Applied to agents, this Zero Trust Architecture (ZTA) means integrating identity as one building block. It must sit within a global identity and access governance architecture. This architecture must be able to assess, monitor, and restrict agent actions in real time.

This is exactly what Agentic Zero Trust is about: the moment “legitimate by default” stops being an option. We covered this topic in the article “Agentic Zero Trust: organizing trust around AI agents.”

But designing this architecture raises a question that cannot be left to technology alone. Who decides what an agent is allowed to do? Because that decision belongs to the business.

Cybersecurity equips, controls, and enforces. Data structures, qualifies, and tracks usage. But it is the business that decides whether access is legitimate. Only the business knows the value and sensitivity of the data and resources the agent accesses.

In this way, agentic AI brings cybersecurity, data, and the business together around the same decision-making table. It marks a new way of working.