EVE + MCP (Model Context Protocol) Gateway

EVE governs MCP tool calls through an MCP gateway — the hardened, out-of-process boundary for agent tool execution. Unlike a wrapper adapter that a direct call can route around, the MCP gateway sits between approval and execution and binds them together, so a request that was mutated after approval is rejected before the side effect.

What the MCP gateway does

Execution binding. EVE cryptographically binds the approved MCP request to the executed request (intent, capability-schema, server-identity, and context digests). Any mutation between approval and execution is rejected before the side effect. This closes the time-of-check/time-of-use gap for MCP tool calls.
Server-derived identity. MCP execution identity (tenant, principal, session) is derived server-side from authenticated context. Identity asserted in a payload or header must match or the request is rejected — forged reverse-proxy identity headers are rejected as untrusted (for example, a forged X-Tenant header yields MCP_UNTRUSTED_PROXY_IDENTITY).
Distributed single-use consumption. Single-use authorizations are atomically consumed via a PostgreSQL-authoritative backend, so one authorization cannot be consumed twice. In the documented test topology, 50 competing processes yielded exactly one winner and one recorded side effect (49 replays rejected).
Signed evidence. MCP execution evidence records that the approved digests equal the executed digests and that the authorization was consumed.

Deterministic decision and evidence

The governance verdict is deterministic and contains no LLM in the decision path, and each decision can produce a signed evidence record. You can verify that evidence independently and offline:

from core.eve_sdk import verify_evidence

# verify_evidence(kind, evidence) dispatches by evidence kind; use "mcp" for
# MCP execution evidence. Returns a structured dict: {"valid": bool, "reason": ...}.
report = verify_evidence("mcp", mcp_evidence)
assert report["valid"] is True

At-most-once, not remote exactly-once

The gateway guarantees at-most-once authorization consumption and an approved-equals-executed binding. It does not provide remote exactly-once execution: when a remote outcome is unknown, it is recorded as OUTCOME_UNKNOWN and never silently retried. Design downstream tools so a recorded-but-unconfirmed outcome is safe to reconcile.

Readiness

MCP execution binding, server-derived authenticated identity, distributed single-use consumption: PILOT_READY. The MCP gateway is the enforcement boundary path for MCP tool calls (Python, mcp_gateway / embedded(service) modes).
Distributed consumption is distributed-pilot validated in the documented test topology.
Signed decision evidence and offline verification: SUPPORTED per the claims registry.

Limitations

Distributed single-use consumption was validated on a real PostgreSQL across separate OS processes on one host. True multi-host consumption across networked machines is argued from PostgreSQL transactional guarantees but is not yet demonstrated across hosts — this is a distributed-pilot, not a production, claim.
Server-derived identity requires the authenticated middleware to be mounted; reverse-proxy identity headers are treated as untrusted.
The gateway provides at-most-once authorization consumption and approved-versus-executed binding — not remote exactly-once execution; unknown remote outcomes are recorded as OUTCOME_UNKNOWN.
Independent verification of signed evidence requires the Ed25519 public key; the HMAC fallback is symmetric and not independently verifiable. Verification proves authenticity and integrity of the record, not the correctness of the decision.
MCP gateway governance is currently a Python surface.