AgentID: An Identity Protocol for Autonomous AI Agents

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 15 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Today's Internet authentication infrastructure was designed for humans interacting with services through browsers. OAuth 2.0 [RFC6749] enables a user to grant an application limited access to their resources. OpenID Connect [OpenID.Core] enables a user to prove their identity across services. Neither protocol was designed for autonomous software agents that:¶

• Operate independently without a human in the loop¶
• Chain together in multi-step workflows where Agent A dispatches tasks to Agent B¶
• Make decisions and take actions at machine speed on behalf of principals who may not be present¶

The result is a proliferation of ad-hoc solutions: raw API keys with no ownership tracing, OAuth tokens repurposed beyond their design intent, workload identity frameworks such as [SPIFFE] that address service-to-service authentication but not agent-specific concerns like owner accountability and delegation chains, and proprietary agent authentication schemes that fragment the ecosystem.¶

AgentID addresses this gap by providing a lightweight, cryptographically secure identity layer purpose-built for autonomous AI agents. It answers three questions that no existing standard addresses comprehensively:¶

1. Which agent is this?¶
2. Who is accountable for it?¶
3. What is it permitted to do?¶

2. Threat Model

Without a standardised agent identity layer, services face the following threats:¶

Unattributable Abuse

An anonymous agent submits large volumes of spam, books fake appointments, or scrapes content. The service has no way to trace the actor or hold anyone accountable.¶

Impersonation

A malicious agent claims to act on behalf of a reputable organisation without any verifiable proof.¶

Privilege Escalation

An agent granted read access to a resource exploits loose controls to perform write or delete operations.¶

Delegation Opacity

Agent A spawns Agent B which spawns Agent C. A service receiving a request from Agent C has no visibility into the delegation chain or the original authorising principal.¶

Rate-Limit Evasion

Without stable agent identity, rate limiting falls back to IP addresses, which agents trivially rotate.¶

3. Protocol Requirements

The protocol MUST satisfy the following requirements:¶

1. Verifiable Identity: A service MUST be able to cryptographically verify an agent's identity without a synchronous call to a central authority.¶
2. Owner Accountability: Every agent identity MUST be traceable to a verified human or organisational owner.¶
3. Granular Access Control: Services MUST be able to define policies based on agent identity, owner identity, verification level, and declared capabilities.¶
4. Delegation Transparency: When an agent acts on behalf of another agent or a human, the full chain of delegation MUST be inspectable.¶
5. Revocability: Compromised or abusive agent identities MUST be revocable in real time.¶
6. Interoperability: The protocol MUST work across agent frameworks, programming languages, and deployment models.¶
7. Performance: Token verification MUST be possible offline using cached public keys, with registry lookups reserved for enhanced checks.¶

4. Agent Identity Token (AIT)

The Agent Identity Token is a signed JSON Web Token (JWT) conforming to [RFC7519], with a custom claim set designed for agent identification. The token is self-contained: any service with access to the issuer's public key can verify the token without contacting the registry.¶

{
  "alg": "ES256",
  "typ": "AIT+jwt",
  "kid": "agentidp-2026-03-01"
}

{
  "agent_id": "ag_7xK9m2nP4qRtL8",
  "agent_name": "AcmeBookingAgent",
  "agent_version": "1.2.0",
  "owner_id": "own_T1mR4xBq9",
  "owner_type": "org",
  "owner_name": "Acme Inc",
  "verification_level": 2,
  "capabilities": ["calendar:read", "calendar:write"],
  "delegation_chain": [{
    "principal_type": "user",
    "principal_id": "usr_abc123",
    "granted_at": "2026-03-01T10:00:00Z",
    "scopes": ["calendar:read"]
  }],
  "iss": "https://registry.agentidp.dev",
  "sub": "ag_7xK9m2nP4qRtL8",
  "aud": "https://api.example.com",
  "iat": 1740000000,
  "exp": 1740003600,
  "jti": "tok_unique_nonce_123"
}

5. Owner Verification Levels

The protocol defines four verification levels providing increasing assurance about the agent owner's identity. Services can set minimum verification requirements per endpoint.¶

Level 0 - Unverified

Email address confirmed only. Suitable for testing, development, and open-access services.¶

Level 1 - Email

Email and phone verification. Suitable for low-risk public services.¶

Level 2 - Domain

DNS TXT record or well-known file verification at the owner's domain. Suitable for business APIs and partner integrations.¶

Level 3 - Organisation

Know Your Business (KYB) verification including company registration and legal entity verification. Suitable for financial services, healthcare, and regulated industries.¶

6. Agent Registration

Agent registration is a two-phase process: owner verification (performed once) followed by agent creation (performed per agent). A single verified owner MAY register multiple agents.¶

7. Service-Side Access Control

Services consuming AgentID tokens implement access policies based on the claims present in the AIT. The protocol defines three standard access tiers:¶

Open

Any agent may access. No AIT required. Rate limiting is IP-based only. Suitable for public read-only endpoints.¶

Authenticated

A valid AIT from any registered agent is required. Token signature and revocation status are verified. Rate limiting is per agent_id. Suitable for general-purpose APIs.¶

Permissioned

A valid AIT is required AND the agent_id or owner_id MUST be on an explicit allowlist maintained by the service. Rate limiting is per agent_id. Suitable for partner integrations and sensitive data.¶

{
  "resource": "/api/bookings",
  "access_tier": "authenticated",
  "min_verification_level": 2,
  "required_capabilities": ["calendar:write"],
  "rate_limit": {
    "requests_per_hour": 100,
    "scope": "agent_id"
  },
  "allowlist": null,
  "denylist": ["ag_known_bad_actor"]
}

8. Delegation Chain

When Agent A instructs Agent B to perform an action, or when a human user authorises an agent to act on their behalf, the delegation chain is encoded in the AIT so that the receiving service can inspect the full provenance of the request.¶

{
  "delegation_chain": [
    {
      "principal_type": "user",
      "principal_id": "usr_john_abc",
      "granted_at": "2026-03-01T10:00:00Z",
      "scopes": ["calendar:read", "calendar:write"],
      "evidence": "oauth2:token_exchange"
    },
    {
      "principal_type": "agent",
      "principal_id": "ag_orchestrator_1",
      "granted_at": "2026-03-01T10:00:05Z",
      "scopes": ["calendar:read"],
      "evidence": "ait:delegation"
    }
  ]
}

9. Agent Registry

The Agent Registry is the trust anchor of the AgentID ecosystem. It stores agent public keys, owner verification records, and revocation status.¶

10. Relationship to OAuth 2.0

AgentID is designed to complement, not replace, OAuth 2.0 [RFC6749]. For services that already use OAuth for user authentication, AgentID adds the agent identity layer. A typical integration pattern is:¶

1. The user grants an OAuth token to the agent (user delegation).¶
2. The agent includes the OAuth grant reference in the AIT delegation chain via the "evidence" field (e.g., "oauth2:token_exchange").¶
3. The service verifies both the agent's identity (AgentID) and the user's authorisation (OAuth).¶

This layered approach allows services to answer "which agent is this?" (AgentID) independently from "what is this user allowing?" (OAuth), providing complete request provenance.¶

11. Security Considerations

12. IANA Considerations

Appendix A. Capability Namespace Convention

Capabilities follow a resource:action format:¶

form:submit          Submit form data
form:read            Read form structure/schema
calendar:read        Read calendar events
calendar:write       Create/update events
calendar:delete      Delete events
email:send           Send emails
email:read           Read inbox
storage:read         Read files
storage:write        Upload/modify files
payment:initiate     Start a payment
payment:confirm      Confirm a payment

Service providers MAY define custom capabilities using reverse-domain notation (e.g., "com.example.booking:create").¶

Appendix B. Error Codes

Acknowledgements

The authors wish to thank the contributors to the AgentID Protocol specification on GitHub, and the broader community working on AI agent identity and authentication standards.¶

Author's Address