Merchant uses a third-party MCP / UCP provider

Use this model when an external company builds or operates the MCPMCPModel Context Protocol: a standard way for AI agents to call tools and data sources exposed by a server./UCP service that represents the merchant to agents.

Ownership model

A clean separation is:

Responsibility	MCP/UCP provider	Merchant
Own AIGW Account/Project	✓
Register AIGW Resource	✓
Operate MCP/UCP service	✓
Hold Proxy client secret	✓
Return 401 / metadata	✓
Receive AIGW token	✓
Redeem merchant token	✓
Operate merchant authorization server		✓
Trust AIGW issuer/JWKS		✓
Configure AIGW client at merchant AS		✓
Define merchant scopes/permissions		✓
Operate merchant backend		✓
Define user matching/provisioning		✓

This is the main handoff boundary in the integration.

Provider setup

The MCP/UCP provider creates the AIGW AccountAccountThe top-level AIGW tenant. It owns Projects, team membership, enabled identity providers, billing, and API keys./Project, registers the merchant as a Token exchange ResourceToken exchange ResourceA Resource for agent access: AIGW authorizes the user and obtains a token from the merchant's own authorization server., and defines the resource indicator and required scopes using values agreed with the merchant.

After creation, the provider captures the ResourceResourceThe downstream system registered in a Project. Its kind (Token exchange or OAuth client) decides the role AIGW plays. reference values.

The provider should send the merchant IAM team:

• AIGW 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./authorization-server URL;
• AIGW per-resource JWKSJWKSJSON Web Key Set: a published set of public keys used to verify JWT signatures. URL;
• client ID AIGW will present to the merchant AS;
• merchant issuer URL/token endpoint values the provider expects to configure in AIGW;
• requested scopes;
• expected grant/authentication pattern (private_key_jwt/RFC 7523 in the supplied Keycloak reference).

Merchant setup

The merchant configures its authorization server using those values. It does not need the MCP provider's Proxy clientProxy clientThe server-side credential (client ID and secret) the MCP/UCP service uses to authenticate itself to AIGW. Never give it to an agent. secret. It also does not need the dynamically registered agent's client secret.

The merchant should validate that:

• the issuer is the AIGW per-resource issuer, not the global core issuerCore issuerThe shared AIGW authorization server that issues agent-facing access tokens and hosts the token endpoint.;
• signatures are checked against the per-resource ES256 JWKS;
• the AIGW client is authorized to request only the intended scopes;
• user mapping/provisioning behavior is defined for the assertion sub values AIGW can send.

See Configure your authorization server.

Provider runtime

After the merchant confirms IAM configuration, the provider creates its project Proxy client and runs the normal MCP/UCP flow:

Agent -> MCP/UCP Provider -> AIGW -> Merchant Authorization Server
                         \-> Merchant Backend

The provider stores the Proxy client secret and merchant access tokensMerchant access tokenA token issued by the merchant's own authorization server. Only the MCP/UCP service sees it, never the agent. server-side. The merchant backend continues to receive merchant-issued access tokens.

Operational handoff checklist

Before production, both parties should agree on:

• resource indicator/audience;
• supported scopes and their semantics;
• merchant issuer and token endpoint;
• AIGW issuer/JWKS trusted by the merchant;
• user lookup/provisioning rules;
• token lifetime/refresh behavior;
• key rotation expectations;
• troubleshooting contacts and logs available on each side.

This prevents a common failure mode where the AIGW console configuration is correct but the merchant AS has a different audience, client ID, scope name, or user-mapping rule.