Skip to content

Architecture

Kaizen has three parts tied together by one idea: the Observer runs as a sidecar in your own tenant, and its strongest form, the Kaizen Sandbox, makes the whole decision inside a microVM so that only the verdict ever leaves.

The three parts

  • Client (data plane). A lightweight library in-process with your agent. It reports each action and can block a known-bad call locally. SDKs for Python and TypeScript, an MCP shim, and framework hooks.
  • Observer. An isolated service that learns each agent's normal behaviour and evaluates deviations in two stages. It runs next to your agent, as a sidecar, in your own environment.
  • Control plane. The managed API and console for policy, keys, verdicts, and exports.

Where the parts connect

The Kaizen Sandbox

The deepest deployment, and the one that is hard to copy. The Observer runs inside a microVM next to your agent, in your own tenant. It judges what the agent reports it did against what it actually did, using your own model key, decides locally, and the control plane receives only the verdict. The raw behavior never crosses the boundary and is destroyed with the microVM. This is how Kaizen gives you data sovereignty by construction, and how it catches an agent that reports one thing and does another.

Kaizen runs in an isolated microVM in your tenant and sends out only the verdict

See the Kaizen Sandbox case study.

The sidecar

The Observer, plus the egress collector, deploys as a sidecar: one small unit that runs beside your agent and its runtime. Actions go in, verdicts come out, and nothing else crosses its boundary. Because it reads untrusted agent input, isolating it means a compromised observer can do nothing. With the reasoning check enabled in the sidecar, even the model call and the raw action sequence stay inside your tenant; only verdicts leave.

The same sidecar runs as a local process in development, a container on your infrastructure, or a hardened deployment in your environment. The Kaizen Sandbox above is its strongest form. See The sidecar.

What runs in your tenant

Observation depth

How deeply the sidecar attaches decides how much it can trust. The lighter attachment points are cooperative hooks an agent could route around; the deeper ones are ground truth.

Where you can attach, from a cooperative hook to a ground-truth collector

The ground-truth attachment points, the egress proxy and the eBPF or sandbox collector, are delivered by the sidecar. The same Observer and the same verdict contract serve every attachment point, so you can start light with a framework adapter and deepen to the sidecar later without re-platforming. See Observation depth.

How a verdict flows

The deterministic check is local and immediate; the reasoning check sits just behind it in the sidecar and never slows the agent. The contract is the same however you attach:

inspect(action) -> { decision: allow | block, reason, evidence, confidence }