The Linux Foundation wants AI agents to prove who they are with DNS

Your CI pipeline is about to start trusting machines you cannot stare in the face. The agent that opens a pull request, the one that runs the deploy, the one that signs the artifact: each needs a name your build steps can verify, and most teams still resolve "which agent" by reading a bot account's handle. That is not identity. That is hope with a profile picture.

This week the Linux Foundation declared its intent to launch the Agent Name Service, an open standard for giving AI agents verifiable identities by tying them to DNS. The Foundation made the call on Tuesday, per reporting in The New Stack, and the bet is unsubtle: the namespace that already proves "this is example.com" is the namespace that should also prove "this agent works for example.com."

Where the spec came from

ANS did not start at the Foundation. The first version was a research paper published in May 2025 by the OWASP GenAI Security Project, co-authored by Ken Huang of DistributedApps.ai and Akram Sheriff, an AI security engineer at Cisco. A second version landed in April as an individual draft at the Internet Engineering Task Force, and that revision is where the design pins each agent to a real domain its operator already controls.

That provenance matters more than it sounds. A protocol that goes OWASP, then IETF, then a foundation is following the slow path. The slow path has produced almost every piece of working internet identity we have.

The mechanism, in short

The trust chain is short. An operator proves it controls a domain the same way it proves the domain for TLS, via ACME, the protocol behind Let's Encrypt. A registration authority then issues the agent a pair of certificates bound to that domain. From a pipeline's side, an agent claiming to belong to example.com has to present material a CA signed off on, working from a domain it never had to phone-verify.

Every change to an agent's status (registration, renewal, revocation) gets written to an append-only log. Clients pick how paranoid they want to be: a basic certificate check at one tier, a check that also consults the log at a stricter tier. If you have read about transparency logs in the certificate world, the shape is familiar. The mechanism is borrowed because the mechanism works.

What a build owner actually gets out of it

The first useful thing is a name your pipeline can verify without a vendor account in the loop. An agent firing a deploy stops being "the bot whose token lives in this repo secret." It becomes a certificate, a domain, and an entry in a log any outsider can audit. Revoking it is a write to a log instead of rotating a long-lived token across every workflow that references it and praying you found them all.

The second is recovery. Today, when an agent's credentials leak, you usually find out from a postmortem. An append-only status log lets a build step ask, before merging or deploying, whether the signing agent is currently in good standing. The verification cost is small. The blast-radius cost of skipping it is whatever your worst supply-chain anxiety looks like.

Third, you can compose policy on the verifying side. A merge gate that accepts agents only from operator domains on your allowlist becomes a single check against the log, not an allowlist scraped out of a vendor console and re-pasted into YAML.

Familiar plumbing in a new costume

None of these primitives are new. Workload identity frameworks have been issuing short-lived service identities for years. OIDC token exchange already lets a build step trade a short-lived identity for cloud credentials, which is how plenty of teams stopped baking long-lived cloud keys into their runners. Mutual TLS has been authenticating services to each other since before "agent" meant anything other than the kind that wears a suit.

What ANS adds is a name a human can read and a registry an outsider can verify, without anyone having to stand up their own trust domain or operate their own OIDC provider. The price for that convenience is a dependency on DNS and on whichever party plays registration authority. Some of you will read that and nod. Some of you will read it and think about the last DNS outage you sat through. Both reactions are fair.

What is worth watching

Intent is not GA. The announcement is a declaration, not a shipping artifact. There is no public reference implementation cited in the reporting, no list of CAs lined up to act as registration authorities, no obvious answer yet to what happens when an operator loses control of the domain its agent's name lives in. All of that is solvable. None of it is solved on the day the press release went out.

There is also the boring failure mode. A name that resolves through DNS is a name that fails when DNS fails. Pipelines that hard-fail on an ANS lookup timeout are pipelines that hard-fail when a registrar has a bad afternoon. The teams that survive will pick an assurance tier deliberately and design a degraded mode that does not just say "fine, no identity, ship anyway."

Verdict

Pinning agents to operator-controlled domains is the right move. It puts identity where the rest of the internet already keeps it, and it makes the audit story legible without inventing new ceremonies. Get this to a reference implementation a CI step can call without buying anything from anyone, and the agentic supply chain gets quietly safer. Leave it as a working group and a slide deck, and the next breach will be the one that names it.