EVE Security

How EVE's governance is designed to fail closed, resist forged identity, and keep secrets out of the client — with independently verifiable evidence.

Who this is for

Security engineers and reviewers evaluating whether EVE's enforcement path can be trusted: what happens on error, whether identity can be forged, where signing keys live, and what the evidence actually proves.

The problem

A governance layer that fails open, trusts client-supplied identity headers, or ships signing secrets into a browser bundle is not a control — it is a liability. You need enforcement that fails closed, derives identity from authenticated context, keeps signing off the client, and produces evidence a third party can check.

Supported security properties

• Fail-closed in every mode. 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 (service down → BLOCK or raise, never a silent ALLOW).
• Server-derived authenticated identity. MCP execution identity (tenant, principal, session) is server-derived from authenticated context; payload/header identity assertions must match or the request is rejected. A forged tenant header is rejected with reason code MCP_UNTRUSTED_PROXY_IDENTITY; reverse-proxy identity headers are treated as untrusted.
• Approved-versus-executed binding. EVE cryptographically binds the approved MCP request to the executed request; any mutation between approval and execution is rejected before the side effect.
• At-most-once authorization consumption. Single-use authorizations are atomically consumed via a PostgreSQL-authoritative backend, so one authorization cannot be consumed twice — validated across separate OS processes in the documented test topology.
• Signing stays off the client. The TypeScript SDK never signs and holds no secrets; it only verifies. Release artifacts contain no private keys, credentials, or .env material (verified in artifact inspection).
• Independently verifiable evidence. Signed evidence can be verified independently and offline in Python, Node, or the browser, without trusting the EVE server.

Readiness: identity, execution binding, and consumption controls are PILOT_READY; signed evidence and offline verification are SUPPORTED.

How it works

1. Identity is derived server-side from authenticated context; client-supplied identity must match or the request is rejected.
2. Decisions are computed by deterministic policy code with no LLM in the decision path.
3. On any service error, the SDK fails closed.
4. Evidence is signed inside the service (ECDSA P-384 (AWS KMS) in production configuration) over jcs-1; the verifying client never holds secrets.
5. Any party with the public key can verify the evidence offline.

Technical example (forged identity rejected)

{
  "request": { "headers": { "X-Tenant": "org_victim" } },
  "authenticated_context": { "tenant_id": "org_attacker" },
  "action": "BLOCK",
  "reason_code": "MCP_UNTRUSTED_PROXY_IDENTITY"
}

Signed evidence example

{ "content_hash": "…", "canon": "jcs-1", "signature": "kms-ecdsa-p384-…", "decision": { "action": "BLOCK" } }

Verifier example

from core.eve_sdk import verify_evidence
report = verify_evidence("decision", envelope)  # {"valid": True, "reason": "certificate verified", "checks": {...}}

Deployment options

Security properties apply across embedded, hosted, sidecar, MCP-gateway, and sovereign modes. Production configuration refuses to disable signed evidence, strict verification, distributed consumption, fail-closed behavior, authenticated identity, or complete scanning. Hard enforcement of tool calls requires a gateway or sidecar rather than a wrapper adapter alone.

Readiness

Fail-closed deployment, authenticated identity, execution binding, and distributed consumption are PILOT_READY (distributed consumption is distributed-pilot validated in the documented test topology). Signed evidence and offline verification are SUPPORTED. The EVE SDK core overall is a RELEASE CANDIDATE WITH EXCLUSIONS.

Limitations

• Authenticated identity requires the auth middleware to be mounted.
• Execution binding provides at-most-once 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.
• Distributed consumption was validated single-host across separate OS processes; multi-host across networked machines is argued from PostgreSQL's transactional guarantees but not yet demonstrated across hosts.
• Verification proves evidence authenticity, not decision correctness. Independent verification requires the ECDSA P-384 public key; the HMAC fallback is symmetric and not independently verifiable.
• Wrapper-enforced framework adapters are bypassable by a direct underlying-tool call; Claude Code hooks are cooperative and are not an unbypassable boundary. Only the generic adapter is validated.
• The clients are published on public registries: pip install eve-coreguard (PyPI) and npm install eve-ai-governance (npm).

Next step

Request a pilot to review EVE's fail-closed behavior, forged-identity rejection, and evidence verification against your own threat model and configuration.