EVE for Critical Infrastructure
For operators in energy, utilities, transportation, and other critical-infrastructure sectors deploying AI agents where a deterministic control point and verifiable evidence are essential.
The problem
In critical-infrastructure environments, an AI agent that can trigger actions must sit behind a deterministic control boundary that fails safely and produces a durable, checkable record. A probabilistic guardrail inside the model is not a control point.
How EVE helps
- Deterministic decision before the side effect. EVE CoreGuard makes a deterministic ALLOW / BLOCK / MODIFY decision before a governed action executes, with no LLM in the decision path.
- Fail closed. EVE supports embedded, hosted, sidecar, MCP-gateway, and sovereign/offline modes. In every mode, a service error fails closed — no SDK silently falls back to permissive behavior.
- Approved-vs-executed binding. For MCP tool calls, EVE cryptographically binds the approved request to the executed request; any mutation between approval and execution is rejected before the side effect.
- 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 controls. 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. In environments where a control must be in the path of the action, hard enforcement requires a gateway or sidecar.
Readiness
- EVE SDK core is a RELEASE CANDIDATE WITH EXCLUSIONS.
- MCP execution binding 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
- EVE supports evidence collection and helps enforce policy; it does not guarantee safety outcomes, guarantee compliance, or issue certification.
- 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.
- 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.