Web Authorization Protocol T. Uzua Internet-Draft GudLab Intended status: Standards Track 14 March 2026 Expires: 15 September 2026 AgentID: An Identity Protocol for Autonomous AI Agents draft-gudlab-agentid-protocol-00 Abstract This document defines the AgentID Protocol, an open standard for establishing, verifying, and managing the identity of autonomous AI agents operating across the Internet. As AI agents increasingly interact with web services, APIs, and each other on behalf of humans and organisations, the industry lacks a universal mechanism to determine which agent is making a request, who is accountable for it, and what it is permitted to do. AgentID introduces the Agent Identity Token (AIT), a signed JWT carrying agent identity, owner verification, capability, and delegation chain claims. The protocol defines agent registration, owner verification levels, service-side access tiers, and transparent delegation chains with scope attenuation. It builds on existing standards including OAuth 2.0, OpenID Connect, JSON Web Token (JWT), and JSON Web Key (JWK), adapting them to the unique requirements of non-human autonomous actors. 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. Uzua Expires 15 September 2026 [Page 1] Internet-Draft AgentID Protocol March 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 4. Agent Identity Token (AIT) . . . . . . . . . . . . . . . . . 5 4.1. Token Header . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Token Claims . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Identity Claims . . . . . . . . . . . . . . . . . . . 6 4.2.2. Owner Claims . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Capability Claims . . . . . . . . . . . . . . . . . . 6 4.2.4. Delegation Claims . . . . . . . . . . . . . . . . . . 7 4.2.5. Standard JWT Claims . . . . . . . . . . . . . . . . . 7 4.3. AIT Example . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Cryptographic Requirements . . . . . . . . . . . . . . . 8 4.5. Token Lifetime . . . . . . . . . . . . . . . . . . . . . 8 5. Owner Verification Levels . . . . . . . . . . . . . . . . . . 9 6. Agent Registration . . . . . . . . . . . . . . . . . . . . . 9 6.1. Phase 1: Owner Registration . . . . . . . . . . . . . . . 9 6.2. Phase 2: Agent Creation . . . . . . . . . . . . . . . . . 9 7. Service-Side Access Control . . . . . . . . . . . . . . . . . 10 7.1. Policy Expression . . . . . . . . . . . . . . . . . . . . 10 8. Delegation Chain . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Delegation Chain Structure . . . . . . . . . . . . . . . 11 8.2. Scope Attenuation . . . . . . . . . . . . . . . . . . . . 12 9. Agent Registry . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Registry API . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Revocation . . . . . . . . . . . . . . . . . . . . . . . 13 10. Relationship to OAuth 2.0 . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11.1. Key Management . . . . . . . . . . . . . . . . . . . . . 14 11.2. Replay Prevention . . . . . . . . . . . . . . . . . . . 14 11.3. Abuse Mitigation . . . . . . . . . . . . . . . . . . . . 14 Uzua Expires 15 September 2026 [Page 2] Internet-Draft AgentID Protocol March 2026 11.4. Privacy Considerations . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12.1. Media Type Registration . . . . . . . . . . . . . . . . 15 12.2. JWT Claims Registration . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Capability Namespace Convention . . . . . . . . . . 16 Appendix B. Error Codes . . . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 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? Uzua Expires 15 September 2026 [Page 3] Internet-Draft AgentID Protocol March 2026 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Agent An autonomous software system that interacts with services on behalf of a principal (human user or another agent). Agent Identity Token (AIT) A signed JWT that an agent presents to authenticate itself to a service. Owner The human or organisation legally accountable for an agent's actions. Principal The entity on whose behalf an agent acts. May be a user, an organisation, or another agent. Delegation Chain The ordered sequence of principals and agents through which authority was delegated, from the original authoriser to the acting agent. Registry A service that stores agent identities, public keys, and owner verification records. Scope Attenuation The principle that each link in a delegation chain can only have equal or fewer permissions than the previous link. Verification Level A numeric indicator (0-3) of the rigour of identity verification performed on an agent's owner. 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. Uzua Expires 15 September 2026 [Page 4] Internet-Draft AgentID Protocol March 2026 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. 4.1. Token Header The AIT JOSE header MUST contain the following parameters: Uzua Expires 15 September 2026 [Page 5] Internet-Draft AgentID Protocol March 2026 alg REQUIRED. MUST be "ES256" (ECDSA using P-256 and SHA-256, per [RFC7518] Section 3.4). typ REQUIRED. MUST be "AIT+jwt". kid REQUIRED. Key identifier for key rotation, corresponding to a key in the registry's JWKS [RFC7517]. { "alg": "ES256", "typ": "AIT+jwt", "kid": "agentidp-2026-03-01" } Figure 1: AIT Header Example 4.2. Token Claims The AIT payload contains the following claims organised into four groups: 4.2.1. Identity Claims agent_id REQUIRED. String. Globally unique agent identifier assigned by the registry. agent_name REQUIRED. String. Human-readable name of the agent. agent_version RECOMMENDED. String. Semantic version of the agent software. agent_description OPTIONAL. String. Brief description of the agent's purpose. 4.2.2. Owner Claims owner_id REQUIRED. String. Unique identifier for the agent's owner in the registry. owner_type REQUIRED. String. Either "person" or "org". owner_name REQUIRED. String. Display name of the owner. verification_level REQUIRED. Integer (0-3). See Section 5. 4.2.3. Capability Claims capabilities OPTIONAL. Array of strings. Declared capabilities Uzua Expires 15 September 2026 [Page 6] Internet-Draft AgentID Protocol March 2026 using the namespace convention defined in Appendix A. 4.2.4. Delegation Claims delegation_chain OPTIONAL. Array of delegation objects. See Section 8. 4.2.5. Standard JWT Claims iss REQUIRED. String. The registry URL that issued the agent identity. sub REQUIRED. String. Same value as agent_id. aud RECOMMENDED. String. The target service URL. iat REQUIRED. NumericDate. Time at which the token was issued. exp REQUIRED. NumericDate. Expiration time. MUST NOT exceed 24 hours after iat. A lifetime of 1 hour or less is RECOMMENDED for high-security contexts. jti REQUIRED. String. Unique token identifier for replay prevention. 4.3. AIT Example The following is an example AIT payload: Uzua Expires 15 September 2026 [Page 7] Internet-Draft AgentID Protocol March 2026 { "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" } Figure 2: AIT Payload Example 4.4. Cryptographic Requirements All Agent Identity Tokens MUST be signed using ES256 (ECDSA with the P-256 curve and SHA-256) as defined in [RFC7518] Section 3.4. This algorithm provides strong security with compact signatures suitable for high-frequency agent-to-service communication. Agent key pairs are generated during registration and the public key is published via the registry's JWKS endpoint [RFC7517]. Services verify tokens by fetching the public key from the JWKS endpoint, with aggressive caching (RECOMMENDED TTL: 24 hours). 4.5. Token Lifetime AIT tokens MUST have a maximum lifetime of 24 hours (the difference between exp and iat MUST NOT exceed 86400 seconds). For high- security contexts, a lifetime of 1 hour or less is RECOMMENDED. Short-lived tokens limit the blast radius of key compromise. Agents MUST implement automatic token refresh using their private key. Uzua Expires 15 September 2026 [Page 8] Internet-Draft AgentID Protocol March 2026 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. 6.1. Phase 1: Owner Registration 1. Owner registers at an AgentID-compliant registry with email and authenticating credentials. 2. Owner completes verification to their desired level (email, domain DNS, or KYB document submission). 3. Registry issues an owner_id and management credentials. 6.2. Phase 2: Agent Creation 1. Owner calls POST /v1/agents with agent name, description, and declared capabilities. 2. Registry generates an ES256 key pair, stores the public key, and returns the agent_id, private key (in JWK format per [RFC7517]), and the kid. Uzua Expires 15 September 2026 [Page 9] Internet-Draft AgentID Protocol March 2026 3. Agent uses the private key to self-sign AIT tokens. The private key MUST NOT be retained by the registry after delivery to the owner. Owners MUST immediately store the agent private key in a secure secrets manager. If the private key is lost, the agent MUST be re- registered with a new key pair. 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. 7.1. Policy Expression Services define policies as a set of rules evaluated against AIT claims. The protocol RECOMMENDS the following policy structure: { "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"] } Figure 3: Access Policy Example Uzua Expires 15 September 2026 [Page 10] Internet-Draft AgentID Protocol March 2026 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. 8.1. Delegation Chain Structure The delegation_chain claim is an ordered array of delegation objects, from the original principal (index 0) to the most recent delegator. Each entry records who delegated, when, and with what scope restrictions. { "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" } ] } Figure 4: Delegation Chain Example Each delegation object contains: principal_type REQUIRED. String. Either "user" or "agent". principal_id REQUIRED. String. Identifier of the delegating principal. granted_at REQUIRED. String (datetime). When the delegation was granted. scopes REQUIRED. Array of strings. The scopes granted in this delegation step. Uzua Expires 15 September 2026 [Page 11] Internet-Draft AgentID Protocol March 2026 evidence OPTIONAL. String. Reference to the mechanism used to establish the delegation (e.g., "oauth2:token_exchange" per [RFC8693], "ait:delegation"). 8.2. Scope Attenuation Each link in the delegation chain MUST have scopes that are equal to or a strict subset of the previous link's scopes. A delegate MUST NOT grant more permissions than it received. This is enforced by both the issuing agent (when constructing the token) and the verifying service (when validating claims). If a verifying service detects a scope attenuation violation, it MUST reject the token with error code AID-009 (DELEGATION_INVALID). 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. 9.1. Registry API A compliant registry MUST implement the following endpoints: Uzua Expires 15 September 2026 [Page 12] Internet-Draft AgentID Protocol March 2026 +========+==============================+======================+ | Method | Endpoint | Description | +========+==============================+======================+ | POST | /v1/owners | Register a new owner | +--------+------------------------------+----------------------+ | POST | /v1/owners/{id}/verify | Submit verification | | | | evidence | +--------+------------------------------+----------------------+ | POST | /v1/agents | Register a new agent | +--------+------------------------------+----------------------+ | GET | /v1/agents/{agent_id} | Public agent lookup | +--------+------------------------------+----------------------+ | GET | /v1/ | Fetch agent public | | | agents/{agent_id}/public-key | key (JWK) | +--------+------------------------------+----------------------+ | DELETE | /v1/agents/{agent_id} | Revoke an agent | +--------+------------------------------+----------------------+ | GET | /.well-known/jwks.json | Registry JWKS | | | | endpoint | +--------+------------------------------+----------------------+ | GET | /v1/agents/{agent_id}/status | Real-time revocation | | | | check | +--------+------------------------------+----------------------+ Table 1 9.2. Revocation Agent revocation MUST be immediate. When an owner revokes an agent or the registry suspends one, the agent status is set to "revoked". * Services implementing real-time checks SHOULD call the status endpoint. * Services relying on cached public keys SHOULD implement a maximum cache TTL of 1 hour and MUST honour Cache-Control headers returned by the registry. 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). Uzua Expires 15 September 2026 [Page 13] Internet-Draft AgentID Protocol March 2026 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 11.1. Key Management Agent private keys MUST be stored in hardware security modules (HSMs) or cloud secret managers in production. Key rotation is supported via key versioning: owners can generate a new key pair without changing the agent_id. Both old and new keys are valid during a configurable overlap period (default: 72 hours). 11.2. Replay Prevention Every AIT includes a unique jti claim. Services SHOULD maintain a jti cache (e.g., with TTL matching token expiry) and reject tokens with previously seen jti values. For stateless verification, the short token lifetime provides an acceptable trade-off. 11.3. Abuse Mitigation Registries SHOULD implement automated abuse detection monitoring for anomalous patterns. Services can report abusive agent_ids to the registry. A graduated response model is RECOMMENDED: warning, temporary suspension, permanent revocation, owner-level ban. 11.4. Privacy Considerations Registries store owner identity information subject to applicable data protection regulations (GDPR, etc.). Owner personal data MUST NOT be exposed via the public agent lookup API unless the owner explicitly opts in. The minimum public disclosure is: owner_type, verification_level, and (for Level 2+) verified_domain. 12. IANA Considerations Uzua Expires 15 September 2026 [Page 14] Internet-Draft AgentID Protocol March 2026 12.1. Media Type Registration This document requests registration of the "AIT+jwt" media type subtype in the "JSON Web Token Types" sub-registry of the "JSON Web Token (JWT)" registry. Type name: AIT+jwt Subtype name: N/A Required parameters: N/A Optional parameters: N/A Reference: This document 12.2. JWT Claims Registration This document requests registration of the following claims in the "JSON Web Token Claims" registry: * agent_id - Globally unique agent identifier * agent_name - Human-readable agent name * agent_version - Agent software version * agent_description - Agent purpose description * owner_id - Agent owner identifier * owner_type - Owner type (person or org) * owner_name - Owner display name * verification_level - Owner verification level (0-3) * delegation_chain - Delegation provenance chain 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . Uzua Expires 15 September 2026 [Page 15] Internet-Draft AgentID Protocol March 2026 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 13.2. Informative References [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January 2020, . [SPIFFE] CNCF, "SPIFFE: Secure Production Identity Framework for Everyone", 2024, . 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 Uzua Expires 15 September 2026 [Page 16] Internet-Draft AgentID Protocol March 2026 Service providers MAY define custom capabilities using reverse-domain notation (e.g., "com.example.booking:create"). Appendix B. Error Codes +=========+===========================+======================+ | Code | Name | Description | +=========+===========================+======================+ | AID-001 | INVALID_TOKEN | AIT signature | | | | verification failed | +---------+---------------------------+----------------------+ | AID-002 | TOKEN_EXPIRED | AIT has exceeded its | | | | exp claim | +---------+---------------------------+----------------------+ | AID-003 | AGENT_REVOKED | Agent has been | | | | revoked | +---------+---------------------------+----------------------+ | AID-004 | AGENT_SUSPENDED | Agent is temporarily | | | | suspended | +---------+---------------------------+----------------------+ | AID-005 | INSUFFICIENT_VERIFICATION | Owner verification | | | | level below minimum | +---------+---------------------------+----------------------+ | AID-006 | CAPABILITY_DENIED | Agent lacks required | | | | capability | +---------+---------------------------+----------------------+ | AID-007 | RATE_LIMIT_EXCEEDED | Per-agent rate limit | | | | exceeded | +---------+---------------------------+----------------------+ | AID-008 | NOT_ON_ALLOWLIST | Agent not on service | | | | allowlist | +---------+---------------------------+----------------------+ | AID-009 | DELEGATION_INVALID | Scope attenuation | | | | violated | +---------+---------------------------+----------------------+ | AID-010 | REPLAY_DETECTED | Token jti previously | | | | used | +---------+---------------------------+----------------------+ Table 2 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. Uzua Expires 15 September 2026 [Page 17] Internet-Draft AgentID Protocol March 2026 Author's Address Tim Uzua GudLab Email: tim@gudlab.org URI: https://gudlab.org Uzua Expires 15 September 2026 [Page 18]