MCP Security

Model Context Protocol (MCP) lets agents call tools on remote servers. Two structural risks follow: an approved request can be mutated before it executes (a TOCTOU gap), and a request's claimed identity can be forged. EVE closes both at the governance boundary.

What EVE enforces for MCP

• Approved-versus-executed 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.
• Server-derived identity — tenant, principal, and session are derived from authenticated context. Payload or header identity assertions must match, or the request is rejected. Reverse-proxy identity headers are treated as untrusted.
• At-most-once authorization — single-use authorizations are consumed atomically so one authorization cannot be consumed twice.

Evidence example

A forged tenant header yields a deterministic reason code:

reason_code: MCP_UNTRUSTED_PROXY_IDENTITY   # forged X-Tenant header rejected

A mutation after approval fails the binding check:

mcp execution evidence { approved_digests == executed_digests }  # else BLOCK before side effect

Links

• MCP governance in depth: /seo/landing/mcp-governance.md
• MCP gateway deployment: /seo/landing/mcp-security-gateway.md
• Cryptographic evidence: /seo/landing/cryptographic-ai-audit-logs.md

Readiness

MCP execution binding, authenticated identity, and distributed at-most-once consumption are PILOT_READY, validated in the MCP suites (107 passed; auth suite 17 passed) and the MCP closure report. MCP deployment is distributed-pilot validated in the documented test topology.

Limitations

• Binding provides at-most-once authorization consumption and 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.
• Authenticated identity requires the authenticated middleware to be mounted; without it, identity derivation cannot be relied upon.
• Distributed consumption was validated across separate OS processes on a single host with a real PostgreSQL; true multi-host operation across networked machines is argued from PostgreSQL transactional guarantees, not yet demonstrated across hosts.

Next step

Run the MCP governance path in a pilot with your own MCP servers and inspect the binding and identity evidence.