Architecture overview
The control plane has three moving parts: a policy evaluator, a broker that carries the call, and an append-only decision log. Everything else is a way of reaching them.
However many modules the platform pages describe, the deployment footprint is small on purpose — a control plane that's hard to run is a control plane that gets bypassed under deadline pressure.
Components
| Component | Job |
|---|---|
| Gateway / broker | Terminates agent traffic, resolves secret handles, routes MCP and A2A calls |
| Policy evaluator | Evaluates the rule set against a call; pure, stateless, in-process |
| Decision log | Append-only, hash-chained store plus the checkpoint publisher |
| Dashboard / API | Policy management, the approval queue, the execution graph |
Where it runs relative to your agent
Three shapes, depending on the runtime: an SDK wrapping the tool-executor boundary in-process, a sidecar proxy alongside a container, or an MCP server entry a coding agent talks to directly. All three terminate at the same gateway.
agent process │ SDK wrap / MCP entry / sidecar proxy ▼gateway ──► policy evaluator (in-process) │ │ │ └─► permit / forbid / hold ▼[ vault ] [ mcp servers ] [ other agents via A2A ] [ your APIs ] │ ▼decision log (append-only, hash-chained)Statelessness and scaling
The evaluator holds no state between calls, so it scales the same way any stateless service does. The decision log is the one component with a real replication story — see High availability.
Deployment shapes
- Sidecar container next to an existing service
- Kubernetes DaemonSet for node-level enforcement without a sidecar per pod
- Fully self-hosted control plane inside your own VPC
- Hosted control plane (private beta)