Kubernetes is a good control plane for running enterprise agents, but it is a high-impact tool: a single mis-scoped credential can turn a “helpful” agent into a cluster admin. For permissioned agents, treat Kubernetes actions as governed operations that require policy-as-code gates, not prompt-only instructions.
Claw EA runs OpenClaw as the baseline agent runtime, then wraps Kubernetes access in Work Policy Contracts (WPC) and CST so each run is constrained, attributable, and reviewable. When the agent uses models through clawproxy, you also get gateway receipts and a proof bundle for audit.
Step-by-step runbook
These steps assume Kubernetes access is connected via official API with enterprise buildout controls. The goal is to allow safe read operations by default and force explicit approvals for write and admin actions.
-
Define the Kubernetes “shape” you will allow: namespaces, resource types, and verbs (get/list/watch first). Decide which actions are always forbidden (for example: creating ClusterRoleBindings, reading Secrets, exec into pods).
-
Create a WPC that encodes those constraints, including allowed namespaces and a strict verb allowlist. Store it as a signed, hash-addressed artifact in the WPC registry (served by clawcontrols), and record the policy hash you intend to pin.
-
Issue a CST from clawscope for the job. Use CST scope hash and optional policy hash pinning so the run can only operate under the intended WPC, and so the token is not reusable outside the job.
-
Run the agent in OpenClaw with sandboxing enabled for tool execution, and with a tight tool allowlist. Keep “elevated” host execution off unless you have a specific, documented need.
-
Implement Kubernetes calls via official API and require an approval gate for write and admin actions. The approval gate should check the WPC, validate the CST, and enforce least-privilege auth scopes on the Kubernetes credential you supply.
-
Route model traffic through clawproxy so each model call emits gateway receipts. On completion, package receipts plus run metadata into a proof bundle, then store the audit artifact in Trust Pulse for later review.
Threat model
Kubernetes is not “just another tool” for agents. It is an authorization hub: if an agent can create workloads, it can often create new network paths, mount data, and establish persistence.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection turns into kubectl write | An attacker convinces the agent to apply YAML that creates a privileged pod or a backdoored deployment. | WPC verb allowlist with explicit approval gates for write/admin actions; CST policy hash pinning so “write” cannot be unlocked mid-run without a new policy. |
| Over-permissioned service account | The agent can list secrets, bind roles, or escalate to cluster-admin via RBAC changes. | Least-privilege Kubernetes RBAC; WPC forbids Secrets reads and RBAC mutation; require separate, time-bounded credentials for rare admin actions. |
| Namespace boundary confusion | The agent is intended to operate in a single namespace but queries or mutates other namespaces. | WPC namespace allowlist; deny cluster-scoped resources; enforce namespace scoping in the tool wrapper before issuing the API call. |
| Stealth persistence through workloads | The agent creates CronJobs, webhooks, or controllers that reintroduce malicious pods after cleanup. | WPC denies creation of workload controllers by default; require change-ticket style approvals for controller creation; keep a rollback plan that can enumerate and delete created resources. |
| Data exfiltration via logs or sidecars | The agent deploys a pod that scrapes internal services and exports data over allowed egress paths. | WPC forbids creating new Services/Ingress by default; egress allowlists enforced outside clawproxy can be implemented as an added control (optional). |
| Audit gaps | You cannot later prove what the model was asked, which model was used, or whether a run replayed a token. | Use clawproxy for gateway receipts; bundle into a proof bundle; use marketplace anti-replay binding (job-scoped CST binding) and store the artifact in Trust Pulse. |
Policy-as-code example
This example shows the intent of a Kubernetes WPC: allow safe reads in one namespace, forbid secrets and RBAC mutations, and require explicit approval for any write path. The WPC is a Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols), so the hash becomes the stable reference you pin in the CST.
{
"tool": "kubernetes",
"mode": "via_official_api",
"k8s": {
"allowedNamespaces": ["apps-prod"],
"allowedVerbs": ["get", "list", "watch"],
"allowedResources": [
"pods",
"deployments",
"replicasets",
"services",
"events"
],
"deny": {
"resources": ["secrets", "clusterrolebindings", "clusterroles"],
"verbs": ["create", "patch", "update", "delete", "exec"]
},
"approvalGates": [
{
"when": { "verbIn": ["create", "patch", "update", "delete"] },
"required": true,
"reason": "All writes require review against WPC and change ticket"
}
]
},
"modelTraffic": {
"mustUseClawproxy": true
}
}
What proof do you get?
For model traffic, clawproxy emits gateway receipts for each call, including the binding metadata needed for verification. Those receipts are collected with run context into a proof bundle so you can audit what was asked and what was answered, without relying on an operator’s logs alone.
For authorization, the CST from clawscope can be pinned to a policy hash so the run is cryptographically tied to the intended WPC. For replay resistance across jobs, marketplace anti-replay binding (job-scoped CST binding) reduces the risk that a token captured from one run can be reused in another.
For review and sharing, you can store the result in Trust Pulse as the place your audit team can retrieve and view the artifact. If you need independent verification, the proof bundle is the unit you hand to verification tooling and incident response.
Rollback posture
Rollback for agents touching Kubernetes must assume partial failure: some resources were created, others were updated, and the agent may have been interrupted. Plan rollback as a sequence of safe, deterministic actions, and require the agent to label everything it creates so cleanup is feasible.
| Action | Safe rollback | Evidence |
|---|---|---|
| Read-only investigation (events, pod logs metadata) | No rollback needed; ensure the agent did not elevate into exec or secret reads. | WPC shows read-only verbs; CST pinned to the WPC; proof bundle shows model decisions and tool intent. |
| Applied manifests (deployments/services) | Delete only labeled resources created by the run; then redeploy the last known good release from your CI system. | Approval record plus WPC gate; proof bundle correlates the change request to the run; cluster audit logs remain your source of truth for API actions. |
| RBAC or cluster-scoped changes (should be rare) | Revert RBAC bindings to a baseline, then rotate affected credentials and review for persistence (webhooks, controllers). | WPC should normally deny this; if permitted, it must be an explicit approval with a dedicated CST and short TTL. |
| Suspected compromise mid-run | Revoke the CST, stop the job, and quarantine the namespace; then enumerate and delete labeled workloads created during the run. | CST revocation event; job-scoped binding reduces replay; gateway receipts and proof bundle provide the investigative timeline for model activity. |
FAQ
Why is prompt-only control not enough for Kubernetes agents?
Prompts can be overridden by injection, tool output, or misaligned instructions, and Kubernetes consequences are durable. Policy-as-code in a WPC provides a machine-enforced boundary that the agent cannot “talk itself out of” during a run.
Is Kubernetes support a native Claw EA connector today?
No. Kubernetes can be connected via official API with enterprise buildout controls, and write and admin actions should require WPC approval gates, CST, and explicit least-privilege auth scopes.
What should be allowed by default for a new cluster integration?
Start with get/list/watch in a single namespace for non-sensitive resources, and deny Secrets and exec. Add narrowly-scoped write paths only when you have an approval workflow and a rollback plan you have tested.
How do gateway receipts help if the real risk is Kubernetes API access?
Receipts prove the model call history that led to an action, which helps determine whether the agent was instructed, injected, or malfunctioned. Kubernetes API auditing is still required for the authoritative record of cluster actions, but receipts close the gap on “why did the agent decide this.”
Where does OpenClaw fit in this stack?
OpenClaw is the agent runtime that executes tools and skills and can be sandboxed to limit local blast radius. Claw EA layers permissioning and verification around that runtime using WPC, CST, gateway receipts, and proof bundles.