MCP Security Gateway

Deploying EVE as an MCP gateway puts governance in front of your MCP servers so every tool call passes through a deterministic decision and a binding check before it reaches the server. Because the gateway is in the request path, enforcement does not depend on an agent cooperating.

Why a gateway (not just a wrapper)

In-path enforcement — the gateway intercepts the MCP request, so a direct call to the underlying tool still transits governance. Wrapper-only integrations, by contrast, are bypassable by calling the tool directly.
Binding at the boundary — the gateway binds the approved request to the executed request; a mutation after approval is rejected before the side effect.
Authenticated identity — tenant/principal/session are server-derived; forged headers are rejected as untrusted.
Atomic authorization — single-use authorizations are consumed atomically across processes via a PostgreSQL-authoritative backend.

Evidence example

# forged identity at the gateway
reason_code: MCP_UNTRUSTED_PROXY_IDENTITY

# concurrent replay across processes
50 processes -> 1 OK, 49 REPLAY, 1 recorded side effect

Readiness

MCP-gateway mode is part of the PILOT_READY MCP governance surface and is distributed-pilot validated in the documented test topology (Python; MCP-gateway and embedded-service modes).

Limitations

The gateway provides at-most-once authorization consumption and approved-equals-executed binding; it does not provide remote exactly-once execution. Unknown remote outcomes are recorded as OUTCOME_UNKNOWN.
Distributed consumption was validated across separate OS processes on one host with real PostgreSQL; multi-host across networked machines is not yet demonstrated across hosts.
Server-derived identity requires the authenticated middleware to be mounted at the gateway.

Next step

Stand up the MCP gateway in front of your MCP servers in a pilot and confirm binding and identity evidence on live tool calls.