GovernorAIby SentinelLayer Request a briefing
Find and qualify
Discovery & Shadow AIInventory the AI activity nobody registered AssuranceEvaluate an agent snapshot before production
Decide and enforce
Policy & GovernanceKeep the policy engine you already run Runtime EnforcementDecide at the action boundary Inference & Model GovernanceGovern the model call itself Multi-cloudOne policy, each cloud's own controls
Prove and observe
Evidence & ComplianceTamper-evident record, mapped to controls Decision ObservabilitySee the decision behind the action
Risk and security
RiskScore the action, and act on the score ContainmentStop a runaway run before it lands Security architectureHow the control plane itself is built
By persona
SecurityPer-call authorization and stop controls GRCEvidence chains and control mapping Platform & AI EngineeringGovern without touching the agent
By risk
Shadow AIUnmanaged agents and connections Data leakageIn prompts, completions and tool calls Destructive actionsChanges to systems of record
By platform
AWS BedrockInbound path, guardrail attachment ServiceNowNow Assist discovery and scoped control SalesforceAgentforce and Einstein Bots, in-org MCPRegistry, proxy, argument-aware inspection
By cloud and runtime
AzureConnect, discover, govern at the gateway Google CloudValidated connect mode, bootstrap session DatabricksCluster-side egress, pinned at create Kubernetes & sidecarIn your cluster, on the agent host

USE CASES / KUBERNETES

In your cluster, on the agent's host.

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 manifests Scoped RBAC and namespace CPU-bound decision path
IN YOUR CLUSTER, ON THE AGENT'S HOST CLUSTER NAMESPACE POD · ONE HOST Agent makes the call Gateway sidecar decides, on this host The decision never crosses the network; data stays in the cluster. An install surface, not an opinionated production topology.

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.

Honesty note

The manifests in the cloud-provider assets are an install surface, not an opinionated production topology. No production reference architecture is published separately from them. What the assets do carry is a set of defaults, and those are worth reading before you treat them as one.

The namespace manifest enforces the restricted Pod Security Standard — enforce, audit and warn are all set to it — alongside a resource quota and a limit range, and the chart declares a Kubernetes 1.25 floor. The control plane defaults to two replicas with a pod disruption budget and pod anti-affinity, requesting 200m of CPU and 256Mi of memory. The sidecar is deliberately small: 100m and 128Mi requested per sidecar in the chart, and less again in the worked manifest. The example workload carries a horizontal pod autoscaler ranging from one to ten replicas against CPU and memory targets, and network policy definitions ship alongside the RBAC manifest.

The sidecar is declared per workload, not injected. Every deployment in the assets lists the gateway container beside the application container in its own pod spec. GovernorAI does not ship a mutating admission webhook, so if you want injection to be automatic and impossible for a team to opt out of, that is a platform component you build and operate. Sizing beyond these defaults, autoscaling policy and mesh interaction remain deployment decisions this page does not make for you.

Continue

BenchmarkLatency in the sidecar model Runtime EnforcementEvery enforcement point and its verdict QuickstartA first governed tool call