MCP Governance

EVE governs Model Context Protocol tool calls end to end: it decides whether the call is permitted, binds the approved request to the executed request so nothing changes in between, and records the outcome. The core guarantee is that the request you approved is the request that runs.

Governance guarantees

Bind approved to executed — EVE cryptographically binds the approved MCP request to the executed request; any mutation between approval and execution is rejected before the side effect.
Server-derived identity — tenant/principal/session come from authenticated context; mismatched payload or header identity is rejected.
Atomic single-use consumption — an authorization is consumed atomically across processes via a PostgreSQL-authoritative backend, so it cannot be consumed twice.
Honest outcomes — an unknown remote result is recorded as OUTCOME_UNKNOWN rather than silently retried.

Evidence example

mcp execution evidence {
  approved_digests == executed_digests,
  authorization_consumed: true
}
# distributed consumption: 50 processes -> exactly 1 OK, 49 REPLAY, 1 recorded side effect

SDK context

MCP identity is always the authenticated tenant_id, principal_id, and session_id — never taken from a request body. The same governance context flows through the SDK:

context = {"tenant_id": "org_abc", "principal_id": "agent_mcp", "session_id": "sess_5"}

Readiness

MCP execution binding, authenticated identity, and distributed consumption are PILOT_READY. MCP deployment is distributed-pilot validated in the documented test topology (Python; MCP-gateway and embedded-service modes).

Limitations

Guarantees at-most-once authorization consumption and approved-equals-executed binding; it does not provide remote exactly-once execution.
Distributed consumption was validated across separate OS processes on one host with real PostgreSQL; multi-host across networked machines is argued from PostgreSQL transactional guarantees, not yet demonstrated across hosts. This is a distributed pilot, not a production claim.
Authenticated identity requires the auth middleware mounted; reverse-proxy identity headers are rejected as untrusted.

Next step

Bring your MCP servers into a pilot and verify the approved-versus-executed binding evidence yourself.