EVE for Security Teams

For security teams that need a deterministic control point in front of AI-agent tool calls, plus signed evidence of what the control decided.

The problem

Agentic systems widen the blast radius: a model can be steered into calling a tool, exfiltrating data, or chaining benign actions into a harmful one. Prompt-level guardrails are probabilistic and live inside the model you are trying to constrain.

How EVE helps

  • Decision before side effect. EVE CoreGuard makes a deterministic ALLOW / BLOCK / MODIFY decision before a governed action executes. Because no LLM is in the decision path, the control cannot be talked out of a block by the model's own reasoning.
  • Approved-vs-executed binding for MCP. EVE cryptographically binds the approved MCP request to the executed request; any mutation between approval and execution is rejected before the side effect. This closes the gap between what was approved and what actually runs.
  • Server-derived identity. MCP execution identity (tenant, principal, session) is server-derived from authenticated context; forged identity headers are rejected. Reverse-proxy identity headers are treated as untrusted.
  • Single-use authorizations. 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.
  • Sequence and budget enforcement. EVE can block individually-permitted actions that combine into a prohibited sequence, and enforce deterministic budget/resource limits.
  • Adversarial regression. A customer-runnable red-team harness exercises single-step and multi-step chains against your configuration; blocked attacks provably cause zero unauthorized side effects, and results are signed.

Enforcement placement matters

Wrapper-style adapters can be bypassed by a direct call to the underlying tool, and cooperative hooks are a cooperative boundary rather than a hard enforcement point. Hard enforcement requires a gateway or sidecar so the control sits in the path of the side effect, not beside it.

Readiness

  • EVE SDK core is a RELEASE CANDIDATE WITH EXCLUSIONS.
  • MCP execution binding, authenticated identity, and cross-process single-use consumption are PILOT_READY; distributed deployment is distributed-pilot validated in the documented test topology.
  • Signed evidence and offline verification are SUPPORTED.
  • The red-team harness is customer-pilot ready at supported boundaries.
  • Framework adapters other than the generic adapter are experimental.

Limitations

  • MCP binding provides at-most-once authorization consumption and approved-equals-executed binding; it does not provide exactly-once semantics for a remote side effect — an unknown remote outcome is recorded as OUTCOME_UNKNOWN, never silently retried.
  • Cross-process 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, not yet demonstrated across hosts.
  • Server-derived identity requires the authenticated middleware to be mounted.
  • Wrapper-enforced adapters are bypassable by a direct underlying-tool call; cooperative hooks are a cooperative boundary, not a hard enforcement point. Hard enforcement requires a gateway or sidecar.
  • Statistical anomaly detectors are advisory unless wired to a deterministic enforcement action.
  • The red-team suite is representative, not exhaustive; mappings are descriptive, not certification.
Part of the EVE AI Core control plane Deterministic AI Governance Control Plane → Policy decisions that return the same result for the same input every time, before execution.