The sidecar topology puts policy evaluation on the same host as the agent. The decision never crosses the network, which is what makes it fast enough to sit in the execution path — and what keeps governance data inside your cluster.
Helm chart and manifestsScoped RBAC and namespaceCPU-bound decision path
Policy evaluation runs on the agent's own host, so the decision never crosses the network and governance data never leaves the cluster. A gateway that cannot answer fails closed for the agents it serves, rather than for the estate.
on-host decisiondata stays localinstall surface, not a reference topology
WHAT SHIPS
The install surface.
Asset
What it does
Helm chart
Chart and values for the gateway, for teams that install by chart rather than by manifest.
Gateway deployment
The governed decision endpoint, deployed into a namespace you control.
Namespace and RBAC
A dedicated namespace with a scoped service account, so the gateway holds only the cluster permissions it needs.
Secrets manifest
Wiring for the encryption key and credentials, which stay in your cluster's secret store.
Example agent
A worked deployment showing an agent alongside the gateway, so the first governed call is reachable from a running example rather than from prose.
Network policies
Cluster network policy definitions accompany the deployment manifests.
WHY SIDECAR
The topology the latency figure describes.
Property
Consequence
Evaluation is on-host
No policy decision leaves the node, so the decision path is CPU-bound rather than network-bound. This is the deployment model the benchmark measures, and the figure does not transfer to other topologies.
Governance data stays local
Decisions and their records are produced inside your cluster. Nothing about the call is required to leave it for the decision to be made.
Failure is contained
A gateway that cannot answer fails closed for the agents it serves, rather than for the estate.
If you already run an Envoy-family mesh, the ext_proc adapter is the shorter route: the decision goes where the gateway already sees the call, and no per-workload sidecar is added.
BEFORE IT IS SCHEDULED
The sidecar governs the host. Assurance governs the release.
Once a pod is running, the decision belongs at the egress boundary. Before it is scheduled, the question is different: should this agent be in the cluster at all? Assurance answers that against bars preregistered for the run, and returns a gate result rather than a score.
The verdict is bound to a snapshot, so it expires when the environment underneath it changes rather than persisting as a standing approval.