AIGW Developer Documentation

AIGW (AI Gateway) is the identity and authorization layer between AI agents and the services they act on. It answers three questions every merchant asks when an agent shows up:

1. Who is the human? A real, verified person — not just an account that happens to be logged in.
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.

The point is that you don't rebuild anything for this. Agents arrive using open standards, users authenticate through AIGW, and your backend keeps working with the authorization server and tokens it already has. To see how the pieces connect, read How AIGW works.

Why AIGW

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 verificationPhone verificationA built-in identity verification provider that checks the user holds the phone for a number and can return verified identity data. provider, with an assurance level attached to the result.
• PasskeysPasskeyA phishing-resistant FIDO2 credential stored on the user's device, offered through the LoginID identity provider. (LoginID FIDO2), email one-time codes, and social/enterprise identity providers such as Google, Microsoft, and Facebook.
• Every token records how the user was verified (amr) and how strongly (acr), so your API can require a higher assurance level for sensitive actions such as checkout.
• Privacy by design: subjects are opaque per project, and raw identifiers such as the phone number are never stored.

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 MCPMCPModel Context Protocol: a standard way for AI agents to call tools and data sources exposed by a server. authorization pattern. The agent gets a 401, discovers the AIGW authorization server, runs Authorization Code + PKCEPKCEProof Key for Code Exchange: binds an authorization request to the later code exchange so a stolen code is useless., 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 JWKSJWKSJSON Web Key Set: a published set of public keys used to verify JWT signatures. URL.
• Your MCP/UCP service redeems that merchant 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.
• The merchant token carries the user and the acting agent, so your backend can audit and authorize agent-initiated actions.

Start by role

I build or operate an MCP / UCPUCPUniversal Commerce Protocol: a standard interface that lets agents carry out commerce tasks with a merchant. service. Protect the endpoint, guide the agent into AIGW authorization, then obtain a merchant access tokenMerchant access tokenA token issued by the merchant's own authorization server. Only the MCP/UCP service sees it, never the agent. server-side. MCP / UCP Quickstart →

I am the merchant. Choose whether your team operates MCP/UCP directly or a third-party provider operates it for you, then configure your authorization server. Merchant Integration →

I build an agent. Discover authentication, register, run Authorization Code + PKCE, and call the MCP/UCP service with the AIGW token. Agent Integration →

I want the big picture first. How AIGW works →

I want to see it work. Run the whole flow in the browser and inspect every real request. Try the Playground →

I need a reference. Use AIGW Configuration for console objects and Protocol Reference for endpoints, claims, metadata, and token flows.