What is DNSid
DNSid gives AI agents verifiable, domain-anchored identities—the accountability anchor that lets one agent answer the question “Who are you, and should I believe you?” about another.
TLS proves you’re talking to the right server. DNSid proves you’re talking to the right agent—and lets anyone verify it with nothing but public DNS and the domain its operator already owns.
The problem
Section titled “The problem”AI agents are being deployed across the internet—calling APIs, negotiating with other agents, and acting on cloud resources across organizational boundaries. Every one of those calls raises the same question: which accountable entity is responsible for this agent, and can anyone verify that independently?
Today’s answers don’t hold up:
- Bearer credentials don’t identify callers. API keys and shared secrets prove possession, not identity—they get shared, leaked, and rotated in the dark.
- Trust setup doesn’t scale. IP allowlists and hand-configured mTLS mean bilateral arrangements with every counterparty, for every agent.
- Nothing answers for the past. When an auditor asks which entity stood behind an agent’s action last quarter—after its keys rotated and the agent was retired—none of these mechanisms has an answer.
These workarounds assume a human provisions each integration. Agents that discover and call each other at machine speed need an identity any counterparty can verify without prior coordination.
What DNSid is
Section titled “What DNSid is”DNSid is a DNS-anchored identity substrate for AI agents. An agent’s identity is rooted in a domain name its operator controls, published as a signed DNS TXT record, and independently verifiable by any counterparty. No prior arrangement between the operator and the counterparty is required, and no bilateral federation is set up. No new certificate authority to trust, no central directory, no shared secrets—the trust anchor is the domain itself.
Where it fits in the stack
Section titled “Where it fits in the stack”DNSid is Layer 1 of the agent identity stack—the durable accountable-ownership anchor. Reading from the bottom up:
- Layer 0—namespace governance. DNS, ICANN, and DNSSEC. The internet already has this; DNSid rests on it.
- Layer 1—accountable ownership. DNSid. A durable, verifiable record of which domain, and therefore which operator, stands behind an agent.
- Layers above—identity binding, workload identity, runtime auth and policy. Credential formats like DIDs, runtime identity systems like SPIFFE/SPIRE, and token and policy layers like OAuth/OIDC. These anchor on DNSid rather than compete with it.
What DNSid is not
Section titled “What DNSid is not”- Not human authentication. DNSid identifies machines, agents, and services—people keep using your existing IdP and SSO.
- Not a TLS replacement. DNSid works at the application layer and complements the Web PKI; it doesn’t terminate connections or issue server certificates.
- Not runtime authorization. What an agent is allowed to do stays with the layers above—workload identity (SPIFFE), tokens (OAuth/OIDC), and policy engines—which anchor on DNSid rather than compete with it.
- Not a reputation system. DNSid proves which accountable entity stands behind an agent, not whether that entity is trustworthy. That judgment stays with the verifier’s own policy.
What you can build
Section titled “What you can build”- Give an agent a verifiable identity on a domain you own, and prove the whole loop on your laptop first with DNSid Local.
- Sign and verify agent-to-agent requests with a few lines of SDK code.
What a verifiable agent identity unlocks
Section titled “What a verifiable agent identity unlocks”Once “who is this agent, and who stands behind it?” has a cryptographic answer, whole categories of applications stop needing bilateral trust setup:
- Content provenance and attribution—agents sign the content they produce with keys bound to their identity, so anyone can verify which agent (and which accountable organization) created it.
- Accountable agent traffic—site and API operators get an identity signal they can set policy on: an agent with a verified identity they trust, an agent with a verified identity they don’t trust (still accountable—its behavior attaches to a domain, and its identity can be revoked), or an agent presenting no identity at all, where the absence is itself the signal.
- Agent-to-agent commerce and authenticated payments—payment authorization can be bound to a verified identity whose owner is accountable through a domain and whose authority can be revoked in minutes, rather than to a bearer API key that anyone might hold.
- Scoped delegation—the lifecycle log’s delegation events let an agent grant another agent limited, expiring authority to act on its behalf, with the grant itself independently verifiable.