Use cases / Kubernetes & sidecar
Let agents run.
Keep production
under control.
Put AI agents to work on your Kubernetes clusters. GovernorAI lets routine work proceed, holds consequential changes for approval, and blocks destructive actions before they reach your systems.
This agent can use the scale tool. A production change still requires an SRE reviewer. Nothing has been dispatched.
- Policy decisionrequire approval
- Human authorityPending · SRE reviewer
- DispatchNot dispatched
- Target resultNot observed
Not dispatched. The deployment is unchanged.Inspect this decision
From copilot to production operator
More autonomy. Less production risk.
Give platform teams a path beyond read-only agents. Delegate the work, not the authority to decide what is acceptable.
Routine work proceeds. People handle the exceptions.
Let agents inspect services and carry out permitted remediation. Route consequential changes to the right reviewer without turning every task into a ticket.
Approve an increase in production replicas.
Stop the wrong change. Not the whole fleet.
Put limits around namespaces, resources and runs. Block destructive changes before dispatch and stop a runaway agent while every other agent keeps working.
Deny action 51 under a 50-action step limit.
Show who authorized it. And what actually happened.
Connect the workload, the exact request, the policy that matched and the human decision to the target's response. Security and operations read the same record.
Three states, never one green check.
In the product
See a held change and its record, in the console.
Recorded on a demo tenant: decisions at the action boundary, an action held with its reason, what each enforcement point can execute, and the record every decision leaves. The sidecar beside your agent reports into the same views.
Governed actions, step by step
Real product screens from a demo tenant with seeded activity: the outcome, the rule and the reason for each governed action.
In your cluster. Beside your agents.
Govern centrally. Enforce locally.
Review the policy once and evaluate it beside the workload. The sidecar runs the policy files mounted in its pod, plus the Rego and kill switches from a signed bundle it verifies before use. Routine decisions stay off the remote control-plane path, and approvals are recorded for review.
and API requests
Allow · Hold · Deny
Cloud & SaaS APIs
Local-sidecar pattern. Policy distribution and human review are separate from routine evaluation.
Keep the decision close.
Evaluate policy beside the workload. Local enforcement removes a remote control-plane round trip from routine action decisions.
Hold the change for a reviewer.
A held change becomes an action intent in the control plane. A reviewer approves or rejects that request. The approval is recorded; it does not release the held change.
Contain failure to its serving scope.
A local evaluator that cannot decide blocks new actions for the agents it serves. Valid cached policy can continue operating while the distribution plane is unavailable.
Three ways in
Pick the enforcement point your cluster already has.
Sidecar
- Use when
- Latency matters and you want governance per pod
- You add
- A GovernorAI sidecar container in the agent’s pod, with its policy mount
- Decision point
- Beside the workload
- Identity
- The registered agent and workload, recorded on every decision
Namespace gateway
- Use when
- Many small agents, or you cannot change pod specs
- You add
- A gateway deployment and authenticated client routing
- Decision point
- At the namespace gateway
- Identity
- The registered agent, recorded on every decision
Mesh ext_proc
- Use when
- Agent traffic already runs through an Envoy-family mesh
- You add
- An ext_proc adapter on an existing Envoy path
- Decision point
- At the configured adapter
- Identity
- The agent from the JWT your mesh verified, recorded on every decision
All three use one approval workflow, record to one evidence trail and show in one console. A sidecar runs the policy files mounted in its pod; the namespace gateway and the adapter use the policies managed in the console. Mix them per namespace.
Policy
Bring your Rego.
Native rules and Rego are evaluated together at the sidecar, under a shared action model. Reuse the Rego your security team already writes, and add agent-specific authority alongside it. CEL at the sidecar is planned.
- nativeReads the effective change. Match on resource, namespace, operation, resolved payload and risk, not on a free-text tool name.
- regoWhat your security team already writes. Bring existing Rego logic into the shared action context.
- celPlanned at the sidecar. CEL policies can be kept in the policy registry today; the sidecar does not evaluate them yet.
- signedA signed bundle, a recorded policy digest. The Rego and kill-switch bundle is signed in the control plane, and a sidecar refuses one it cannot verify. The sidecar logs the digest of the policy files it loaded when it starts.
# Standard rules: the YAML the sidecar loads
id: production-safety
name: production-safety
governance_mode: enforcement
fail_closed: true
session: {max_steps: 50}
rules:
- id: routine-inspection
priority: 20
match: {tool: deployments.get}
action: allow
- id: production-change-approval
priority: 10
match:
tool: deployments.scale
condition: {field: args.namespace, operator: in,
value: [prod-payments, prod-checkout]}
action: require_approval
- id: protected-namespace
priority: 1
match:
tool: namespaces.delete
condition: {field: args.name, operator: in,
value: [prod-payments, prod-checkout]}
action: deny
---
# existing-egress-rules (engine: rego, from the signed bundle)
package agents.egress
import rego.v1
default deny := false
deny if input.inspection.destination_is_externalView the complete policy files
# production-safety.yaml: Standard (native) rules.
# Mounted from the governor-policies ConfigMap and read
# when the sidecar starts.
id: production-safety
name: production-safety
namespace: agents
governance_mode: enforcement
fail_closed: true
session:
max_steps: 50 # action 51 in a run is denied
tools:
allowed: [deployments.get, deployments.scale, namespaces.delete]
rules:
- id: production-change-approval
priority: 10
match:
tool: deployments.scale
condition:
field: args.namespace
operator: in
value: [prod-payments, prod-checkout, prod-pipelines, prod-research]
action: require_approval
- id: routine-inspection
priority: 20
match: {tool: deployments.get}
action: allow
- id: protected-namespace
priority: 1
match:
tool: namespaces.delete
condition:
field: args.name
operator: in
value: [prod-payments, prod-checkout, prod-pipelines, prod-research]
action: deny
---
# existing-egress-rules: a Rego policy from the signed bundle
# (decision: allow, deny, require_approval, reason)
package agents.egress
import rego.v1
default deny := false
deny if input.inspection.destination_is_external
reason := "egress outside the cluster API" if denyDeep Kubernetes integration
Native to the way your platform team works.
From the release pipeline to the next tool call, agent authority stays connected to the cluster, the workload and the change being made.
Assurance before deployment
Run GovernorAI’s assurance gate before deployment: a decision surface a deploy step can consume; shown today as a demo, not yet the automated stop in your pipeline. Enforcing it at Kubernetes admission is planned.
Ship policy with Argo CD or Flux
Keep the policy files in Git and let Argo CD or Flux deliver the set the sidecar loads from its policy mount at start.
Policy keyed to the workload
Policy is keyed to the agent and workload you register, and every decision records which one acted. The sidecar sits inside the pod boundary you already trust, next to your RBAC and NetworkPolicy.
See the alternate paths
GovernorAI shows which agent actions take the governed path and flags the ones that don't. Pair it with NetworkPolicy and scoped credentials to close them.
Stop one agent, not the cluster
A kill switch is scoped to an agent, a tool or a namespace, and the scope is recorded. Each gateway sends a signed heartbeat to the control plane.
Cluster discovery is planned
Finding unregistered agents in a cluster from workload metadata, AI SDK indicators and MCP configuration is planned. Today, register each agent and workload you put behind the sidecar.
Add the missing operating layer
Keep your security stack. Add agent-aware change control.
Keep the controls you already trust. GovernorAI connects release context, policy, approval and target results into one operating workflow for consequential agent actions.
| Layer | You may already run | What it decides | What GovernorAI adds |
|---|---|---|---|
| Admission | Kyverno · Gatekeeper · admission policy | Resource admission and release-evidence checks. | Release trust connected to runtime authority.Carry the assessed agent snapshot into the decisions made after admission. |
| Mesh and gateways | Istio · agentgateway · Envoy | Traffic, tool access and application policy at the configured path. | One reviewed change, through your existing path.Coordinate approval holds and evidence through the adapter. |
| Kernel runtime | Tetragon · runtime detection tools | Process, file and network controls or observations. | Action meaning and its authority.Join application-level approval with lower-level runtime controls. |
| Sandboxes | OpenShell · agent-sandbox | Execution isolation and configured access policy. | Coordinated authority across boundaries.An action approval does not widen a stricter sandbox boundary. |
| Policy engines | OPA · Kyverno · CEL | Policy evaluation, verification and related control workflows. | One shared action context.Connect native rules and Rego to the policy, the approval and the target result. |
Access is necessary. It is not the whole decision. A permitted scale tool can still require approval for a production change.
Even on one platform
Even if everything runs in your own clusters.
"Our own clusters" describes where your agents run. Governance is about what they do, who answers for it, and what you can prove. None of those stop at the cluster boundary.
Kubernetes governs deployment and access. Not the business action.
RBAC decides which verbs a ServiceAccount may use on which resources. Admission controllers and policy engines such as Gatekeeper and Kyverno decide which objects may enter the cluster. NetworkPolicy and a service mesh decide which workloads may talk to which. None of them decides whether this change, by this run, needs an SRE to say yes.
The consequences land outside the cluster.
The agent in your pod refunds in Stripe, files in ServiceNow and writes to your warehouse. Those calls are not Kubernetes objects, so admission control never sees them. NetworkPolicy can allow or block the destination; it cannot read the amount, hold it for its owner or count it against the case.
The authority sits outside the platform team.
Cluster administrators own RBAC, admission and the mesh. The people who answer for a production change, a refund or a disclosure are SREs, Finance and Legal. A ClusterRole cannot route a request to its accountable owner and record who said yes.
Evidence has to survive cluster churn.
Pods restart, namespaces are deleted, clusters are rebuilt, and the API server audit log rolls over on its own retention. That log records requests to the cluster, not the agent’s decision, the approval or what the external system did. The record an auditor asks for has to outlive the cluster it was made in.
One production change, end to end.
In this example, Kubernetes permissions are configured as usual, and the production-change rule is managed in GovernorAI.
- Kubernetes The change is within the agent's configured Kubernetes permissions.
- GovernorAI GovernorAI requires SRE approval before submitting it. The production-safety policy holds the production change, and nothing is submitted to the cluster while it is held.
- SRE The reviewer approves or rejects. The decision and who made it are recorded with the change.
- Record The record carries the policy and rule that decided and the outcome, and it outlives the cluster it ran in.
And when your agents reach beyond the cluster: one policy, one ledger, one evidence chain across Kubernetes, AWS, Azure, Google Cloud, Databricks, MCP, Salesforce and ServiceNow. See how one policy governs everywhere
One traceable chain of authority
From the release you trusted to the change that happened.
Policy authorization, human approval, dispatch and the target's response each get their own record. Connect them in one trail that security, operations and audit teams can use.
The assessed workload
The agent snapshot and deployment identity that entered production, and the verdict that let it in.
The active policy
The policy and rule that decided at the enforcement point, when one did.
The exact request
The target, the resolved payload, the resource version and the reviewer's decision on this change, which covers no other.
The target's response
What was dispatched, what the API accepted or rejected, and whether the rollout actually reached ready. Unknown stays unknown.
Correlate decisions with OpenTelemetry traces and operational Prometheus metrics. Keep the per-action evidence trail alongside—not inside—your metrics counters.
Beyond the cluster
One authority. Wherever your agents work.
Extend the same governance lifecycle across cloud runtimes and enterprise systems. Keep policy ownership, approval and evidence connected as your agents move between environments.
Install
One namespace. A governed first workflow.
Add the sidecar
Add the GovernorAI sidecar container to the agent’s pod spec, from the deployment manifest supplied with your GovernorAI release. Connect identity and the secret store your team already operates. A versioned chart is planned.
Mount the policy
Put the policy files in a ConfigMap mounted at the sidecar’s policy path, and roll out the workload through your normal deployment process. The sidecar reads them when it starts. Namespace opt-in with automatic injection is planned.
Exercise the decisions
Start with the sample workflow, check the policy digest the sidecar logs at start, and exercise allow, hold and deny.
Sidecar installs are set up with an engineer during a briefing while we finish verification of this install path.
Offline-tolerant; self-hosted control plane scoped per engagement.
Your first governed Kubernetes workflow
Start with one agent. One namespace. One real outcome.
Bring a workflow that needs more than read-only access. In a six-week design partnership we define its boundaries, exercise the controls under approval, denial and failure, and measure the production path together.
Questions platform teams ask
Before you install.
Does the agent need any code changes?
Run the GovernorAI sidecar beside the agent for a local path, or connect the gateway and mesh your team already runs. Where the existing path exposes the action, governance can be added without rewriting agent logic. An SDK is available for explicit integration.
Does a human approval block the Kubernetes API server?
No. Human review belongs in a durable action workflow, not in a waiting admission request. The approval is recorded on that request and does not release it; the execution result is recorded separately.
What happens if the control plane is unreachable?
Local enforcement continues with the policy files the sidecar loaded at start and the last bundle it verified. When that bundle expires, the sidecar reports itself degraded. Approvals need the control plane. With the signed bundle configured, decision events are written to a local log and sent when the control plane is reachable again.
We run Istio. Do we need another sidecar?
Use the ext_proc adapter on an existing Envoy path. The adapter passes the action and the caller identity from the JWT Envoy verified to the configured decision service, with the same approval and evidence workflow.
Does this replace Gatekeeper or Kyverno?
Keep your existing policy and admission controls. GovernorAI adds the shared action context, approval holds and execution trail. Bring Rego logic into that context alongside native rules; CEL at the sidecar is planned.
Kubernetes already has RBAC, admission control and NetworkPolicy. Why add GovernorAI?
Keep them; they stay the floor. RBAC decides which verbs a ServiceAccount may use, admission control decides which objects enter the cluster, and NetworkPolicy and the mesh decide which workloads may talk. GovernorAI decides the action itself: this change, by this run, under this policy, held for a named reviewer where the policy requires one, and a record that follows the call to systems outside the cluster and outlives the cluster it ran in.
Can it run fully inside our perimeter?
Yes. Use a self-hosted control plane, so policy and evidence stay in your environment. External tools still receive the requests you authorize; governance-service placement is under your control.
What does the published benchmark measure?
The in-process policy engine on Apple M4 hardware. It excludes adapter, transport and audit I/O. The pilot measures the full action path on your cluster. Read the measurement method ↗
Your first governed workflow
Full speed. Under your control.
Bring one consequential workflow. See how local policy, approval holds and target evidence fit your Kubernetes environment.