EVE MCP Governance

Bind the approved MCP request to the executed request, and reject any mutation before the side effect.

Who this is for

Teams exposing tools to agents over the Model Context Protocol (MCP) who need approval and execution to refer to the same request — not a request that was quietly changed between the two. If you approve "read row 5" and the executed call becomes "delete table," you need that caught before the delete runs.

The problem

Approval and execution are two events. Between them, arguments, target server, capability schema, or context can be mutated — a time-of-check-to-time-of-use (TOCTOU) gap. A single approval could also be replayed to run an action more than once. You need the executed request cryptographically tied to the approved one, and single-use authorizations that cannot be spent twice.

Supported capabilities

• Execution binding. EVE cryptographically binds the approved MCP request to the executed request; any mutation between approval and execution is rejected before the side effect. Binding covers intent, capability-schema, server-identity, and context digests (core/mcp/execution_binding.py).
• Authenticated, server-derived identity. MCP execution identity (tenant, principal, session) is server-derived from authenticated context; payload/header identity assertions must match or the request is rejected (interfaces/api/rest/mcp_identity.py, interfaces/middleware/auth.py).
• Distributed single-use consumption. Single-use authorizations are atomically consumed across processes via a PostgreSQL-authoritative backend, so one authorization cannot be consumed twice — validated across separate OS processes in the documented test topology (50 processes → 1 winner, 1 side effect, 49 replay-rejected).

Readiness: execution binding, authenticated identity, and distributed consumption are PILOT_READY — distributed deployment is distributed-pilot validated in the documented test topology.

How it works

1. An MCP request is proposed and approved; EVE computes digests over intent, capability schema, server identity, and context.
2. The identity (tenant, principal, session) is derived server-side from the authenticated context, not from client-supplied headers.
3. At execution, EVE recomputes the digests. If the executed request differs from the approved one, it is rejected before the side effect.
4. The single-use authorization is atomically consumed via the PostgreSQL-authoritative backend, so a replay cannot spend it again.

Technical example (rejected mutation)

If an approved read is mutated into a delete before execution, the digests no longer match and the call is rejected before any side effect:

{
  "mcp_execution_evidence": {
    "approved_digests": { "intent": "…", "capability_schema": "…" },
    "executed_digests":  { "intent": "…(changed)…", "capability_schema": "…" },
    "action": "BLOCK",
    "reason_code": "MCP_EXECUTION_BINDING_MISMATCH"
  }
}

A forged X-Tenant header is rejected with reason code MCP_UNTRUSTED_PROXY_IDENTITY.

Signed evidence example

On the success path, the evidence records that approved and executed match and that the authorization was consumed:

{
  "mcp_execution_evidence": {
    "approved_digests": "== executed_digests",
    "authorization_consumed": true,
    "signature": "ed25519-…",
    "canon": "jcs-1"
  }
}

Distributed consumption under contention:

50 processes -> exactly 1 OK, 49 REPLAY, 1 recorded side effect

Verifier example

import { verifyEvidence } from "@eve/coreguard";
const report = verifyEvidence(mcpEvidence, { publicKeyPem });
// { valid: true, signature: "ed25519-valid" }

Deployment options

MCP Governance runs in MCP-gateway mode or embedded inside the EVE service. The distributed single-use consumption backend requires a reachable PostgreSQL instance. The authenticated identity path requires the auth middleware to be mounted; reverse-proxy identity headers are rejected as untrusted.

Readiness

Execution binding, authenticated identity, and distributed consumption are PILOT_READY — distributed deployment is distributed-pilot validated in the documented test topology. Supported via the Python SDK. The EVE SDK core overall is a RELEASE CANDIDATE WITH EXCLUSIONS.

Limitations

• Execution binding guarantees at-most-once authorization consumption and an approved-equals-executed binding. It does not provide remote exactly-once execution — an unknown remote outcome is recorded as OUTCOME_UNKNOWN and never silently retried.
• Distributed 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's transactional guarantees but is not yet demonstrated across hosts. This is a distributed-pilot, not a production claim.
• Authenticated identity requires the auth middleware to be mounted; reverse-proxy identity headers are treated as untrusted.
• The release-candidate clients are distributed privately for pilots — install the pilot artifact, not a public pip/npm install (see readiness for public-registry status).

Next step

Request a pilot to run MCP Governance in gateway or embedded mode against your tool servers, including the distributed single-use consumption test in the documented topology.