MCP Identity Gateway (Beta)

The Aembit (MCP) Identity Gateway is a data-plane gateway that sits between AI agents and MCP servers. It centralizes how AI agents connect to MCP servers by enforcing , performing secure token exchange, and providing visibility into MCP activity.

What it does

Proxies MCP traffic - AI agents connect to the MCP Identity Gateway as if it were an MCP server. The Gateway connects to downstream MCP servers and relays requests and responses.
Enforces identity-aware policies - The Gateway validates the AI agent’s access token on every MCP request and requests evaluation of the Gateway-to-Server policy from Aembit Cloud to authorize access to the target MCP server. The Client-to-Gateway policy is evaluated by Aembit Cloud when the AI agent initially connects and obtains an access token. A Trust Provider validates user identity, and OAuth 2.0 Authorization Code Credential Providers manage per-user credentials.
Performs secure token exchange - The Gateway obtains and manages credentials for MCP servers so that AI agents never hold direct credentials for enterprise systems. Supported credential types include OAuth 2.0 tokens (via Authorization Code flow) and API keys. The Gateway obtains credentials per-request and caches them for 60 seconds—it never persists them to disk. For details on the token exchange flow, see MCP Identity Gateway concepts.
Centralizes MCP routing - AI agents connect to the Gateway endpoint instead of connecting directly to MCP servers. The Gateway routes requests to the configured MCP server based on policy.
Provides auditability - The Gateway produces structured logs that capture agent identity, user identity, target MCP server, and policy decisions. These logs integrate with Log Streams for centralized observability.
Runs under your control - Deploy the MCP Identity Gateway as a Linux virtual machine (VM) in your environment to control network boundaries, data locality, and integration with existing infrastructure. In the current limited beta, the supported packaging is a Linux service running on a VM; containerized or fully managed service deployments are planned for future releases.

When to use it

Use the MCP Identity Gateway when you need:

Centralized policy enforcement for all MCP traffic from AI agents
Auditability for which user and agent accessed which MCP server and tools
Guarantees that AI agents never hold reusable credentials to critical systems

The MCP Identity Gateway targets those who need to secure, control, and audit access from AI agents to third-party and custom-built MCP servers. Currently, a single Gateway can route traffic to multiple MCP servers while sharing centralized policies across many users, with each user’s access isolated by their own credentials.

How it works

The following diagram shows the request flow from a user through the MCP Identity Gateway:

A user sends a prompt to their large language model (LLM) client (AI agent).
The AI agent connects to the MCP Identity Gateway and presents a signed JSON Web Token (JWT) that identifies the agent and user.
The Gateway validates the token, requests policy evaluation from Aembit Cloud, and proxies the request to the MCP server using credentials that Aembit manages. If token validation or policy evaluation fails, the Gateway rejects the request (fail-closed).
The MCP server processes the request and returns a response.
The Gateway relays the response back to the AI agent.

The AI agent never receives credentials for the MCP server—the Gateway handles credential exchange transparently.

For architecture details, see MCP Identity Gateway concepts.

Identity validation

The MCP Identity Gateway validates identity through three distinct processes: initial authentication (one-time setup), per-request token validation, and per-request access policy evaluation.

Initial authentication (one-time setup)

Before an AI agent can make MCP requests, it must obtain credentials through a one-time authentication flow:

User authentication - The user authenticates to their identity provider (such as Google, Okta, or Microsoft Entra ID) through single sign-on (SSO).
Access token issuance - The identity provider issues a signed access token containing the user’s identity claims (iss, sub, aud, email).
Aembit access token issuance - The Aembit Authorization Server validates the access token and issues an Aembit-signed access token (an OAuth 2.0 access token in JWT format).
Token storage - The AI agent stores the Aembit access token for subsequent MCP requests.

This authentication process happens once during MCP client configuration. The AI agent reuses the stored token for all subsequent requests until it expires.

Token validation (per request)

On every MCP request, the Gateway validates the token before processing:

JWT format - The AI agent presents an access token (a signed JWT) with each request.
Signature validation - The Gateway validates the token signature using Aembit’s signing keys (JWKS).
Audience check - The token aud claim must match the Gateway URL.
Claims extraction - The Gateway extracts user identity and agent identity from the token.
Trust Provider validation - The configured Trust Provider validates the token issuer, audience, and key material for your identity provider.

If token validation fails, the Gateway rejects the request immediately.

Access policy evaluation (per request)

After token validation succeeds, the Gateway requests policy evaluation from Aembit Cloud:

Client-to-Gateway policy - Validates which MCP client is connecting and which user it represents.
Gateway-to-Server policy - Authorizes access to the target MCP server. Optional Access Conditions can enforce time-based or geographic restrictions.
Credential retrieval - The Credential Provider retrieves the user’s OAuth tokens for the target MCP server.

If policy evaluation fails, the Gateway rejects the request and logs the decision.

For details on the security model, see MCP Identity Gateway concepts.

Security properties

The MCP Identity Gateway provides the following security guarantees:

Credential isolation - AI agents never receive credentials for MCP servers. The Gateway obtains and manages credentials on their behalf.
Fail-closed behavior - If token validation or policy evaluation fails, the Gateway rejects the request. The Gateway denies requests by default unless a policy explicitly allows them.
Audit trail - The Gateway logs MCP traffic with agent identity, user identity, target server, and policy decision so you can see which agents and users accessed which MCP servers and when.
Centralized policy - Aembit policies govern access, not scattered configurations in individual agents.

What the Gateway doesn’t do:

The Gateway doesn’t replace the MCP server’s internal authorization logic.

In this section

Concepts - Architecture, security model, token handling, access policies, deployment patterns, and operational considerations
Setup - Deploy and configure the Gateway, with validation steps
Reference - CLI commands, configuration schema, networking, and error codes
Environment variables - Environment variables for Gateway configuration