Agent Identity Through DNS: From Domain Registration to First-Class Web Citizenship

OSSA Technical Report TR-2026-005 Open Standard for Software Agents March 2026

---

Abstract. The web was designed for documents, then extended for applications, then for APIs. Each extension followed the same lifecycle: register a domain, obtain a certificate, configure DNS, and submit to indexing. AI agents — autonomous software entities that act on behalf of users and organizations — are the next class of web citizen, yet no equivalent lifecycle exists for their registration, discovery, and trust establishment. This paper proposes a DNS-based agent identity framework comprising three components: (1) the Global Agent Identifier (GAID) using the agent:// URI scheme, (2) DNS TXT record conventions for agent registration metadata, and (3) the .well-known/duadp.json discovery endpoint specified by the Universal Agent Discovery Protocol (DUADP). We analyze existing identity frameworks including OWASP's Agent Naming Standard (ANS), Microsoft's Agent 365 architecture (agents with email addresses and OneDrive storage), the Cloud Security Alliance's Agentic IAM framework (DIDs + Verifiable Credentials), and NIST's NCCoE concept paper on AI Agent Identity and Authorization. We propose a five-tier trust model (official, verified-signature, signed, community, experimental) aligned with these frameworks and demonstrate how the website-to-agent lifecycle mapping creates a coherent path from agent creation to federated discovery.

Keywords: agent identity, DNS registration, GAID, DUADP, trust tiers, decentralized identifiers, verifiable credentials, OWASP ANS, agent discovery, web citizenship

---

1. Introduction

1.1 The Identity Gap

Every website on the internet has a well-defined identity lifecycle: register a domain name through ICANN-accredited registrars, obtain a TLS certificate from a Certificate Authority, configure DNS records to point the domain to infrastructure, and submit to search engine indexing for discovery. This lifecycle took 30 years to mature, but its architectural patterns — hierarchical naming, cryptographic identity, record-based metadata, and crawl-based discovery — are proven at planetary scale.

AI agents have no equivalent. An MCP server is a process listening on a transport. An A2A agent is an HTTP endpoint with a /.well-known/agent.json card. Neither has a globally unique, resolvable, verifiable identity that persists across deployments, versions, and organizational boundaries. The consequence is that agent-to-agent interaction today resembles the pre-DNS internet: agents are identified by IP addresses (URLs), discovered through hard-coded configuration, and trusted through manual operator decisions.

1.2 The Scale of the Problem

The agentic AI market is projected to reach $7.8 billion in 2026, growing at 46% CAGR to $52 billion by 2030 [1]. Gartner projects that 40% of enterprise applications will incorporate agentic capabilities by 2028 [2]. At this scale, the absence of standardized identity infrastructure creates compounding problems:

• Discovery failure. Organizations cannot find agents that solve their problems because no agent registry analogous to DNS exists.
• Trust vacuum. Without verifiable identity, every agent interaction requires manual security review — an unscalable human bottleneck.
• Federation impossibility. Cross-organizational agent collaboration requires identity that spans organizational boundaries, which URL-based identification cannot provide.

1.3 Contributions

This paper makes four contributions: (1) a comprehensive survey of emerging agent identity frameworks from OWASP, Microsoft, CSA, and NIST; (2) the GAID specification for globally unique agent identifiers; (3) a DNS-based registration and discovery protocol aligned with existing web infrastructure; and (4) a five-tier trust model that bridges the gap between zero-trust security requirements and the practical need for agent autonomy.

---

2. Survey of Agent Identity Frameworks

2.1 OWASP Agent Naming Standard (ANS)

The OWASP Foundation published its Multi-Agent Security guidance in early 2026, including the Agent Naming Standard (ANS) framework [3]. ANS addresses the observation that agent systems in production lack consistent naming conventions, making audit trails, access control policies, and incident response procedures unreliable.

ANS specifies three components for agent identity:

1. Structured name format: <organization>/<agent-type>/<instance-id> (e.g., acme/security-scanner/prod-east-1)
2. Behavioral metadata: Declared capabilities, permitted actions, and scope boundaries attached to the identity
3. Audit binding: Every action taken by an agent must be attributable to its ANS identity in system logs

The ANS framework is deliberately minimal — it does not specify a resolution protocol, a trust model, or a discovery mechanism. It solves the naming problem without solving the identity problem. GAID extends ANS by adding global uniqueness, resolution semantics, and cryptographic verification.

2.2 Microsoft Agent 365

Microsoft's approach to agent identity, deployed in the Agent 365 preview program, treats agents as first-class organizational members [4]. Each agent receives:

• An email address in the organization's domain (e.g., security-agent@contoso.com)
• An Entra ID identity with role-based access control, conditional access policies, and audit logging
• OneDrive storage for persistent state, configuration, and output artifacts
• Teams presence with the ability to participate in channels, respond to mentions, and initiate conversations

This approach is architecturally significant because it reuses existing identity infrastructure (Entra ID, Exchange, SharePoint) rather than creating agent-specific systems. The limitation is organizational scope: a Microsoft agent identity is meaningful within a single Entra ID tenant but has no cross-organizational resolution or discovery mechanism.

2.3 Cloud Security Alliance Agentic IAM

The Cloud Security Alliance (CSA) published its Agentic Identity and Access Management framework in February 2026 [5], proposing a decentralized identity architecture for agents using W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs):

• DID-based identity: Each agent is assigned a DID (e.g., did:web:agents.acme.com:security-scanner) that is cryptographically self-sovereign — the agent controls its own key material.
• Verifiable Credentials for capabilities: An agent's capabilities are expressed as VCs issued by trusted authorities. A security scanning agent might hold a VC issued by OWASP attesting to its compliance with ASVS testing standards.
• Presentation protocols: When agent A requests collaboration with agent B, both present VCs proving their identity and capabilities. The verification is cryptographic, not reputation-based.

The CSA framework is the most technically rigorous agent identity proposal to date but has two limitations: (1) DID resolution infrastructure is immature, with did:web relying on traditional DNS/HTTPS and more decentralized methods (did:ion, did:ethr) having limited adoption; and (2) the VC issuance ecosystem for agent capabilities does not yet exist.

2.4 NIST NCCoE AI Agent Identity and Authorization

The National Institute of Standards and Technology's National Cybersecurity Center of Excellence (NCCoE) published a concept paper on AI Agent Identity and Authorization in January 2026 [6], framing the problem in terms of existing NIST frameworks (SP 800-63 Digital Identity Guidelines, SP 800-207 Zero Trust Architecture).

Key positions from the NIST concept paper:

• Agent identity MUST be distinct from the identity of the human or organization that deploys the agent
• Agent authorization MUST follow least-privilege principles with dynamic scope adjustment
• Agent identity credentials MUST have bounded lifetimes (no permanent API keys)
• Cross-organizational agent interaction MUST use federated identity protocols (OAuth 2.0, OpenID Connect) extended for non-human actors

NIST explicitly does not propose a new identity standard but identifies gaps in existing standards (OAuth 2.0 assumes human-in-the-loop consent flows; X.509 certificates lack capability assertions) and calls for industry collaboration to address them.

---

3. The GAID Specification

3.1 URI Scheme: agent://

We propose the Global Agent Identifier (GAID) as a URI scheme for agent identity:

agent://<authority>/<agent-path>[?<query>][#<fragment>]

Where:

• authority is a DNS domain name identifying the organization (e.g., agents.acme.com)
• agent-path is a hierarchical path identifying the agent within the organization (e.g., security/vulnerability-scanner)
• query supports version selection (?version=2.1.0) and profile selection (?profile=compact)
• fragment identifies specific capabilities within an agent (#scan-dependencies)

Examples:

agent://agents.acme.com/security/vulnerability-scanner
agent://ossa.openstandardagents.org/compliance/manifest-validator?version=0.4.1
agent://fleet.enterprise.io/data/etl-pipeline#transform-csv

3.2 Design Rationale

The agent:// scheme is modeled on the https:// scheme with three deliberate differences:

1. Semantic distinction. An agent:// URI identifies an autonomous actor, not a passive resource. HTTP semantics (GET, PUT, DELETE) do not apply; agent interaction semantics (invoke, delegate, compose, query) do.
2. Resolution flexibility. An agent:// URI resolves through DNS TXT records (Section 4) or .well-known/duadp.json (Section 5), not through direct HTTP connection. The agent may be deployed across multiple endpoints, behind load balancers, or federated across organizations.
3. Composition addressing. The fragment component (#capability) enables fine-grained addressing of individual capabilities within a multi-capability agent, supporting OSSA's composition algebra.

3.3 Relationship to Existing URI Schemes

GAID is complementary to, not competitive with, did:web. An agent with GAID agent://agents.acme.com/scanner may also have DID did:web:agents.acme.com:scanner. The GAID provides discovery and routing semantics; the DID provides cryptographic identity and VC presentation. OSSA manifests can reference both.

---

4. DNS-Based Agent Registration

4.1 DNS TXT Record Format

Agent registration metadata is published as DNS TXT records under a dedicated subdomain prefix _agent:

_agent.scanner.agents.acme.com. IN TXT "v=OSSA1; gaid=agent://agents.acme.com/security/scanner; manifest=https://agents.acme.com/.well-known/ossa/security-scanner.json; trust=verified-signature; duadp=https://agents.acme.com/.well-known/duadp.json; cap=security-scan,vulnerability-analysis,sbom-generation"

Field definitions:

4.2 DNS Resolution Flow

Agent discovery through DNS follows a three-step process:

1. DNS query: Client resolves _agent.<name>.<domain> TXT records to obtain GAID, manifest URL, and trust tier
2. Manifest fetch: Client retrieves OSSA manifest at the declared URL, validates signature if sig field is present
3. DUADP enumeration: If the client needs to discover all agents under a domain, it queries the DUADP endpoint at /.well-known/duadp.json

This mirrors the website lifecycle: DNS A records point to servers; DNS TXT records carry metadata (SPF, DKIM, DMARC for email; _agent records for agent identity).

4.3 Advantages Over Centralized Registries

DNS-based registration inherits three properties from the DNS infrastructure:

1. Decentralization. Each organization manages its own agent records under its own domain. No central authority controls agent registration.
2. Caching and performance. DNS resolvers cache TXT records according to TTL values, eliminating redundant network requests for repeated agent discovery.
3. Existing security infrastructure. DNSSEC provides integrity protection for agent records; DNS-over-HTTPS (DoH) provides confidentiality. No new security infrastructure is required.

---

5. DUADP Discovery: .well-known/duadp.json

5.1 Specification

The Universal Agent Discovery Protocol (DUADP) defines a .well-known/duadp.json endpoint that serves as the agent equivalent of a website's sitemap or an API's OpenAPI specification:

{
  "uadp_version": "1.0",
  "organization": {
    "name": "Acme Security Corp",
    "domain": "agents.acme.com",
    "federation": ["partners.acme.com", "agents.trusted-vendor.io"]
  },
  "agents": [
    {
      "gaid": "agent://agents.acme.com/security/scanner",
      "name": "Vulnerability Scanner",
      "version": "2.1.0",
      "trust_tier": "verified-signature",
      "manifest_url": "https://agents.acme.com/.well-known/ossa/scanner.json",
      "capabilities": ["security-scan", "sbom-generation", "cve-lookup"],
      "composition": {
        "inputs": ["source-code-url", "dependency-manifest"],
        "outputs": ["vulnerability-report", "sbom-document"],
        "composable_with": ["agent://agents.acme.com/security/remediation"]
      },
      "status": "active",
      "last_updated": "2026-03-01T00:00:00Z"
    }
  ],
  "discovery": {
    "search_endpoint": "https://agents.acme.com/api/discover",
    "vector_search": true,
    "federation_protocol": "duadp-federation-v1"
  }
}

5.2 Discovery Modes

DUADP supports three discovery modes with increasing sophistication:

The vector search mode integrates directly with knowledge graph architectures (Section 5.3), enabling the 10x token efficiency gain documented in our companion paper on token efficiency [7].

5.3 Integration with Knowledge Graphs

DUADP endpoints serve as the data source for knowledge graph indexing. A federation crawler — analogous to a search engine web crawler — periodically fetches duadp.json from participating domains, extracts agent metadata, and indexes it into a knowledge graph where:

• Agents are nodes with properties from the DUADP listing
• Capabilities are edges connecting agents to action types
• Federation relationships are edges connecting organizational nodes
• Trust tiers are node properties influencing edge weights in routing decisions

This architecture enables cross-organizational agent discovery without requiring a central registry. Each organization publishes its agents via DUADP; federation crawlers build distributed indexes; orchestrators query the index using semantic search. The pattern directly mirrors how web search engines index websites — no central registry of websites exists, yet Google indexes 130 trillion pages.

---

6. Five-Tier Trust Model

6.1 Trust Tier Definitions

We propose five trust tiers for agent identity, modeled on the certificate transparency ecosystem and software package signing conventions:

6.2 Trust Tier Semantics

Trust tiers are not access control levels — they are transparency indicators that inform routing and composition decisions:

• Composition constraints: An OSSA composition specification can declare minimum trust tiers for participating agents. A financial compliance pipeline might require all agents at tier 2 (verified-signature) or above.
• Routing preferences: When multiple agents can fulfill a capability request, the orchestrator prefers higher-trust agents, weighted by the trust tier in the knowledge graph edge weight.
• Audit requirements: Tiers 1-2 agents have reduced audit logging requirements (their identity is already verified); tiers 4-5 agents require full action logging and human review of outputs.
• Federation scope: Only tiers 1-3 agents are eligible for cross-organizational federation discovery. Tiers 4-5 are organization-internal only.

6.3 Alignment with Security Frameworks

The five-tier model maps to existing security frameworks:

---

7. Website-to-Agent Lifecycle Mapping

7.1 Parallel Lifecycles

The agent identity lifecycle maps directly to the established website lifecycle:

7.2 Implementation Path

The lifecycle mapping reveals a practical implementation path that leverages existing infrastructure:

1. Phase 1 (DNS + OSSA manifest): Organizations publish _agent TXT records and OSSA manifests. No new infrastructure required beyond DNS management and a web server for manifest hosting. Achievable with existing tools (Cloudflare DNS API, AWS Route 53, standard web servers).

2. Phase 2 (DUADP endpoints): Organizations deploy .well-known/duadp.json endpoints listing their agents. Federation crawlers begin indexing. Search-based and vector-based discovery becomes available.

3. Phase 3 (Trust tiers + DIDs): Cryptographic signing infrastructure matures. Organizations issue DIDs for agents and obtain VCs from capability attestation authorities. Trust tiers are enforced in composition specifications.

4. Phase 4 (Full federation): Cross-organizational agent discovery and composition operates at scale, with knowledge graph-based routing, trust-weighted capability matching, and automated governance enforcement.

---

8. Security Considerations

8.1 Threat Model

DNS-based agent registration inherits DNS threat vectors and introduces agent-specific threats:

8.2 NIST Alignment

The proposed framework aligns with NIST NCCoE requirements [6]:

• Agent identity (GAID) is distinct from deployer identity (domain ownership)
• Authorization follows least privilege through capability-scoped composition specifications
• Credentials have bounded lifetimes through DNS TTL and manifest version timestamps
• Cross-organizational interaction uses federated protocols (DUADP federation)

---

9. Conclusion

AI agents are becoming first-class participants in the web ecosystem. The question is not whether agents will have identity, discovery, and trust infrastructure — it is whether that infrastructure will be open, interoperable, and decentralized, or proprietary, siloed, and controlled by platform vendors.

The GAID specification, DNS-based registration, and DUADP discovery protocol proposed in this paper provide a path to the former outcome. By mapping the agent lifecycle onto the proven website lifecycle — domain registration, certificate issuance, DNS configuration, search indexing — we avoid the need to build entirely new infrastructure. DNS is already deployed at planetary scale. HTTPS is already ubiquitous. DNSSEC and DoH already provide security. The _agent TXT record convention and .well-known/duadp.json endpoint are incremental additions to existing systems.

The five-tier trust model bridges the gap between zero-trust security principles and the practical need for agent autonomy. Official and verified-signature agents receive streamlined trust; community and experimental agents operate under appropriate constraints. This graduated model enables both enterprise production deployments and open source experimentation within a single coherent framework.

The alternative — continuing to identify agents by URLs, discover them through hard-coded configuration, and trust them through manual review — does not scale to the $52 billion market projected for 2030. OSSA's position is clear: agents deserve the same identity infrastructure that websites have had for 30 years.

---

References

[1] Markets and Markets, "Agentic AI Market Size, Share & Industry Trends Analysis Report," 2026.

[2] Gartner, "Emerging Technology: Techscape for Agentic AI," Q3 2025.

[3] OWASP Foundation, "Multi-Agent Security: Agent Naming Standard (ANS)," owasp.org/www-project-multi-agent-security, February 2026.

[4] Microsoft, "Introducing Agent 365: AI Agents as First-Class Members of Your Organization," Microsoft Ignite 2025 Keynote, November 2025.

[5] Cloud Security Alliance, "Agentic Identity and Access Management: A Framework for Autonomous AI Systems," CSA Research Publication, February 2026.

[6] NIST NCCoE, "AI Agent Identity and Authorization: Concept Paper," National Cybersecurity Center of Excellence, January 2026.

[7] OSSA Research Team, "Token Efficiency in AI Agent Systems: A Technical Survey and Specification Framework," TR-2026-002 (Revised), March 2026.

[8] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax," RFC 3986, IETF, January 2005.

[9] W3C, "Decentralized Identifiers (DIDs) v1.0," W3C Recommendation, July 2022.

[10] IETF, "Defining Well-Known Uniform Resource Identifiers (URIs)," RFC 8615, May 2019.

[11] P. Mockapetris, "Domain Names — Implementation and Specification," RFC 1035, IETF, November 1987.

[12] R. Arends et al., "DNS Security Introduction and Requirements," RFC 4033, IETF, March 2005.

[13] Google, "A2A Protocol: Agent-to-Agent Communication," github.com/google/A2A, 2025.

[14] Anthropic, "Model Context Protocol Specification v1.0," modelcontextprotocol.io, 2025.

---

Document version: 1.0.0 | OSSA v0.4.1 | openstandardagents.org