Best practices
The security rules that keep agents, services and merchants on separate credentials.
Checked against the Evaluation environment, Console 0.10.1 / 0.14.1, on October 19, 2026. Release status
Keep the two tokens apart
Most AIGW mistakes come from a credential ending up in the wrong place. Each party holds only what it needs.
| Credential | Held by | Never reaches |
|---|---|---|
| Agent client secret | The agent's backend | The model context, prompts, browser code or logs |
| AIGW access token | The agent, sent to the MCP or UCP service | The merchant API |
| ID token | The agent | MCP and UCP services, logs |
| Proxy client secret and Proxy token | The MCP or UCP service | The agent |
| Merchant access token | The MCP or UCP service, in memory | The agent, tool results, logs |
| AIGW signing keys | AIGW | Anyone. Merchants trust the public JWKS only. |
For agent developers
- Start from the 401. Follow the
resource_metadataURL in the service'sWWW-Authenticateheader and read endpoints from discovery. Hard-coded endpoints break when a Resource moves. Discovery reference - Register once per install, then reuse. Store the client ID and secret in a secrets manager. Registering on every run creates orphaned clients you can't audit.
- Ask for scopes at authorization, never at registration. Request the smallest set the task needs.
- Always use PKCE with S256 and check state. Generate a fresh verifier and state for every authorization request.
- Keep tokens out of the model. The agent runtime attaches the bearer token to HTTP calls; the language model should never see it in a prompt or tool output.
- Handle expiry by re-authorizing. Refresh is unverified in this release, so fall back to a new authorization request when a refresh fails.
For MCP and UCP services
- Validate every AIGW token. Signature from JWKS,
iss,audandexp, on every request. How to validate - Redeem on the server, keep the result there. Call redemption from your backend and use the merchant token only for the outbound call. Redemption reference
- Send the exact resource indicator. Keep it in configuration, copied from the Console, not assembled from user input.
- Reuse your Proxy token. Cache it for its lifetime and renew it a little before it expires.
- Key users by sub. It is stable and opaque. Don't ask agents for email addresses or names.
For merchant IAM teams
- Trust AIGW through its JWKS URL. Fetching keys by URL lets AIGW rotate keys without a change on your side. Authorization server guide
- Use one identity provider alias per Resource. It keeps audiences unambiguous and lets you revoke one integration without touching others.
- Keep assertion lifetimes short. Use the documented limits: one hour maximum for user assertions, one minute for client assertions, 60 seconds of clock skew.
- Make scopes optional and explicit. Attach agent scopes as optional client scopes so a token carries only what the user approved.
- Decide user mapping first. It is the most common first failure. Pick how AIGW's subject maps to your users before you test.
For everyone
- Redact before you log. Log token IDs,
sub, status codes and error codes. Never log full tokens, secrets or ID token contents. - Retry only what is safe. Retry network errors and 5xx with backoff. Never retry
invalid_grantor a used authorization code. - Build on Supported features first. Check the release status and keep a fallback for anything Unverified.
Ready to ship? Work through the production checklist. It turns these rules into checks you can sign off.

