AIGW Developer Documentation

AIGW (Agent Identity Gateway) is the identity and authorization layer between AI agents and the services they act on.

See How AIGW works for the architecture and request flow.

Choose your integration

You build or operate	Start here
A merchant API	Merchant Integration: connect your authorization server and decide who operates the MCP/UCP service.
An MCP / UCP service	MCP / UCP Quickstart: protect your endpoint, validate agent requests, and obtain merchant access tokens server-side.
An AI agent	Agent Integration: discover AIGW, register your client, obtain user authorization, and call the service.

Tools to get started

• Playground — walk through authorization and inspect HTTP requests. The MCP service and merchant API are simulated.
• DevCLI — the aigw command-line tool for configuring AIGW. Use it with Codex or Claude Code from your application workspace.
• DevCon — AIGW Developer Console — configure AIGW in your browser. Start with an Account, your organization's workspace for team members, Projects, and API keys.

Reference

AIGW Configuration · Protocol Reference · Glossary

Why AIGW

AIGW answers three questions when an agent shows up:

1. Who is the human? The person the agent is acting on behalf of. Once they sign in, AIGW can establish their possession factor, their identity assurance, or both, depending on the sign-in methods you enabled.
2. Who is the agent? Proven with the verification standard that agent already uses.
3. What is it allowed to do? Scoped, user-consented access, handed to your existing APIs as a normal OAuth token.

Keep your existing merchant APIs and authorization server. Configure that server to trust AIGW, then add authorization handling to your MCP/UCP service. How AIGW works shows the complete request flow.

Verified human identity, not just a login

Agents act on behalf of someone, so knowing who that someone is matters more than ever. AIGW authenticates the user and can verify their identity at the same time:

• Phone possession and identity verification through a built-in phone verification provider, with a possession check and any additional identity assurance established by the provider.
• Passkeys (LoginID FIDO2), email one-time codes, and social/enterprise identity providers such as Google, Microsoft, and Facebook.
• AIGW access tokens can include the authentication methods (amr) and authentication context (acr) established during sign-in. Check the claims actually present and the provider-defined meaning of acr before requiring an assurance level. Your merchant authorization server decides which claims appear in its own access tokens.
• Subjects are opaque per project. AIGW retains an encrypted, account-scoped end-user identity snapshot, including verified phone/email data. Authorized administrators receive masked views and use audited reveal/erase flows; see Account identity-data access for administration.

Works with the agent verification standards that already exist

There is no single "agent ID" standard yet, and AIGW doesn't make you pick one. It accepts several and turns them into one trust decision:

Proof	What the agent shows
Web Bot Auth	Requests signed with HTTP Message Signatures (RFC 9421), keys published in the agent's signature directory
Reverse DNS	Its network address resolves forward and back to its own domain
KYA credentials	A Know-Your-Agent credential from a third-party issuer you trust, rated on a trust ladder from Trusted to Untrusted
Hosted client metadata (CIMD)	Its client metadata document served from its own domain
Platform-trusted domains	Its domain is on a curated list of known agent platforms

You decide what each proof is worth with Agent policy: approve automatically, hold for review, or reject, per project or per resource. A person's decision always overrides policy.

Agent-friendly: no pre-registration

Agents shouldn't need a sales call or a developer portal before they can serve a user. With AIGW, an agent needs nothing but the issuer URL:

• Dynamic Client Registration (RFC 7591) lets an agent register itself at runtime.
• Client ID Metadata Documents let an agent use a URL as its client_id and skip registration entirely.
• Registration is global and merchant-agnostic: an agent registers once and can then reach any AIGW-protected merchant, with each merchant's policy applied on first contact.
• Discovery follows the standard MCP authorization pattern. The agent gets a 401, discovers the AIGW authorization server, runs Authorization Code + PKCE, and retries.

Seamless with standard OAuth infrastructure

AIGW doesn't replace your authorization server. It sits in front of it and speaks standard protocols in both directions:

• Agent side: OAuth 2.0 / OpenID Connect, authorization server metadata (RFC 8414), PKCE, and token revocation (RFC 7009).
• Merchant side: AIGW obtains a token from your existing authorization server (Keycloak, Auth0, or any OAuth server with standard extension grants). It uses a JWT bearer assertion with private_key_jwt (RFC 7523) or token exchange (RFC 8693), signed with per-resource keys published at a JWKS URL.
• Your MCP/UCP service redeems that merchant access token server-side and calls your API exactly as it does today. Merchant tokens are vaulted, refreshed when needed, and never exposed to the agent.