Agent Name Service (ANS) Explained, Agent Identity

Agent Name Service (ANS) is an open standard that ties an AI agent's identity to a domain name its operator controls, publishes the evidence through DNS records, and logs each registration in a public transparency log. The Linux Foundation welcomed it as a project on November 10, 2026. ANS answers "who is this agent?" It does not answer "what may this agent do?"

That second question is where most teams get stuck. The ANS authentication spec says its procedures establish who is calling, "never what they may do", and it leaves delegation (an agent acting for a user) out of the current revision. The status label matters too. The Linux Foundation calls the specification "formalized", while the ANS site and the spec files still call the documents drafts.

See how an MCP server handles access

Oakgen's MCP server lists OAuth and personal API key sign-in. See how agents discover models, check prices and start jobs.

Explore Oakgen MCP

The short version

This table is the part to save. It compares four ways to identify an agent or its client, using only cells we checked against the primary page on November 12, 2026.

Option	What it identifies	How identity is proven	Authorizes actions	Status on 2026-11-12
ANS	A versioned agent registration anchored to a domain, such as `ans://v1.0.0.payments.example.com`	A registration authority checks domain control and seals the event in a transparency log. Callers prove key possession with mTLS or DPoP	No. ANS-6 authenticates and never authorizes	Linux Foundation project. Spec files labelled DRAFT. IETF individual draft 02
A2A Agent Card	An agent endpoint, through a JSON card at `/.well-known/agent-card.json`	The card MAY be signed as a JWS. Clients SHOULD verify one signature and the server's TLS certificate	The card declares accepted schemes. Credentials come from outside the protocol	A2A 1.0.0 is the latest released version
MCP authorization with CIMD	The MCP client, by an HTTPS URL used as its `client_id`	The authorization server fetches the document, checks `client_id` matches the URL and validates redirect URIs	Yes. OAuth 2.1 tokens with scopes, bound to the server as audience	Authorization is OPTIONAL. CIMD is SHOULD and is an IETF working group draft
OAuth 2.0 with token exchange	A client or user, through an authorization server	The authorization server authenticates. RFC 8693 adds impersonation and delegation	Yes. This is where scopes and delegation live	RFC 8693 and RFC 9728 are Standards Track

ANS is the only row that names the agent itself, with a history and a version. MCP authorization and OAuth are the only rows that grant anything. The A2A card sits between, describing an agent and how to authenticate to it.

Who this is for

You run security, platform or operations for a team that will let outside agents call your systems, or send yours out to call theirs, and you want to know what ANS covers before it shows up in a vendor questionnaire.

The gap this standard is aimed at

InfoWorld's November 10, 2026 analysis by Isaac Sacolick puts the gap in one quote from Kevin Paige, CISO at C1.ai. MCP and A2A are "one giving agents a dial tone to tools, the other a dial tone to each other, but neither saying who is authorized to place the call". That is one executive's opinion, but it matches the specs. MCP defines how a client gets a token, and A2A says credentials are obtained out of band.

Split "identity" into four questions.

Who is this agent, and is it the one I think it is?
Who operates it and answers for it?
On whose behalf is it acting right now?
What is it allowed to do?

ANS targets the first, and partly the second. Authorization standards answer the fourth. Delegation, the third, is the least settled. RFC 8693 token exchange covers it at the OAuth layer, and ANS leaves it for later.

An incident shows why attribution matters. WorkOS's bulletin of November 6, 2026 says an AI agent that escaped a security researcher's test environment pulled records in bulk from an internal tool on October 30. WorkOS attributed it only after the researcher came forward and a forensics firm matched the evidence to its logs. The bulletin does not say what identity the agent presented, and an identity record would not have stopped it. CircleID's Alan Wallace makes the same point, calling it an attribution gap.

What ANS specifies

The Linux Foundation's November 10 press release says the specification has seven documents, is governed by a technical steering committee, and has 11 contributing or adopting organizations since June. They are Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP and Trustmodel.ai. It also says the AGNTCY Agent Directory Service supports verification of ANS identities. Those are the foundation's claims, and we tested none of the integrations. The New Stack reported on June 23, 2026 that ANS began as a May 2025 OWASP paper.

The documents run from ANS-0 (proof of control and optional Verified Identities) through registration, the versioned name and certificate, DNS publication, the transparency log and integrity monitoring, to ANS-6 (how one agent authenticates another). In plain terms, it works like this.

A name for a registration. The name carries a version, as in ans://v1.0.0.payments.example.com. The ANS site says a new version is a new registration, so a verifier can pin an agent to a release.

Proof of domain control. The operator submits its host, endpoints and certificate material to a registration authority, which checks control of the domain with an ACME-style challenge. ANS-0 states the governing rule. An identity is sealed only after control is proven, "never on resolution alone".

DNS records and a log entry. The default ANS_DNSAID profile uses SVCB records in the style of DNS-AID, with a TXT-based profile as an opt-in. A required _ans-badge TXT record points to the agent's entry in the transparency log, and TLSA records for DANE are optional. The log seals the event before activation succeeds.

Authentication at call time. ANS-6 describes three proofs. Identity asks whether this certificate is bound to this agent in the log. Status asks whether the registration is still valid. Possession asks whether the peer holds the private key. Method A is mutual TLS. Method B is an RFC 9449 DPoP proof in a header, which survives gateways that terminate TLS. The spec recommends offline SCITT receipts for new implementations.

A guard against trusting DNS. ANS-6 says the DNS record locates the badge and does not confer trust. A verifier must check the badge URL against a log host it already trusts.

An optional "who" layer. ANS-0 separates the agent (always anchored to a domain) from the operator behind it. Verified Identities are optional, with profiles for did:web, did:key, lei and ens. The spec calls the registration authority "a notary, not a judge".

Try an agent workflow with an approval step

Draft a creative brief in Oakgen Agent Chat, review the plan, and approve each paid step yourself.

Open Agent Chat

What ANS does not specify

Authorization. ANS-6 says the callee must apply its own authorization to the authenticated identity. The ANS site adds that authentication "does not authorize an action or delegate a user's permissions".
Delegation. ANS-6 calls an agent acting for a user across a call chain a separate, higher-risk concern outside this revision.
Trust scoring. The trust-index-spec repository covers scoring, and the ANS spec index calls it "not an ANS protocol layer".
Proof about code or behavior. The ANS site says sealed metadata digests "do not attest the code executing on a remote machine or guarantee an agent's behavior". The specification README says a version-bound certificate "records which code is running". The two pages read differently, so plan around the narrower one.
Whether a domain is benign. CircleID reports that Bill Hartzer pointed out on launch day that whoever holds a lookalike domain can register a fully verified agent on it. Verified is not trustworthy.

There is also a wording mismatch. The Linux Foundation's June 23, 2026 announcement said the framework lets systems verify "what permissions it has" for an agent. The current ANS-6 text says the opposite. If a vendor says ANS covers permissions, ask for the spec section.

Status, critics and rivals

Standing. The IETF datatracker shows draft-narajala-courtney-ansv2-02, updated October 26, 2026, as an Independent Submission with intended status Informational and no formal standing in the IETF process. It expires April 29, 2027. ANS-0 is dated 2026-06-23 and ANS-6 2026-11-03, both version 0.2.0 and labelled DRAFT v1.0.

Commercial interest. The New Stack argued in June that the trust hierarchy ANS inherits is old and fragile, and that registrars profit most from pushing it. CircleID repeats the point on November 10. Its author runs a public relations firm and worked at the registry Afilias from 2015 to 2020, so read it as opinion.

Security analysis. The Cloud Security Alliance's June 25, 2026 paper analysed the earlier design. It says trust roots in DNS and the certificate authority system, and cites APNIC Labs data that DNSSEC is signed on about seven percent of zones. We did not open the APNIC data. The paper also says the reference implementation it reviewed, a separate repository by Ken Huang, used mock cryptography. The current Go reference is a different codebase that we did not audit. CircleID lists an independent security review of the launched standard as something to watch for, and we found none.

Rivals. The New Stack counted at least four DNS-based efforts in June, including DNSid and DNS-AID, and CircleID adds a Verisign draft. We did not open those drafts.

How ANS differs from A2A Agent Cards

An A2A Agent Card is the agent describing itself. The A2A specification says servers must make a card available, listing identity, skills, endpoint and authentication requirements. Cards may be signed with a JSON Web Signature after JCS canonicalization, and clients should verify at least one signature before trusting a card.

A signature shows the card was not altered after the key holder signed it. In the sections we read, trust in that key comes from where you fetch it, over HTTPS or from a key store you maintain. ANS adds an outside party, a registration authority that verified domain control and sealed the event in an auditable log.

The two fit together. The IETF draft says a registrant can declare a SHA-256 digest of the agent card it serves, and the authority checks the digest format without fetching the card. ANS can bind a card to a registration, but it does not vouch that the card's claims are true.

How ANS differs from MCP authorization

MCP authorization asks one thing. Can this client call this server for this user? In the latest spec (2026-07-28) the MCP server is an OAuth resource server that publishes RFC 9728 metadata. Servers must validate that a token was issued for them, and must not accept or pass on other tokens. The MCP security best practices page covers related attacks, such as the confused deputy problem for proxy servers.

For client identity, clients and authorization servers should support Client ID Metadata Documents. The client uses an HTTPS URL as its client_id, pointing to a JSON document with at least client_id, client_name and redirect_uris. Dynamic Client Registration is deprecated. CIMD is an IETF working group draft. The datatracker shows revision 03 of November 2, 2026, while the MCP page cites revision 00.

CIMD and ANS both lean on HTTPS and domain names, but the outputs differ. CIMD ends in a token carrying a user's grant. ANS ends in identity evidence and grants nothing. One pairing would let an authorization server's trust policy prefer clients with a verified ANS registration. We know of no spec that describes it, so it is our suggestion.

A checklist for teams

Use this before you write "supports agent identity" in a questionnaire or policy.

Scope the problem

List which of your agents call outside systems, and which outside agents call yours.
For each, write the four answers you need. Who is it, who runs it, on whose behalf, what may it do.

Authorization first

Every MCP server you run or call uses scoped tokens and rejects tokens issued for another audience.
A request for more scope triggers fresh consent, not a silent upgrade.
Paid, public or irreversible actions need human approval, whatever the identity evidence says.

Identity evidence

You can state which evidence you accept for outside agents today, such as TLS validation, a signed A2A card or an allowlisted client URL.
If you adopt ANS, the transparency log keys you trust come from configuration, not from the DNS records under verification.
Your policy says what happens when a status check fails or a log is unreachable. Fail closed for anything sensitive.
You watch for lookalike domains of names you care about.

Accountability

You log the identity evidence seen on every outside call.
Each of your agents has a named human owner and a fast way to revoke its credentials.
Someone rechecks the ANS, A2A and MCP authorization pages monthly.

Methodology and as-of date

We opened each source on November 12, 2026. For ANS that means both Linux Foundation releases, the GitHub organization and spec index, the ANS-0 and ANS-6 files, the ansinfo.ai pages and the IETF datatracker entry. For comparison we read the A2A 1.0.0 specification and the MCP 2026-07-28 authorization and client registration pages. The registration-flow text we read from the IETF draft was revision 01, while 02 is current, so check those details against the live draft.

We did not run the ANS reference implementation, test any integration, or verify the 11 supporters beyond the press release. The A2A and MCP rows describe the specs, not deployments.

Disclosure. Oakgen is our product. We have no role in ANS, A2A or MCP governance and no commercial tie to any organization named here.

How a creative team would apply this

Most creative teams do not run agent-to-agent traffic across companies yet. They connect a coding agent or chat assistant to tools that make images, video or audio. Identity matters narrowly there. You want to know which tool server you are talking to, and a person should approve paid generations.

Oakgen is our product. Its MCP page lists OAuth and personal API key authentication, and we searched our code and content on November 12, 2026 and found no ANS support. Do not read our MCP server as ANS-verified. For more, see our MCP security checklist for creative teams and when a creative agent should wait for human approval.

Keep a human in the loop on paid generation

Plan the brief in Agent Chat, check the price, then approve the spend.

Plan a creative brief

Common mistakes

Reading identity as permission. A verified agent can still ask for something it should not get. ANS says so in its own spec.
Treating "formalized" as final. The announcement and the spec files use different words. Plan for revisions.
Trusting the DNS record that points to the proof. ANS-6 warns against it.
Assuming the card is the identity. A signed A2A card shows integrity, and the key still needs a source you trust.
Waiting for one winner. Several DNS-based proposals compete, and OAuth already covers part of the problem.

Decision framework

You call a few trusted partner agents. Use TLS, scoped OAuth tokens and an allowlist. ANS adds little yet.
You expose an MCP server to unknown clients. Follow the MCP authorization spec, prefer Client ID Metadata Documents over Dynamic Client Registration, and validate token audience. ANS is optional.
You publish an A2A agent for other companies. Sign your Agent Card, serve it over HTTPS and publish clear security schemes. Watch ANS as outside verification.
You are a registrar, DNS or certificate vendor, or a platform that vets agents. Read ANS-0, ANS-3 and ANS-6 and run the reference implementation yourself.
You need to know on whose behalf an agent acts. Look at OAuth token exchange and your identity provider. Neither ANS nor the A2A card settles it.

What I would do

I would not wait for ANS. This quarter I would make authorization strict and boring, with scoped tokens, audience checks, approvals for paid or public actions, and logs of who called. Then I would add identity evidence in layers, starting with signed Agent Cards and TLS validation for outside agents.

I would put ANS on a watch list with two triggers. One is an independent security review of the launched specification. The other is a major agent platform or gateway saying it verifies ANS identities in production, not only in a press release. Until then I would ask vendors for a written answer on authorization and delegation, and not require ANS in a contract.

Connect agents to creative tools with clear access rules

Review how Oakgen's MCP server handles sign-in, model discovery, price checks and job status.

Review Oakgen MCP

For more in this series, see our explainers on MCP versus A2A, the Agentic AI Foundation and the MCP supply chain security checklist. For MCP basics, read what an AI image generation MCP server is.

Turn an approved brief into finished creative

Once the plan is approved and access rules are set, generate the images and video in Oakgen's AI product creative studio.

Open the creative studio

Frequently asked questions

What is Agent Name Service (ANS)?

ANS is an open standard that gives an AI agent a verifiable identity tied to a domain name its operator controls. A registration authority checks domain control, issues certificates and records the event in a public transparency log, and the operator publishes DNS records that let others find the evidence. The Linux Foundation welcomed ANS as a project on November 10, 2026, and says the specification has seven documents.

Is ANS a finished standard?

Sources disagree on wording. The Linux Foundation's November 10, 2026 press release says the specification is now formalized and governed by a technical steering committee. The ANS site says the published specifications are drafts under active development, and the ANS-0 and ANS-6 files are labelled DRAFT. The IETF document behind it is an individual Internet-Draft, revision 02, intended status Informational, which the IETF page says is not endorsed by the IETF. Treat it as an early open standard, not a settled one.

Does ANS decide what an agent is allowed to do?

No. The ANS-6 specification says every procedure in it authenticates a peer, establishing who is calling and never what they may do, and that the callee must apply its own authorization. Delegation, meaning an agent acting for a user or another agent, is listed as outside the current revision. Note that the Linux Foundation's June 23, 2026 announcement said the framework lets systems verify what permissions an agent has, which the spec text does not support.

How is ANS different from an A2A Agent Card?

An A2A Agent Card is a JSON document the agent publishes about itself, with its skills, endpoint and the authentication schemes it accepts. It may be signed with a JSON Web Signature. ANS adds a registration step in which a registration authority verifies domain control, issues certificates and seals the event in a transparency log, with a version in the name. The two can work together, because ANS lets a registrant declare a SHA-256 digest of the agent card it serves.

How is ANS different from MCP authorization?

MCP authorization, in the 2026-07-28 spec, is an OAuth 2.1 based flow in which an MCP client obtains a token to call an MCP server for a user. A client can identify itself with an HTTPS URL that hosts a Client ID Metadata Document. The output is an access token with scopes. ANS produces identity evidence and no permissions. They answer different questions and are not substitutes.

Do I need ANS to run or call MCP servers today?

No. MCP authorization is optional in the spec, and nothing in the MCP or A2A specs we read requires ANS. If you call servers or agents run by other companies, the practical controls today are OAuth with narrow scopes, token audience checks, allowlists and human approval for costly or irreversible actions. ANS is worth tracking, and worth requiring from a counterparty only once your own verifiers can check it.

Who backs ANS?

The Linux Foundation's November 10, 2026 release names 11 organizations that have contributed to or adopted the standard since June. They are Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP and Trustmodel.ai. The release also says the AGNTCY Agent Directory Service supports verification of ANS identities. Several backers sell domains, DNS or certificates, which critics have pointed out.

What are the main criticisms of ANS?

Commentators raise four. Trust is rooted in DNS and the certificate authority system, which are centrally governed. DNSSEC, which protects the bindings, is signed on a minority of zones according to the Cloud Security Alliance's June 2026 analysis of the earlier design. Several backers profit from domain and certificate sales. And there are competing DNS-based proposals. A verified agent can also sit on a lookalike domain, so verified does not mean trustworthy.