Runs where your workload runs
The same deterministic engine, four ways to deploy it — from a hosted API call to a fully air-gapped on-prem install. The decision logic is identical across all four; only where it runs changes.
Runs where your workload runs
The same deterministic engine, four ways to deploy it — from a hosted API call to a fully air-gapped on-prem install. The decision logic is identical across all four; only where it runs changes.
Hosted API
Point your application at the decision endpoint. The fastest path to enforcement — one HTTP call per action, no infrastructure to run.
- Single /v1/decisions/evaluate call
- Bearer-authenticated, tenant-isolated
- Managed updates and policy distribution
resp = requests.post( "https://api.eveaicore.com/v1/decisions/evaluate", headers={"Authorization": "Bearer eve_…"}, json=request) if resp.json()["decision"]["status"] == "BLOCKED": halt()
EVE Sidecar
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.
- Loopback / localhost decisions
- No egress for evaluation
- Drop-in next to any service
# app calls the local sidecar POST http://127.0.0.1:8700/v1/decisions/evaluate # sidecar enforces in-process, no external hop
Kubernetes
Deploy as an in-cluster service or admission-style gate. Scale enforcement horizontally with your workloads and keep policy distribution declarative.
- Service or sidecar injection
- Horizontal scale, health-checked
- Declarative policy rollout
kind: Deployment spec: template: spec: containers: - name: eve-coreguard image: eve/coreguard:stable ports: [{ containerPort: 8700 }]
On-Premises / Air-Gapped
Run the engine entirely inside your environment — including disconnected, air-gapped networks. Policy, decisions, and evidence stay on your hardware.
- Fully self-hosted, no callbacks
- Air-gap compatible
- Hardware-attested options on the roadmap
# self-contained, no outbound dependency
docker run -p 8700:8700 \
-v ./policy:/policy \
eve/coreguard:onpremWhich deployment fits
The engine is identical; the trade-off is between time-to-enforcement and how tightly the data and decision stay inside your boundary.
| Model | Best when | Data boundary |
|---|---|---|
| Hosted API | You want enforcement in one call, no infra to run. | Request crosses to the hosted endpoint. |
| Sidecar | You need low latency and no external round-trip. | Stays in your cluster — loopback decisions. |
| Kubernetes | You're scaling enforcement with your workloads. | In-cluster, horizontally scaled. |
| On-Prem / Air-Gapped | You require full self-hosting or no egress. | Never leaves your hardware. |
Common questions
How can EVE CoreGuard be deployed?
Can it run air-gapped with no outbound network?
Does the sidecar keep my data in my trust boundary?
Request a Design Partner Pilot
Put 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.