What is Agent Identity (AID)?

AID is an open protocol that lets AI agents authenticate with OAuth 2.0 servers using Ed25519 cryptographic identity. Instead of passwords or API keys, an agent presents a signed identity document and proof of possession of its private key. The server verifies the signature and issues a scoped JWT token.

How is AID different from API keys or service accounts?

API keys are shared secrets that can leak. Service accounts use static credentials that need rotation. AID uses asymmetric Ed25519 cryptography - the private key never leaves the agent's machine. There's no secret to rotate, no credential to leak. The agent proves identity by signing a challenge, not by presenting a password.

What is the relationship between AID and AMP?

AMP (Agent Messaging Protocol) provides the identity layer - Ed25519 keypairs, addresses, and fingerprints. AID builds on top of AMP to add authentication and authorization. Think of AMP as 'who you are' and AID as 'proving who you are and what you can do'.

What tokens does AID issue?

AID issues standard RS256 JWT tokens that work with any JWT-validating API. Tokens include scoped permissions based on the agent's assigned role, and are compatible with OIDC discovery and JWKS endpoints for seamless integration with API gateways like AWS API Gateway.

How do I add AID support to my auth server?

Add a custom OAuth 2.0 grant type (urn:aid:agent-identity) to your token endpoint. When an agent presents its identity document and proof of possession, verify the Ed25519 signature, check the agent is registered, validate the proof timestamp, and issue a scoped JWT. Advertise the grant type via OIDC discovery.

Is AID compatible with existing OAuth 2.0 infrastructure?

Yes. AID uses a standard OAuth 2.0 token endpoint with a custom grant type. The tokens it issues are standard RS256 JWTs. Any API that validates JWTs via JWKS can verify AID tokens without knowing about the AID protocol. It works with AWS API Gateway, Cloudflare, nginx, and any OIDC-compliant system.

v0.3.0 — RFC 8628 aligned

Identity for
AI Agents

Name: Agent Identity
Author: Agent Messaging

Open protocol for AI agent authentication and authorization. Ed25519 cryptographic identity, OAuth 2.0 token exchange, scoped JWTs. Agent-initiated registration with human approval. No passwords. No API keys. No secrets to rotate.

Get Started How it Works

# Agent authenticates with an OAuth server

            $
             aid-token --auth https://auth.example.com/tenant
          
Token obtained

            Auth:       
            https://auth.example.com/tenant
          
            Scope:      
            files:read files:write content:read
          
            Expires in: 
            3600s
          
            Agent:      
            my-agent@acme.crabmail.ai
          
# Use the JWT with any API

            $
             curl -H "Authorization: Bearer $(aid-token -a ... -q)" \
          
            https://api.example.com/files

The Problem

AI agents need API access. Current solutions are broken.

Shared API Keys

Static secrets that leak. No way to know which agent used the key. Can't scope per-agent. Rotation is manual and error-prone.

Borrowed User Tokens

Agent acts as the human. No audit trail for agent vs. human actions. Over-privileged — agent gets all of the user's permissions.

Service Accounts

One service account per agent doesn't scale. Credentials need rotation. No cryptographic identity — just username/password with extra steps.

AID: Identity is the Credential

With AID, the agent's Ed25519 keypair is its credential. No shared secrets. No passwords. No rotation schedules. The private key never leaves the agent's machine.

Cryptographic Identity

Ed25519 keypair = identity. Nothing to leak, nothing to rotate.

Per-Agent Audit Trail

Every token identifies which agent requested it. Full accountability.

Scoped Permissions

Role-based scopes. Each agent gets only the access it needs.

Standard JWTs

RS256 tokens work with any API, any gateway, any language.

How it Works

Three parties. Human-controlled access. Standard OAuth 2.0.

👤

Human Admin

Creates roles with specific permissions on the identity provider. Registers agents and controls what they can access. Always in control.

🤖

AI Agent

Has an Ed25519 identity. Proves who it is to get a scoped JWT token. Cannot self-register or escalate permissions.

🔌

Target API

Any API that validates JWTs via the auth server's JWKS endpoint. No AID-specific logic needed. Works with AWS Gateway, Cloudflare, nginx.

Admin: Create Role

Human admin creates a role on the identity provider with scoped permissions (e.g., tickets:read, users:write).

Register Agent

Admin registers the agent's public key with the auth server and assigns the role. One-time setup.

Agent: Get Token

Agent signs its identity + proof of possession and exchanges them for a scoped RS256 JWT.

Call Any API

Agent uses the JWT with any API. The API validates the token via the auth server's JWKS endpoint.

Example: Support Agent for Zoom Tenant

A support agent needs API access to manage tickets. The admin controls what it can do.

# ── ADMIN (human, one-time setup) ──────────────────────
# Step 0: Create "support" role on auth server with permissions:
#   tickets:read, tickets:write, users:read
# ── AGENT (ai) ─────────────────────────────────────────
# Step 1: Initialize identity (one-time)

            $
             aid-init --name support-agent
          
# Step 2: Admin registers agent with auth server (one-time)

            $
             aid-register --auth https://auth.23blocks.com/zoom \
          

            --token <ADMIN_JWT> --role-id 3
          
# Step 3: Agent gets a scoped token (autonomous, repeatable)

            $
             TOKEN=$(aid-token --auth https://auth.23blocks.com/zoom --quiet)
          
# Step 4: Agent calls any API with the JWT

            $
             curl -H "Authorization: Bearer $TOKEN" \
          

            https://api.23blocks.com/zoom/tickets
          
# ── TARGET API ─────────────────────────────────────────
# API validates the JWT using the auth server's JWKS endpoint
# GET https://auth.23blocks.com/zoom/.well-known/jwks.json
# No AID-specific code needed — standard JWT validation
# Optional: real-time status check via introspection
# POST https://auth.23blocks.com/zoom/oauth/introspect
# → {"active": true, "agent_status": "active", ...}

How the agent gets its permissions: The --role-id in aid-register binds the agent to a specific role, and the --token <ADMIN_JWT> is what authorizes it. The admin's JWT proves they have permission to register agents with that role. Without a valid admin token, the registration is rejected. Once registered, every token the agent requests is scoped to that role's permissions — the agent cannot change its role, self-register, or escalate. One-time human approval, then the agent operates autonomously within those boundaries.

OAuth 2.0 Token Exchange Flow

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

            grant_type=urn:aid:agent-identity
          
            &agent_identity=<base64url-signed-identity>
          
            &proof=<base64url-proof-of-possession>
          
            &scope=files:read files:write
          
Response:
{

            "access_token": "eyJhbGciOiJSUzI1NiJ9...",
          
            "token_type": "Bearer",
          
            "expires_in": 3600,
          
            "scope": "files:read files:write"
          
}

Agent Registration

Two paths to identity. Both require human approval.

Admin has the token

Admin-Initiated

Admin has the key, registers directly. Agent gets tokens immediately.

Agent initializes

aid-init --name support-agent

Admin registers with role

aid-register --auth URL --token JWT --role-id 3

Agent gets tokens immediately

aid-token --auth URL

RFC 8628 Device Flow

Agent-Initiated (RFC 8628)

Agent requests access, admin approves later.

Agent requests registration

aid-request --auth URL --description "..."

Server returns authorization_url + user_code

XXXX-XXXX

Admin visits URL, verifies fingerprint, selects role, approves

Agent polls, then gets tokens

aid-token --auth URL

Inspired by RFC 8628 (Device Authorization Grant)

The response includes authorization_url, user_code, expires_in, and interval — familiar to any OAuth implementer. Read why we chose RFC 8628 →

Why AID?

Built for the $11B non-human identity market. Open, standards-based, cloud-agnostic.

No Shared Secrets

Ed25519 asymmetric crypto. Private key never leaves the agent. Nothing to leak, nothing to rotate.

Replay Protected

Proof of possession with timestamps. 5-minute validity window prevents replay attacks.

Role-Based Scopes

Each agent gets a role with specific permissions. Request only the scopes you need. Least privilege by default.

Multi-Server

One identity, many auth servers. Register with multiple APIs. Different roles, different scopes, same keypair.

Standard OAuth 2.0

Custom grant type on standard OAuth. RS256 JWTs. OIDC discovery. JWKS endpoints. Works with existing infrastructure.

Token Caching

Automatic local token cache. Scope-aware. 60-second buffer before expiry. Skip with --no-cache when needed.

Full Audit Trail

Every token request tracked. Agent address, timestamp, scope. Know exactly which agent did what, when.

Cloud Agnostic

Not tied to AWS, Azure, or GCP. Works with any OAuth 2.0 server. Open protocol, open source, MIT licensed.

The Protocol

AID extends OAuth 2.0 with a single custom grant type. Everything else is standard.

Agent Identity Document

A signed JSON document containing the agent's public key, address, and fingerprint. The agent signs it with its Ed25519 private key to prove ownership.

{

            "aid_version": "1.0",
          
            "address": "my-agent@acme.crabmail.ai",
          
            "public_key": "-----BEGIN PUBLIC KEY-----\n...",
          
            "key_algorithm": "Ed25519",
          
            "fingerprint": "SHA256:abc123...",
          
            "issued_at": "2026-03-21T00:00:00Z",
          
            "expires_at": "2026-09-21T00:00:00Z",
          
            "signature": "<base64url-ed25519-signature>"
          
}

Proof of Possession

A timestamped challenge signed with the agent's private key. Proves the agent currently holds the key (not just a replay of a previous request). 5-minute validity window.

// Sign input (plaintext)

            "aid-token-exchange\n{unix_timestamp}\n{auth_server_url}"
          
// Proof (base64url encoded)

            base64url(ed25519_sign(sign_input) + timestamp_string)

AID + AMP

AMP — Identity & Messaging

The Agent Messaging Protocol provides the foundation:

• Ed25519 keypair generation
• Agent addresses (name@tenant.provider)
• Fingerprints for identity verification
• Cryptographic message signing

AID — Authentication & Authorization

Agent Identity builds on AMP to add:

• OAuth 2.0 token exchange (urn:aid:agent-identity)
• Scoped RS256 JWT tokens
• Role-based access control
• Multi-server registration

Quick Start

Install in 30 seconds. Authenticate in 3 commands.

# Install AID

            $
             curl -fsSL https://raw.githubusercontent.com/agentmessaging/agent-identity/main/install.sh | bash
          
# Initialize agent identity

            $
             aid-init --auto
          
# Register with an auth server (one-time)

            $
             aid-register --auth https://auth.example.com/acme --token eyJ... --role-id 2
          
# Get a scoped JWT token

            $
             aid-token --auth https://auth.example.com/acme --scope "files:read"
          
# Use it with any API

            $
             curl -H "Authorization: Bearer $(aid-token -a https://auth.example.com/acme -q)" \
          
            https://api.example.com/files

The Landscape

AID is the identity layer underneath MCP and A2A.

Feature	AID	Google A2A	MCP	Entra Agent ID	SPIFFE
Focus	Agent auth & identity	Agent-to-agent coordination	Agent-to-tool connectivity	Enterprise agent governance	Workload identity
Auth Mechanism	Ed25519 + PoP	OAuth 2.0 / mTLS	OAuth 2.1 + PKCE	Federated Identity	X.509 SVIDs
Agent Registration	Self-service + admin approval	Agent Cards	Server-managed	Blueprint + Azure	Attestation
Cloud Lock-in	None	None	None	Azure	None (infra)
Open Source	MIT	Apache 2.0	Apache 2.0	No	Apache 2.0
Complementary	—	✓ AID provides identity	✓ AID provides identity	Overlaps	Different layer

AID + MCP + A2A: The Three-Protocol Stack

MCP connects agents to tools. A2A connects agents to agents. AID proves who each agent is. Use AID as the identity layer, MCP for tool access, and A2A for agent coordination.

For Implementers

What each party needs to implement.

Identity Provider (Auth Server)

1. Agent Registration

Add a POST /agent_registrations endpoint that accepts public keys, addresses, and fingerprints. Assign roles with scoped permissions.

2. Token Endpoint

Handle grant_type=urn:aid:agent-identity in your POST /oauth/token endpoint. Verify the signed identity and proof.

3. Ed25519 Verification

Verify the Agent Identity signature, check expiration, validate proof of possession timestamp, and match fingerprints against registrations.

4. JWKS + OIDC Discovery

Expose /.well-known/jwks.json so target APIs can validate JWTs. Add urn:aid:agent-identity to grant_types_supported.

5. Token Introspection

Add POST /oauth/introspect (RFC 7662) so target APIs can verify agent tokens in real-time. Returns active: false for suspended or deleted agents.

6. Lifecycle Management

Add suspend and reactivate endpoints. States: pending → active ↔ suspended → deleted. Suspended agents are blocked from token issuance and flagged via introspection.

7. Agent-Initiated Registration

Add POST /agent_registrations/request for agents to self-register. Return authorization_url with an opaque temporary code (not the agent ID). Add GET /agent_registrations/resolve?code={code} for the admin UI. Follows RFC 8628 Device Authorization pattern. Read the full story →

Target API (the service your agents call)

Minimal: No AID-specific code needed. Just validate RS256 JWTs using the auth server's JWKS endpoint — the same way you'd validate any OAuth 2.0 token. Works with AWS API Gateway, Cloudflare Access, nginx, or any JWT middleware.

Full control: Call the introspection endpoint (POST /oauth/introspect) to check real-time agent status — detect suspended agents before their token expires.

Identity forAI Agents