MCP Identity Gateway concepts

This page explains how the MCP Identity Gateway works, including its architecture and policy model. For setup instructions, see Set up the MCP Identity Gateway.

Core actors

The MCP Identity Gateway architecture involves:

AI Agent () - MCP-capable AI agents (such as Claude) that connect to the Gateway
MCP Identity Gateway - The data-plane proxy you deploy that enforces policies and proxies MCP traffic
Aembit Cloud - Evaluates and provides credentials via
Identity Provider (IdP) - Your IdP (Okta, Google, Entra ID) authenticates users
- The target services providing tools and resources

User identity in MCP traffic

Unlike typical workload-to-workload scenarios, MCP traffic involves a human user operating an AI agent. This means every MCP request carries two identities:

MCP client identity (workload) - The AI agent application making the request, identified by its OAuth redirect URL (for example, https://claude.ai/api/mcp/auth_callback)
User identity (human) - The person using the AI agent, identified by claims from your IdP such as their email address

The MCP Identity Gateway uses both identities for access control. The MCP client identity determines which AI agents can connect, while the user identity determines who can access which MCP servers and enables per-user credential isolation.

In the client-to-Gateway policy, the Credential Provider extracts the user’s identity from their IdP token. You specify this using a dynamic claim expression like ${oidc.identityToken.decode.payload.<user_claim>}. Replace <user_claim> with a claim from your IdP that uniquely identifies users (such as email, sub, or preferred_username). This embeds the user’s identity in the access token, enabling Aembit to:

Enforce per-user access policies
Store OAuth tokens for each user in isolation
Provide user-level audit trails showing who accessed which MCP servers

MCP Identity Gateway architecture

The following diagram shows how traffic flows through the MCP Identity Gateway:

Authorization flows

The Gateway orchestrates two flows: initial authentication and per-request authorization.

Initial authentication

The AI agent initiates an OAuth flow with the Aembit Authorization Server, which redirects the user to their Identity Provider for authentication. After validating the user’s OIDC token against the Client-to-Gateway policy, Aembit issues a long-lived access token. This token embeds the user’s identity and enables per-user access policies. This happens once per AI agent.

Per-request authorization

For each request, the Gateway validates the access token locally, then requests an assessment from Aembit Cloud. The Policy Engine evaluates the Gateway-to-Server policy and returns credentials if allowed. The Gateway proxies the request using those credentials. The Gateway is stateless—every request triggers fresh policy evaluation with per-request credentials.

Identity-aware access policies

The MCP Identity Gateway evaluates every MCP interaction against Aembit access policies. The MCP Identity Gateway requires two access policies to function:

You configure one Client-to-Gateway policy per MCP Identity Gateway and one Gateway-to-Server policy per MCP server—not one policy per user. This model supports many users sharing the same policies while maintaining per-user credential isolation through the Credential Provider.

Client-to-Gateway policy - Validates which MCP client is connecting (by redirect URL) and authenticates the user through your IdP via a Trust Provider. This policy handles blended access: both the AI agent identity and the user identity.

Gateway-to-Server policy - Authorizes the Gateway to access MCP servers on behalf of authenticated users. The Credential Provider manages access to the MCP server, with optional Access Conditions for time or GeoIP restrictions. Use MCP User-Based Access Token when the MCP server requires per-user OAuth credentials (most SaaS MCP servers). Use OAuth 2.0 Authorization Code when the server accepts a shared, administrator-authorized token.

Each user completes an OAuth flow once per MCP server. If unauthorized, the Gateway denies the request and logs the event.

Token exchange

A central design principle: the MCP Identity Gateway scopes credentials to where they’re needed:

Agent → MCP Identity Gateway - The AI agent holds a token that identifies the agent and user. This token is only valid against the MCP Identity Gateway.
MCP Identity Gateway → MCP server - The MCP Identity Gateway holds a token that’s valid against the MCP server. The MCP Identity Gateway never exposes this token to the AI agent.

This separation allows you to:

Revoke or change access by updating Aembit policies without reconfiguring AI agents
Rotate MCP-side credentials without redistributing anything to AI agents
Prove for audit purposes that AI agents never received direct credentials for sensitive systems

Security model

The MCP Identity Gateway enforces four security boundaries:

Token validation - The MCP Identity Gateway validates incoming tokens against the configured before processing any request.
Transport security - All connections use Transport Layer Security (TLS) 1.2 or higher. The MCP Identity Gateway terminates TLS from clients and initiates new TLS connections to MCP servers.
Credential isolation - The MCP Identity Gateway holds downstream credentials only in memory and never exposes them to AI agents.
Policy enforcement - The MCP Identity Gateway evaluates every request against Aembit access policies before proxying it.

Next steps

Get started:

Set up the MCP Identity Gateway - Deploy and configure the Gateway

Learn more:

Environment variables - Configuration reference
Reference - Networking, logging, and operational details
About MCP User-Based Access Tokens - When to use this Credential Provider and how it works
Configure MCP User-Based Access Token - Step-by-step configuration guide