EVE CoreGuard
Enforcement
EVE CoreGuard
Enforcement
The deterministic enforcement engine.
EVE CoreGuard evaluates every proposed AI action against your policy packs and returns ALLOWED, BLOCKED, or MODIFIED — before the action executes. It fails closed, runs a sub-millisecond deterministic gate, and ships wherever your workload runs.
ALLOWED · BLOCKED · MODIFIED — decided before execution, fail-closed
Most "guardrails" observe and annotate. EVE CoreGuard sits in the decision path: the proposed action is evaluated against policy and the verdict is binding. A BLOCKED action does not run.
The action is evaluated before it reaches the tool, the model output, or the downstream system. Enforcement happens up front, not in post-mortem.
Every request resolves to ALLOWED, BLOCKED, or MODIFIED — with a reason code and a signed record of which policy fired.
Policy packs compute deterministic risk and map it to a disposition. The same inputs always produce the same verdict.
{
"request_id": "req-001",
"tenant_id": "org_acme",
"proposed_action": { "type": "loan_approval", "amount": 50000 },
"context": { "credit_score": 610, "debt_to_income": 0.55 },
"policy_set": "lending_v1"
}
// → { "decision": { "status": "BLOCKED" },
// "risk": { "level": "HIGH" }, "audit": {…signed…} }
A safety control that fails open is not a safety control. If a policy is ambiguous, a dependency is unavailable, or the gate cannot reach a confident verdict, EVE CoreGuard denies by default — and records why.
The deterministic gate is a pure, side-effect-free function — no I/O, no model call. Its verdict executes in well under a millisecond, so enforcement is something you keep on in production, not a check you skip under load.
The pure veto/gate decision — no external calls, fully reproducible.
Runtime-integrity self-checks are short-TTL cached to keep per-decision overhead minimal.
Per-decision authorization is a constant-time check — latency stays flat as policy grows.
Sub-millisecond figures describe the deterministic gate decision. End-to-end policy evaluation latency depends on policy pack complexity and deployment topology.
Each tenant gets its own isolated policy set. Shared baseline rules are read-only; tenant-specific rules can only ADD restrictions — never weaken the platform's immutable controls.
Policy, decisions, and audit are scoped per org. The auth-derived tenant id is injected server-side — never trusted from the request body.
Reference packs like lending_v1 ship ready to use; custom packs are versioned so every decision cites the exact policy that fired.
Tenants tighten, never loosen. Immutable safety rules and red lines hold regardless of tenant configuration.
Token-by-token generation needs token-by-token governance. EVE CoreGuard enforces over streaming output, interrupting a response mid-stream the moment it crosses a policy boundary — not after the unsafe content has already shipped.
Not every decision should be automatic. High-consequence or ambiguous actions escalate to a human with the full context, a recommended disposition, and a bounded window — and the request holds until a decision is made.
EVE CoreGuard is the enforcement plane: it consumes a proposed action, applies the tenant's policy packs, and returns a binding disposition that the evidence plane then signs.
The same deterministic engine, four ways to deploy it — from a hosted API call to a fully air-gapped on-prem install.
Point your application at the decision endpoint. The fastest path to enforcement — one HTTP call per action, no infrastructure to run.
resp = requests.post( "https://api.eveaicore.com/v1/decisions/evaluate", headers={"Authorization": "Bearer eve_…"}, json=request) if resp.json()["decision"]["status"] == "BLOCKED": halt()
Co-locate the engine next to your service for low-latency, in-cluster enforcement with no external round-trip. Your data never leaves your trust boundary.
# app calls the local sidecar POST http://127.0.0.1:8700/v1/decisions/evaluate # sidecar enforces in-process, no external hop
Deploy as an in-cluster service or admission-style gate. Scale enforcement horizontally with your workloads and keep policy distribution declarative.
kind: Deployment spec: template: spec: containers: - name: eve-coreguard image: eve/coreguard:stable ports: [{ containerPort: 8700 }]
Run the engine entirely inside your environment — including disconnected, air-gapped networks. Policy, decisions, and evidence stay on your hardware.
# self-contained, no outbound dependency
docker run -p 8700:8700 \
-v ./policy:/policy \
eve/coreguard:onpremPut EVE CoreGuard in front of one real, high-stakes AI workflow. We'll stand up a policy pack, wire the gate, and show you blocked actions with signed evidence.