EVE Sidecar · Egress Governance Gateway

The enforcement point AI egress cannot route around

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.

Or email us directly: [email protected]
The Problem

Software guardrails are advisory. Auditors want proof.

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.

Bypassable by design

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.

No proof it ran

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.

Fails open silently

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.

How It Works

Every egress request transits governance before it leaves the pod

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.

Customer App
libs, agents,
LLM callers
HTTPS_PROXY :3128
EVE Sidecar
relay to hosted
governance API
on pass · forwarded
Upstream API
model / endpoint
on violation: 451 + severed TCP connection + signed Decision Certificate
Pillar 128 (symbolic-assembly / attack detection) · CoreGuard policy evaluation · fail-closed wrapper run inline on every request
The sidecar is a 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).
Key Properties

A non-bypassable gateway that produces evidence

🚫

Mandatory gateway — non-bypassable

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.

🔒

Fail-closed enforcement

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.”

📜

Signed Decision Certificate

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.

📦

Drop-in Kubernetes sidecar

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.

Deployment Topology

One container in the pod, one init container for non-bypass

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"]
The full YAML, environment-variable reference, response-code table, and audit-trail format are in the Deployment guide.
Alternative

Prefer a library? Use the fail-closed wrapper

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
See the Deployment guide §7 (Fail-Closed Wrapper) for the full contract and guarantees.
Posture & Trust

Hosted SaaS. Signed image. Nothing proprietary on-prem.

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.

Hosted governance plane

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.

Signed container image

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.

Honest framing

The sidecar is a production-ready listener with fail-closed enforcement, available for controlled / pilot deployments. Some capabilities are on the roadmap rather than shipping today — see below.
Roadmap

What ships today, and what is coming

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).

CapabilityTodayPlanned
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
The full gap list lives in Deployment guide §9 (Known Open Gaps).

Put a non-bypassable gate in front of your AI

We’ll walk through your egress topology, the certificate format your auditors will verify, and a controlled pilot deployment for your environment.

Direct line: [email protected] · See pricing