Skip to main content

Accept an AIGW-authorized request

After OAuth completes, the agent retries the MCPMCPModel Context Protocol: a standard way for AI agents to call tools and data sources exposed by a server./UCP operation with an AIGW access tokenAIGW access tokenThe token an agent receives after the user authorizes it. It says which user approved which agent for which scopes..

POST /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer <AIGW_ACCESS_TOKEN>
Content-Type: application/json

At this point the agent is authenticated/authorized to AIGW. Your MCP/UCP service still needs a merchant token before it calls the downstream merchant API.

What is in scope for the MCP/UCP service​

Your server should preserve three pieces of context:

  • the received AIGW bearer token;
  • which merchant/resource this MCP tool operation maps to;
  • the operation/scopes required for the downstream call.

The resource mapping is important because AIGW's credential endpoint takes a resource value and resolves it within the same project as the AIGW token and proxy tokenProxy tokenA short-lived token the MCP/UCP service gets with its Proxy client, sent as X-Proxy-Token when redeeming a merchant token..

Core-issued AIGW token vs per-resource signed assertions​

AIGW uses two issuer/key contexts in the supplied implementation:

  • Agent access tokens are issued by the global/core AIGW authorization server and validated against the core issuerCore issuerThe shared AIGW authorization server that issues agent-facing access tokens and hosts the token endpoint./JWKS.
  • JWTs AIGW signs toward the merchant authorization server use the per-resource issuerPer-resource issuerThe AIGW authorization server dedicated to one Resource, at /<RESOURCE_ID> on the AIGW API host. Agents discover it; merchants trust it. and per-resource ES256 JWKSJWKSJSON Web Key Set: a published set of public keys used to verify JWT signatures..
Validate with the right keys

Do not validate the agent's bearer token with the per-resource, merchant-facing JWKS. Use the core AIGW issuer and JWKS.

Authorization and agent approval​

Each agent gets a status in ProjectProjectThe isolation boundary for an integration. It holds Resources, agents and agent policy, end users, and Proxy clients. → Agents (Pending, Approved, Rejected, Revoked). The first status comes from the Project's Agent policy; with no rules configured, the system default approves every agent. If a rule says Hold, the agent waits under Pending, and the authorization server refuses its requests until someone approves or rejects it.

Approved agents

This approval is a project policy control. It is separate from the end userEnd userA person an agent has acted on behalf of at a Project's Resources, as listed in the AIGW Console.'s OAuth consent.

The authorization browser flow presents the configured identity-provider sign-in page and then the resource consent experience. The supplied E2E run reached the AIGW login page and successfully completed another configured resource's code flow.

AIGW login

Once the agent returns with an AIGW token, continue to Get a merchant access token.