Trusted Agent Discovery: What DNS Can—and Cannot—Do
A practical architecture view of naming, identity, provenance and continuous verification for an agentic Internet.
Autonomous agents will need to discover services, prove identity, receive authorization and leave evidence that another system can verify. DNS is part of that story—but it is not the whole trust system.
Start with the role DNS already plays
DNS provides scalable, delegated naming. DNSSEC can protect the authenticity of DNS data, while records and discovery conventions can help clients locate services. That makes DNS valuable infrastructure for agent discovery.
What DNS does not establish by itself is whether an agent is currently authorized, whether its software is trustworthy, or whether a particular action fits policy and context.
Treat discovery and trust as separate layers
A practical architecture can separate five concerns:
- Naming: a stable way to refer to an agent or service.
- Discovery: a way to find current endpoints and capabilities.
- Identity: cryptographic proof of the workload or agent.
- Authorization: policy for a specific action and context.
- Evidence: provenance, logs and attestations for later verification.
Approaches such as ANS or AgentDNS may help structure discovery. Workload identity systems such as SPIFFE can strengthen runtime identity. Protocols such as MCP and A2A can carry capability and interaction context. None of them should be treated as a universal solution in isolation.
A useful direction
The strongest model is federated and layered: DNS and registries can anchor namespaces; issuers can establish workload identity; policy engines can authorize actions; and continuous signals can confirm that trust remains justified.
The design question is therefore not whether DNS can “handle” the agentic Internet alone. It is how DNS can remain a dependable part of a broader, continuously verifiable trust architecture.