AI Agents Need Identity Before Autonomy Scales

Turns the ANS handoff topic into an operator framework for evaluating AI-agent identity, DNS/PKI verification, discovery, permissions, auditability, and founder opportunities around agent governance infrastructure.

The next constraint on AI agents is not only reasoning quality. It is trust plumbing.

If an agent can call tools, move across services, represent a company, open workflows, and interact with other agents, the basic operational question becomes uncomfortable: who is this agent, who does it represent, and how does another system verify that claim without trusting one vendor's private registry?

That is why the Linux Foundation's Agent Name Service announcement matters. ANS is not a finished answer to agent safety. It is a signal that agentic AI is entering the boring but necessary infrastructure phase.

The thesis: agents cannot become a durable business interface until identity, discovery, verification, and governance move from product feature to shared control plane.

Why This Matters Now

The Linux Foundation announced on June 23 that it intends to launch Agent Name Service, an open standard for trusted identity, verification, and discovery for AI agents. The proposed system builds on DNS, not a new centralized lookup network.

The data point behind the urgency is clear. The Linux Foundation cited World Economic Forum data that 82% of executives plan to adopt AI agents within one to three years. GoDaddy has separately projected more than one billion AI agents built by businesses alone over three years.

Even if those forecasts prove too aggressive, the direction is obvious: enterprises are preparing for many more semi-autonomous software actors than their current governance systems were designed to manage.

CIO Dive framed the gap sharply: citing IBM research, it reported that only 11% of technology executives feel prepared for the scale of agentic AI deployment over the next year. It also cited Deloitte research that only 1 in 5 companies report a mature governance model for AI agents.

That is the real market signal. Agent adoption is accelerating faster than agent control.

The Agent Identity Stack

ANS points to a four-layer stack every serious agent deployment will need.

First, naming. Humans and systems need a stable way to reference an agent. GoDaddy's ANS material describes human-readable names mapped to agent endpoints and metadata through domains and DNS.

Second, verification. A name is not enough. GoDaddy describes X.509 certificates and PKI as the mechanism for proving identity, while the Linux Foundation says ANS is meant to help verify who an agent represents, what permissions it has, and whether its code and operational history remain authentic and unchanged.

Third, discovery. Agents need to find capabilities and endpoints without relying on ad hoc integration lists. Infoblox's DNS-AID work is complementary here: it focuses on publishing discoverable metadata through existing DNS record types, while ANS focuses on identity, naming, and verification.

Fourth, governance. Identity only matters if policy can attach to it. Enterprises will need approval rules, audit logs, revocation, scope limits, runtime monitoring, and incident response tied to each agent identity.

This is where the hype usually gets ahead of the system. DNS and PKI can help establish a trust foundation. They do not automatically solve authorization, prompt injection, tool misuse, data leakage, or bad business logic.

The Operator Test

Teams evaluating agents should stop asking only whether an agent can complete a task. Ask whether the organization can govern the agent after it starts succeeding.

Can the agent's identity be verified by another system?

Can the organization prove which company, team, workflow, or user the agent represents?

Can permissions be inspected, narrowed, and revoked?

Can another agent or service discover what the agent can do without accepting a proprietary trust claim?

Can logs show what changed between the identity claim, the tool call, and the resulting action?

These questions sound dull compared with model demos. They are the difference between a pilot and an operating system.

The Founder Opening

The opportunity is not only to build more agents. It is to build the identity, policy, and observability layer around agents.

Useful products will live in the gaps: agent registries, DNS/PKI implementation tools, MCP and A2A policy gateways, certificate lifecycle management, agent permission reviews, trust-score explainability, audit trails, revocation workflows, and runtime monitors that connect identity to actual behavior.

The best wedge may be narrow. Start with one high-risk workflow, such as customer support actions, finance approvals, developer tooling, or procurement. Give every agent a verifiable identity, limit its permissions, log its actions, and make revocation obvious.

That is more valuable than another generic agent dashboard.

The Takeaway

ANS is still proposed infrastructure. The archived IETF draft is experimental, and the Linux Foundation announcement is an intent to launch, not proof of universal adoption.

But the direction is important. Agentic AI is moving from "can it act?" to "can we trust the actor?"

The next serious agent stack will not be judged only by model quality. It will be judged by whether identity, discovery, verification, permissions, and auditability are built in from the beginning.

Autonomy without identity is just another shadow IT problem. Autonomy with verifiable identity starts to look like infrastructure.