Deploy as a sidecar

Run EVE as a sidecar next to your application so tool calls are governed at a boundary that a direct in-process call cannot bypass. The client SDK talks to the sidecar over a reachable endpoint, and every decision fails closed on error.

Prerequisites

• The EVE service deployed as a sidecar with a reachable endpoint.
• The EVE client SDK (Python or TypeScript) configured for sidecar mode.
• Synthetic tools for testing; no production credentials.

Installation

pip install ./eve_coreguard-0.2.2-py3-none-any.whl        # Python client
npm install ./eve-coreguard-0.1.0-rc1.tgz                 # TypeScript client (ESM, Node >=18)

Deploy the EVE service as a sidecar and note its endpoint (for example a loopback or unix-socket address on the pod).

Runnable code

Python client pointed at the sidecar:

from eve_coreguard import EVE

eve = EVE(policy="lending_v1", mode="sidecar", api_key="eve_sk_...", endpoint="http://127.0.0.1:8001/v1")
decision = eve.govern_tool_call(
    tool="loan_approval",
    arguments={"amount": 1000},
    context={"tenant_id": "acme", "principal_id": "agent-1", "session_id": "sess-1"},
)
# The hosted/sidecar client returns a plain dict (portable shape); read fields by key.
print(decision["action"], decision["allowed"])

TypeScript client:

import { EVE } from "@eve/coreguard";

const eve = new EVE({ policy: "lending_v1", mode: "sidecar", endpoint: "http://127.0.0.1:8001/v1" });
const decision = await eve.governToolCall({
  tool: "loan_approval",
  arguments: { amount: 1000 },
  context: { tenantId: "acme", principalId: "agent-1", sessionId: "sess-1" },
});
console.log(decision.action, decision.allowed);

Expected result

• Governed calls return ALLOW / BLOCK / MODIFY from the sidecar.
• Because governance sits at a boundary, a direct call to the underlying tool that goes through that boundary is governed — unlike an in-process wrapper, which a direct call can bypass.

Evidence output

GovernanceResult{action: <...>, reason_codes: [...], decision_id: "...", certificate: {...}}

The certificate is signed (Ed25519 in production configuration, HMAC-SHA256 fallback) and verifiable offline.

Verification

Verify a sidecar decision's evidence independently (see verify-evidence-offline.md):

# The pip client verifies through the EVE instance (or eve_coreguard.verify_decision_record);
# in TS use @eve/coreguard verifyEvidence.
v = eve.verify("decision", decision["certificate"], expected_tenant="acme")
print(v["valid"], v["reason"])

Failure example

If the sidecar is unreachable, the client fails closed — Python raises, TypeScript returns a BLOCK. No client silently falls back to permissive behavior on a sidecar error.

Production considerations

• The sidecar boundary gives enforcement that a direct underlying-tool call cannot bypass, unlike wrapper-enforced adapters; route side-effecting calls through it.
• Sidecar mode requires a reachable endpoint; treat endpoint failure as a deny condition in your design.
• The production configuration refuses to disable signed evidence, strict verification, distributed consumption, fail-closed behavior, authenticated identity, or complete scanning.

Limitations

• Sidecar is one of the supported deployment modes (embedded, hosted, sidecar, MCP-gateway, sovereign); deploy.modes is PILOT_READY. Hosted/sidecar require a reachable endpoint.
• Hard, non-bypassable enforcement of tool calls requires this gateway/sidecar boundary; wrapper-enforced adapters alone are bypassable by direct underlying-tool calls.
• The TypeScript client governs via hosted/sidecar mode and never signs; embedded mode is Python/service-only (SDK_TS_EMBEDDED_UNSUPPORTED).

Next step

If you cannot run a sidecar, use use-the-hosted-service.md; for air-gapped deployments, see sovereign-offline-mode.md.