AI Pilot — MCP Proxy Mode

Audience: Platform engineers, AI agent owners, security architects Time: ~10 min read

Control Core acts as an intelligent transparent proxy between MCP clients and MCP servers. The bouncer detects MCP traffic (/mcp paths and application/json-rpc content-type), normalizes JSON-RPC payloads into OPA inputs (input.mcp.method, input.mcp.params, agent_context), and applies PBAC overlays.

This page describes the three proxy modes and when to use each.

The three modes

Click to enlarge

Mode	What the bouncer does	When to use
`passthrough`	Sees the JSON-RPC, applies PBAC, forwards unchanged	You already publish each MCP server URL to clients
`registry`	Maintains an allowlist of MCP servers; rejects calls to unregistered targets	You want to centrally control which MCP servers are reachable
`broker`	Bouncer is the only MCP endpoint clients use; routes by `tool` to the right server	You want one URL for clients and a moving server fleet behind it

Passthrough mode

The default. Clients call the MCP server URL directly; the bouncer sits in front of it (sidecar or reverse proxy). Configure tool-level allowlists in Settings -> AI Pilot -> MCP Proxy and write Rego policies that read input.mcp.method to decide allow/deny.

Example PBAC: "MCP delete_record is allowed only for finance managers with MFA on production"

package controlcore.mcp.allow

default allow := false

allow if {
    input.mcp.method == "delete_record"
    input.user.role == "finance_manager"
    input.user.mfa == true
    input.context.environment == "production"
}

Registry mode

Add the MCP server URLs you trust to the Registry table under Settings -> AI Pilot -> MCP Proxy. The bouncer rejects any JSON-RPC call whose target host is not in the table with a 403 + MCP_SERVER_NOT_REGISTERED audit event.

The compiler emits an MCPRoute CRD listing the allowed servers and their schemas. Each entry can carry:

name, endpoint, tls, auth_ref
tool_allowlist[] — only these tool names are forwarded
tool_response_cache_ttl_seconds

Broker mode

Clients point only at the bouncer's MCP endpoint. The bouncer reads the requested tool from the JSON-RPC payload and routes to the right MCP server based on the registry table. This lets you:

Move MCP servers without reconfiguring clients
A/B test two implementations of the same tool
Cache tool responses transparently with tool_response_cache_ttl_seconds

The broker mode requires the bundled or external cache topology (see Cache & Rate Limits) for response caching to be effective across replicas.

Tool allowlists

For each registered server you can list the tools the bouncer will forward. Anything else returns 403 + MCP_TOOL_NOT_ALLOWED. The allowlist is enforced at the bouncer; PBAC policy can further narrow it by principal/context.

Tool-response caching

When tool_response_cache_ttl_seconds > 0, the bouncer caches the JSON-RPC result keyed by (tool, args_hash, principal) with the requested TTL. Useful for read-only tools (e.g. weather_lookup, inventory_get) that are expensive to call.

The cache key includes the principal so different users do not see each other's results.

PBAC overlays beyond the gateway

Where generic upstream AI gateway routing stops at traffic steering, AI Pilot continues with full PBAC:

Decision lineage — every MCP allow/deny is recorded with the rule chain that produced it
Step-up auth — Rego can demand MFA or device-trust before high-risk MCP tools execute
JIT access — short-lived grants stored on Policy.context_config.oem_metadata are first-class inputs
Workspace scoping — multi-tenant agents only see MCP servers/tools allowed for their workspace

Observability and audit

Every MCP call emits the usual AI_TRAFFIC_LOG plus a dedicated AI_MCP_TOOL_CALL event with tool, arguments_hash, server, decision, and cache_hit. Filter /audit?quickFilter=ai-mcp to drill in.

AI Pilot Enterprise Onboarding
Cache & Rate Limits — required for tool-response caching
Advanced AI Audit
mTLS Enforcement