EVE AI Core
The EVE Sidecar vetoes outbound AI and LLM traffic before it leaves the pod, severs the TCP connection on a violation, and emits a signed, offline-verifiable Decision Certificate — so you can prove governance actually ran. It is a thin, stateless signed container relay to EVE’s hosted governance API: a network gateway, not a self-contained engine.
An in-process SDK or a prompt wrapper is something your developers can disable, forget, or route around — and when an incident happens, you have no cryptographic record that the control ever executed. Regulated buyers need an enforcement point that sits in the network path, fails closed, and produces evidence.
A library import can be commented out, a flag flipped, or a second code path can call the model directly. Software-only guardrails depend on every caller cooperating.
Even when a guardrail is in place, there is rarely a tamper-evident artifact showing the decision executed. “Trust us, it was on” does not survive an exam.
When the guardrail crashes or times out, most systems let traffic through. The one moment you most need enforcement is the moment it quietly disappears.
Your application routes outbound HTTP(S) through the sidecar by setting HTTPS_PROXY to the sidecar on port 3128. The sidecar relays each request to EVE’s hosted governance API. On a pass, it forwards upstream and streams the response back. On a violation, it returns 451, severs the TCP connection, and emits a signed Decision Certificate. No upstream request is ever issued on a veto.
stdlib-only relay. No governance logic, model weights, or decision-making code runs inside it — the actual enforcement decision is made by EVE’s hosted governance plane, and the sidecar carries back the verdict and a signed certificate. Source for the sidecar is not provided; it ships as a signed container image (eveaicore/sidecar).
Deployed with an iptables egress redirect in the pod, outbound TCP on ports 80/443 is forced through the sidecar even if the application ignores HTTPS_PROXY. A developer cannot route around it without removing the network policy itself.
If the enforcement pipeline crashes or exceeds its timeout, the sidecar returns a veto — never a silent pass-through. This is Pillar 114 (Fail-Shut Invariance): the failure mode is “block,” not “allow.”
Every decision — allow, block, or fail-closed — produces an HMAC-SHA256 signed certificate with content hash, verdict, matched pillar, and timestamp. Your auditor can verify it offline months later, without contacting EVE.
One additional container in the same pod as your app. Stateless, signed image, configured entirely by environment variables. Standard /healthz and /readyz probes integrate with your existing orchestration.
The sidecar runs alongside your application container. An optional NET_ADMIN init container installs iptables rules that redirect egress to the sidecar, so enforcement holds even if the app never sets a proxy variable.
# Sidecar container — same pod as the app containers: - name: app env: - name: HTTPS_PROXY value: "http://127.0.0.1:3128" - name: eve-sidecar image: eveaicore/sidecar:latest ports: [{ containerPort: 3128 }] env: - name: EVE_PROXY_ORG_ID # tenant stamped into every cert valueFrom: { fieldRef: { fieldPath: metadata.labels['tenant'] } } - name: JWT_SECRET_KEY # HMAC signing key (from a Secret) valueFrom: { secretKeyRef: { name: eve-signing-key, key: hmac } } - name: EVE_PROXY_FAIL_CLOSED value: "1" readinessProbe: { httpGet: { path: /readyz, port: 3128 } } livenessProbe: { httpGet: { path: /healthz, port: 3128 } } # Init container — non-bypass egress redirect initContainers: - name: egress-redirect securityContext: { capabilities: { add: ["NET_ADMIN"] } } args: ["iptables -t nat -A OUTPUT -p tcp ! -o lo --dport 443 -j REDIRECT --to-port 3128"]
Teams that don’t want the proxy posture can consume EVE as a library with the same guarantees. The @enforce decorator bounds execution by a timeout, converts any exception or overrun into a fail-closed veto, and returns a signed HMAC-SHA256 certificate for every outcome.
from core.governance.fail_closed import enforce, FailClosedError @enforce(caller="my_service.call_llm", org_id="bank_tier1_a", timeout_s=2.0, run_fmi=True) def call_llm(prompt: str) -> dict: return llm_client.generate(prompt) try: result = call_llm(user_prompt) cert = result["certificate"] # signed allow cert except FailClosedError as e: cert = e.certificate.to_dict() # signed block or fail_closed cert
EVE is operated exclusively as a hosted service by EVE NeuroSystems LLC. What runs in your environment is a thin, stateless network relay — not the governance engine.
All policy evaluation, attack detection, and decision logic run on EVE’s hosted governance API. The sidecar relays requests and carries back verdicts — it makes no decisions of its own.
The sidecar ships as a signed image (eveaicore/sidecar). It contains no governance logic, no model weights, and no decision code, and its source is not distributed.
We are explicit about the current edges. HTTPS CONNECT tunnels are passed through today (the target host is still subject to veto, but plaintext body inspection requires TLS termination, which is on the roadmap).
| Capability | Today | Planned |
|---|---|---|
| TLS MITM with per-deployment root CA | CONNECT passthrough (host still vetoed) | Q2 2026 |
Helm chart + eveaicore/sidecar image |
Manual sidecar YAML | Q2 2026 |
Prometheus /metrics endpoint |
Logs only | Q2 2026 |
Envoy ext_authz gRPC filter |
Stdlib HTTP proxy only | Q3 2026 |
| Asymmetric signing (Ed25519 / ECDSA P-256) | HMAC-SHA256 (shared secret) | Q3 2026 |
We’ll walk through your egress topology, the certificate format your auditors will verify, and a controlled pilot deployment for your environment.