MCP Identity Gateway reference

Operational reference for MCP Identity Gateway operators and implementers.

For environment variables, see Environment variables reference. For installation, see Set up the MCP Identity Gateway.

Token and credential details

The tokens and credentials used in each hop have different formats and purposes:

Token / Credential	Format	Source
Agent-to-Gateway	Aembit-issued access token (typically JWT)	Issued by the Aembit Authorization Server after the user authenticates via a configured IdP
Gateway-to-Server	Varies by MCP server	Determined by the Credential Provider configuration (for example, OAuth 2.0 access token via Authorization Code flow)

Agent-to-Gateway tokens - The Aembit Authorization Server issues these tokens after it authenticates the user via an external identity provider (such as Google, Okta, or Microsoft Entra ID). The MCP Gateway validates these tokens using Aembit’s signing keys.
Gateway-to-Server credentials - Aembit manages these via Credential Providers. For modern SaaS MCP servers, these are typically OAuth 2.0 access tokens obtained via the Authorization Code (3-legged OAuth) flow. Aembit may support other methods depending on how the MCP server authenticates.
Credential caching - The MCP Gateway caches downstream MCP server credentials and configuration in memory to reduce latency. Cached credentials are short-lived and refreshed as needed; the Gateway doesn’t persist them to disk.

`systemd` Commands

The MCP Identity Gateway runs as a systemd service (aembit_mcp_gateway).

# Check service status
sudo systemctl status aembit_mcp_gateway

# Restart the service
sudo systemctl restart aembit_mcp_gateway

# Stop the service
sudo systemctl stop aembit_mcp_gateway

# Start the service
sudo systemctl start aembit_mcp_gateway

# View logs
journalctl --namespace aembit_mcp_gateway -f

Network requirements

Inbound

Port	Protocol	Purpose
443	TCP/TLS	MCP client connections
80	TCP	TLS certificate provisioning (`Let's Encrypt`)

MCP clients authenticate using access tokens (JWTs) from your identity provider (such as Google, Okta, or Microsoft Entra ID). The MCP Identity Gateway validates tokens against the configured Trust Provider and uses streamable HTTP transport (HTTP with server-sent events) for server-to-client streaming.

Outbound

Port	Target	Destination	Purpose
443	Aembit Cloud	`https://<tenantId>.aembit.io`	Authorization, policy, credentials
443	MCP servers	`https://<mcp-server-host>`	Proxied MCP traffic
443	IdP endpoints	`https://<idp-host>/...`	OAuth/OIDC user authentication
5000	Agent Controller	`http://localhost:5000`	Registration (localhost only)

Logging and events

Log access

View MCP Identity Gateway logs using journalctl:

# Follow logs in real-time
journalctl --namespace aembit_mcp_gateway -f

# View recent logs
journalctl --namespace aembit_mcp_gateway -n 100

# View logs since a specific time
journalctl --namespace aembit_mcp_gateway --since "1 hour ago"

Workload events

Workload events in capture access patterns for audit and observability. See Audit and report on Workload activity for details.

Observability

The MCP Identity Gateway produces structured JSON logs that help you:

Answer “who did what” questions—which user and AI agent accessed which MCP server and tools, and when
Trace policy decisions—which policy allowed or denied a given request
Monitor behavior—connection patterns and error rates between AI agents and MCP servers

Forward these logs to Log Streams to integrate with your existing observability and Security Information and Event Management (SIEM) tooling.

Operational considerations

Policy management - Configure access policies through the Aembit Tenant, Terraform provider, or API.
Service management - The MCP Identity Gateway runs as a systemd service. See the systemd Commands section for service commands.
Logging - The MCP Identity Gateway writes logs to journald. Use journalctl --namespace aembit_mcp_gateway to access logs.

To verify your deployment is working correctly, see Verify the connection in the setup guide.

Supported deployment patterns

In the current beta, the supported pattern is:

Internet-facing VM Gateway - A Linux VM (for example, in AWS) running the MCP Identity Gateway as a systemd service, with a public DNS name for SaaS AI agents (such as Claude or Gemini).

You can deploy multiple Gateway VMs for different environments (development, staging, production) or for different MCP servers or trust boundaries.

Supported MCP servers

The Gateway supports both third-party SaaS MCP providers and customer-built MCP servers, subject to compatibility and configuration.

In the current beta, Aembit has validated the Gateway with a small set of MCP servers. Additional MCP servers may work but Aembit considers them best-effort until explicitly documented.

Security guarantees and non-goals

Guarantees:

AI agents never receive downstream credentials for MCP servers
Centrally managed Aembit policies govern all access
You retain control over deployment, network placement, and data flow

Non-goals:

The Gateway doesn’t replace the MCP server’s internal authorization logic
The Gateway doesn’t inspect or filter prompt content beyond what policy evaluation requires
The Gateway isn’t a fully managed multitenant service in the current public beta