Agent Identity (AID)

Agent Identity (AID) is an open-source protocol built by Agent Messaging that gives AI agents a cryptographic identity for authenticating with OAuth 2.0 servers. Released under the MIT license, it is currently at v0.3.0 and aligned with RFC 8628. The core idea is that an agent's Ed25519 keypair is its credential — no shared secrets, no API keys, and no rotation schedules.

What It Is

AID is an authentication and authorization protocol for AI agents. It extends standard OAuth 2.0 with a single custom grant type (urn:aid:agent-identity) so that agents can prove who they are and receive scoped RS256 JWTs that work with any API, gateway, or JWT middleware — without requiring AID-specific code on the target API side. The protocol sits at the identity layer underneath higher-level agent protocols like MCP (Model Context Protocol) and Google A2A.

How the Authentication Flow Works

The protocol involves three parties: a human admin, an AI agent, and a target API. The flow proceeds in four steps:

• Admin creates a role with specific permissions on the auth server (e.g., tickets:read, users:write)
• Agent registers its Ed25519 public key with the auth server (one-time, admin-authorized)
• Agent requests a token by presenting a signed Agent Identity document plus a timestamped proof of possession; the auth server verifies both and issues a scoped RS256 JWT
• Agent calls any API using the JWT; the target API validates it via the auth server's standard JWKS endpoint

Proof of possession uses a 5-minute validity window to prevent replay attacks. Token caching is built in, with a 60-second buffer before expiry and scope-aware cache keys.

Two Registration Paths

AID supports two ways for an agent to get registered, both requiring human approval:

• Admin-initiated: The admin holds the agent's public key and registers it directly using aid-register with an admin JWT and a role ID. The agent can get tokens immediately after.
• Agent-initiated (RFC 8628): The agent calls aid-request, which creates a pending registration and returns an authorization_url plus a short user_code. The admin visits the URL, verifies the agent's fingerprint, selects a role, and approves. The agent polls for status and begins getting tokens once approved.

The agent-initiated flow is explicitly modeled on the RFC 8628 Device Authorization Grant pattern, including expires_in and interval fields familiar to OAuth implementers.

Agent Lifecycle and Audit Trail

Every registered agent moves through a defined lifecycle: pending → active ↔ suspended → deleted. Admins can suspend an agent to immediately block token issuance; suspended agents are flagged via the RFC 7662 introspection endpoint so target APIs can detect suspension before a token expires. Every token request is tracked with agent address, timestamp, and scope, providing a full per-agent audit trail — something shared API keys and borrowed user tokens cannot provide.

Where It Fits in the Stack

The project's homepage positions AID as the identity layer underneath MCP and A2A: "MCP connects agents to tools. A2A connects agents to agents. AID proves who each agent is." AID shares its Ed25519 identity storage with the Agent Messaging Protocol (AMP) from the same organization — if both are installed, they use the same ~/.agent-messaging/agents/ directory, but neither requires the other.

The CLI (aid-init, aid-register, aid-request, aid-token, aid-status) is written in Shell and installable via a one-line curl script. A Claude Code skill integration is also available via npx skills add agentmessaging/agent-identity. Prerequisites are jq, curl, and OpenSSL 3.x for Ed25519 support.

Update: v0.3.0

The homepage banner shows the current release as v0.3.0, aligned with RFC 8628. The GitHub repository was created in March 2026 and last pushed in May 2026, indicating active early development. The project has 3 stars and 1 fork on GitHub. A reference auth server implementation is available separately as the 23blocks Authentication API.