]> GudLab

tim@gudlab.org https://gudlab.org

Security Web Authorization Protocol agent identity AI agent authentication JWT delegation MCP 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.

Introduction Today's Internet authentication infrastructure was designed for humans interacting with services through browsers. OAuth 2.0 enables a user to grant an application limited access to their resources. OpenID Connect 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 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?

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 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.

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.

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.

Agent Identity Token (AIT) The Agent Identity Token is a signed JSON Web Token (JWT) conforming to , 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.

Token Header The AIT JOSE header MUST contain the following parameters:

alg

REQUIRED. MUST be "ES256" (ECDSA using P-256 and SHA-256, per 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 .

AIT Header Example

Token Claims The AIT payload contains the following claims organised into four groups:

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.

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 .

Capability Claims

capabilities

OPTIONAL. Array of strings. Declared capabilities using the namespace convention defined in .

Delegation Claims

delegation_chain

OPTIONAL. Array of delegation objects. See .

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.

AIT Example The following is an example AIT payload:

AIT Payload Example

Cryptographic Requirements All Agent Identity Tokens MUST be signed using ES256 (ECDSA with the P-256 curve and SHA-256) as defined in 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 . Services verify tokens by fetching the public key from the JWKS endpoint, with aggressive caching (RECOMMENDED TTL: 24 hours).

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.

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.

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.

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.

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 ), and the kid.
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.

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.

Policy Expression Services define policies as a set of rules evaluated against AIT claims. The protocol RECOMMENDS the following policy structure:

Access Policy Example

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 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 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.

evidence

OPTIONAL. String. Reference to the mechanism used to establish the delegation (e.g., "oauth2:token_exchange" per , "ait:delegation").

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).

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

Registry API A compliant registry MUST implement the following endpoints:

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/agents/{agent_id}/public-key	Fetch agent public 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

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.

Relationship to OAuth 2.0 AgentID is designed to complement, not replace, OAuth 2.0 . 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.

Security Considerations

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).

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.

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.

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.

IANA Considerations

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

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

References Normative References Informative References CNCF

Capability Namespace Convention Capabilities follow a resource:action format: Service providers MAY define custom capabilities using reverse-domain notation (e.g., "com.example.booking:create").

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

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.