Add identity governance to your existing MCP servers — authenticate every agent, authorize every tool call, and audit every action, without modifying your MCP servers.
MCP Proxy is for when you already have MCP servers running but they lack identity awareness. Maybe you built MCP servers that expose tools for your AI agents, but those servers do not know who is calling them or whether the caller is authorized. MCP Proxy solves this by adding an identity-aware layer between your agents and your existing MCP servers — without modifying either side.The Model Context Protocol (MCP) is an open standard for AI agent-to-tool communication. When you have MCP servers already deployed, they speak MCP natively — agents connect, discover tools, and invoke them. The problem is that vanilla MCP does not include identity. Any agent that can reach your MCP server can invoke any tool. MCP Proxy fixes this gap.The Maverics Orchestrator acts as a transparent proxy between agents and your MCP servers. Agents connect to the Orchestrator (thinking it is the MCP server), and the Orchestrator forwards their requests to your actual MCP servers after applying identity and authorization. Here is the flow:
Agent connects — The AI agent connects to the Orchestrator’s MCP endpoint, treating it as a standard MCP server.
Authentication — The AI Identity Gateway Orchestrator returns protected resource metadata (per RFC 9470) that tells the agent which authorization server(s) to authenticate against. The agent authenticates with the Auth Provider Orchestrator and obtains a token, which the gateway validates before allowing the connection to proceed.
Identity injection — For every tool invocation, the Orchestrator injects identity context into the request before forwarding it to the upstream MCP server. This context includes the agent’s identity, the delegating user’s identity, and any relevant claims or attributes.
Authorization — The Orchestrator evaluates authorization policies to determine whether this agent, acting on behalf of this user, is allowed to invoke this specific tool.
Transparent forwarding — The Orchestrator exchanges the agent’s token for a short-lived, narrowly scoped token specific to the tool being invoked, then forwards the authorized request to the upstream MCP server with this fresh token and identity context attached. The MCP server receives the request as if the agent connected directly — but now with identity information it can use.
Response passthrough — The MCP server’s response flows back through the Orchestrator to the agent, with audit logging capturing the complete interaction.
MCP Proxy vs MCP Bridge: MCP Proxy proxies existing MCP server connections
with identity injection — choose it when you already have MCP servers running.
MCP Bridge translates REST APIs into MCP tools — choose it when you have REST
APIs, not MCP servers.See the AI overview for a side-by-side
comparison of both approaches.
A running Maverics Orchestrator — If you have not installed the Orchestrator yet, follow the Quick Start guide first. The Orchestrator is a small, lightweight runtime that deploys almost anywhere.
An identity provider configured as an identity connector — The Orchestrator needs an Identity Fabric to authenticate agents and resolve user context.
One or more existing MCP servers — These are the upstream MCP servers that your AI agents will access through the proxy. They must be reachable from the Orchestrator over the network.
An AI agent that supports the Model Context Protocol (MCP) — The agent connects to the Orchestrator’s MCP endpoint (not directly to your MCP servers).
The MCP Provider is the Orchestrator’s entry point for AI agent connections — the same component used by MCP Bridge. It handles MCP transport, agent authentication via OAuth, and routes tool calls to the correct MCP Proxy app.
Console UI
Configuration
Console UI documentation is coming soon. This section will walk you
through configuring this component using the Maverics Console’s visual
interface, including step-by-step screenshots and field descriptions.
AI Identity Gateway mode selection with MCP Proxy in Maverics Console
Define the MCP Provider and the OIDC connector for agent authentication. This configuration is identical to the MCP Bridge setup — the MCP Provider serves both Bridge and Proxy apps.
The MCP Provider configuration is shared across all MCP apps (both Bridge and Proxy). Agents authenticate once at the MCP Provider level (via the Auth Provider Orchestrator) and can then invoke tools from any registered MCP app.
2
Define the MCP Proxy app
Register your upstream MCP server as an MCP Proxy app. The Orchestrator proxies MCP protocol natively — it receives MCP requests from agents and forwards them to your upstream MCP server over the Streamable HTTP transport.
Console UI
Configuration
Console UI documentation is coming soon. This section will walk you
through configuring this component using the Maverics Console’s visual
interface, including step-by-step screenshots and field descriptions.
Upstream MCP server registration in Maverics Console
Define an MCP Proxy app in the apps section. The upstream configuration points to your existing MCP server, and toolNamespace prefixes tool names to avoid collisions.
The upstream.stream.url points to your MCP server’s Streamable HTTP endpoint. The toolNamespace.name prefix is added to all tools from this upstream server — for example, my_server_listItems. This prevents naming collisions when you proxy multiple MCP servers.The connection settings control how the Orchestrator maintains its connection pool to the upstream MCP server, including dial timeouts and keep-alive intervals.
If your MCP servers are behind a firewall or VPN, make sure the Orchestrator
has network access to them. The Orchestrator needs to reach each upstream
server to discover its tools and forward requests.
3
Configure authorization
Like MCP Bridge, every MCP Proxy app requires both inbound authorization (OPA policy) and outbound authorization (how the Orchestrator authenticates to the upstream MCP server on behalf of the agent). This is the same authorization pattern used across all MCP apps.
Console UI
Configuration
Console UI documentation is coming soon. This section will walk you
through configuring this component using the Maverics Console’s visual
interface, including step-by-step screenshots and field descriptions.
Agent authentication and authorization for MCP Proxy in Maverics Console
The outbound authorization is where the Orchestrator’s per-tool token exchange happens. Instead of forwarding the agent’s original token to your MCP server, the Orchestrator mints a fresh, short-lived token for each tool invocation — scoped to exactly the permissions that tool needs, with a TTL measured in seconds.Add the authorization block to your MCP Proxy app. The inbound section defines the OPA policy, and the outbound section configures token exchange (or marks the upstream as unprotected).
Inbound authorization (OPA): The Rego policy controls which tool calls are allowed. The OPA input schema provides input.request.mcp.tool.params.name (the tool name), input.request.mcp.tool.params.arguments (the tool arguments), input.request.http.headers (including the inbound access token), and input.source.ip (the client IP). See the Authorization Policies guide for the full input schema and example policies.Outbound authorization (token exchange): Each tool gets its own scopes and TTL for the delegated token. The type: delegation means the exchanged token preserves both the agent’s and the delegating user’s identity.This means when an agent calls listItems, the Orchestrator mints a token with only item:List scope that expires in 5 seconds. When the same agent calls createItem next, a completely different token is minted with only item:Create scope. Every tool invocation gets a fresh, minimal-privilege token — nothing is reused or over-scoped.If your upstream MCP server does not require authentication, use type: unprotected:
If your upstream MCP servers are also accessible directly (not just through
the proxy), agents could bypass the identity layer by connecting to the MCP
server directly. Restrict network access so that MCP servers only accept
connections from the Orchestrator.
4
Verify proxied connections
Test the complete flow by connecting an AI agent to MCP Proxy and verifying that identity context is correctly injected into upstream requests.Connect your agent to the Orchestrator’s MCP endpoint and invoke a tool. Then check:
Agent authentication — The Orchestrator logs show the agent was authenticated successfully
Tool discovery — The agent sees tools from all registered upstream MCP servers
Identity injection — The upstream MCP server received the request with identity context attached (check the MCP server’s logs or add a debug tool that echoes received metadata)
Authorization enforcement — Try invoking a tool the agent should not have access to and confirm the request is denied
Success! Your existing MCP servers are now protected by the Orchestrator’s
identity layer. Agents authenticate before accessing tools, identity context
is injected into every request, and authorization policies control which
tools each agent can use.