The OpenClaw Operator's Default-Deny Baseline: What One CRD Can (and Cannot) Contain

In two weeks, security researchers counted more than 30,000 OpenClaw AI agents exposed to the public internet — leaking API keys, chat histories, and account credentials. That is the backstory behind the OpenClaw Kubernetes operator that reached Show HN's front page: a single custom resource that deploys an agent with non-root execution, dropped Linux capabilities, a default-deny NetworkPolicy, configuration-hash rollouts, and an optional hardened Chromium sidecar, all by default. The question worth asking before you install it is not whether those controls are good — they are — but where they stop. Kubernetes can contain what an agent process does. It cannot contain what an agent decides.

30,000 exposed agents is why the defaults matter​

OpenClaw — the open-source personal AI agent by Peter Steinberger that crossed 180,000 GitHub stars and drew 2 million visitors in a single week — became the fastest-adopted agent runtime in history and, simultaneously, the most aggressively scrutinized one from a security standpoint. The numbers from the first half of 2026 explain why a hardened operator exists at all:

• Bitsight observed more than 30,000 distinct OpenClaw instances exposed online between January 27 and February 8, 2026.
• SecurityScorecard found 15,200 of those instances exploitable via remote code execution through three high-severity CVEs, the worst rated CVSS 8.8.
• Cato Networks put the total internet-facing population near 500,000 instances in a late-March check.
• Cisco called the project "an absolute nightmare" from a security perspective; Gartner labeled it an "unacceptable cybersecurity risk to enterprises."
• The skill supply chain fared no better: Koi Security found 12% of ClawHub skills confirmed malicious, and Snyk's ToxicSkills audit flagged over a third of skills for security concerns.

The default deployment story was a big part of the problem: an agent that can run shell commands, browse the web, and hold your messaging credentials, installed with whatever permissions the installer happened to have. The Kubernetes operator is the community's answer — take the same agent and wrap it in every Pod-level control the platform offers, switched on by default rather than documented as an exercise for the reader. That is a genuine improvement. It is also, by construction, only half the job.

What one CRD buys you: five controls, five stopped threats​

The operator (Apache-2.0, installable via Helm) manages the full agent deployment — StatefulSet, Service, RBAC, NetworkPolicy, PVC — from one OpenClawInstance resource. Its security baseline reads like a checklist from a Kubernetes hardening guide, which is exactly the point: each default maps to a concrete attack it stops.

Note the deliberate split in that last row: everything above it ships switched on, while the Chromium sidecar is opt-in. That matches how the risk breaks down — the first four controls cost you nothing at runtime, while a browser sidecar adds memory, a CDP endpoint, and a whole web-facing attack surface you should only accept if the agent actually needs to click things.

Supply-chain hygiene comes along for the ride: multi-arch images, Cosign keyless signatures, SBOM attestations, and Trivy plus gosec in CI. For a project whose ecosystem accumulated over 280 GitHub Security Advisories and 100 CVEs in months, signed and scannable artifacts are not garnish.

This is the "can contain" half, and it is worth stating plainly what it achieves: if the agent process turns hostile — hijacked, exploited, or just buggy — the blast radius ends at the Pod boundary and the allowlisted egress set. That is precisely what Kubernetes enforcement is good at, and the operator turns it on with one YAML file instead of five.

What the CRD cannot contain​

Here is the uncomfortable half. Every control above constrains the agent's process. None of them constrains the agent's judgment — and an AI agent's judgment is exactly what attackers target. Three risks survive Pod hardening intact:

1. Prompt injection walks through every firewall you own.

The canonical example, reported by The Hacker News, starts with a prompt-injection payload embedded in a crafted WhatsApp message that tricks an exposed OpenClaw instance into exfiltrating its own .env and creds.json — API keys and session tokens included. Note what made that attack work: the exfiltration channel was the agent's legitimate tooling, used exactly as designed, on instructions the model could not distinguish from its owner's. No NetworkPolicy stops that, because the traffic goes to an allowlisted destination through an approved tool. A default-deny egress policy bounds where a compromised agent can phone home; it cannot judge whether the message it sends is something the owner actually wanted sent. As one Kubernetes sandboxing discussion put it: a stronger kernel boundary does not fix prompt injection, but it does bound what a compromised agent can do next.

2. MCP credentials are broader than the task, by protocol design.

The Model Context Protocol has no standard for per-tool authorization: a server declares tools, but it cannot declare which agents may call which tools — so every connected agent effectively gets every tool. Industry analyses of the 2026 agent-security landscape keep landing on the same finding: over-delegated MCP servers (broad file read/write, privileged API tokens, unrestricted network access) turn one confused agent into a skeleton key. Microsoft has warned specifically about malicious instructions hidden in MCP tool descriptions — metadata the agent reads as guidance, part of the software supply chain no checksum covers. The operator can mount a credential as a read-only secret; it cannot make that credential scoped to the current task. Only short-lived, least-privilege tokens issued per session — and servers that treat untrusted tool output as hostile input — close this gap.

3. Destructive tools need authorization, not just isolation.

An agent that can rm -rf the workspace, force-push to main, or delete production resources is dangerous even in a perfectly hardened Pod, because the damage happens through legitimate capabilities. The operator gestures at this with its allowedActions policy: self-configuration requests are validated before they apply. That is the right instinct, and it needs to extend to every destructive tool the agent holds — an explicit allowlist of actions, with human approval in the loop for anything irreversible. Pod Security Standards will never give you that; it is an authorization layer above the orchestrator, and you have to build or buy it separately.

The pattern across all three: Kubernetes answers "what may this process touch?" while agent security also needs "what may this agent decide?" — and no CRD, however well-designed, spans that gap by itself.

The minimum-security test for any agent sandbox on your fleet​

The operator is still useful beyond OpenClaw itself: treat its defaults as the floor for any deploy-from-chat or coding-agent sandbox you run on a Cluster-API fleet, then add the layers it cannot provide. Before an agent workload lands on shared nodes, it should pass this checklist:

• Kernel boundary stronger than a plain container. The kubernetes-sigs/agent-sandbox project — now a formal SIG Apps subproject — treats gVisor or Kata Containers via RuntimeClass as the standard backend for untrusted agent code. If the agent executes anything the model wrote, a shared-kernel container is not sufficient isolation.
• Default-deny egress with an explicit allowlist. Model provider APIs and required services only. This is the single control that turns "prompt injection succeeded" from "credentials are gone" into "an attack was attempted."
• Scoped, short-lived credentials. No long-lived cloud tokens or broad API keys mounted into the agent's environment. If a .env exfiltration would end your week, the credential design is wrong, not just the sandbox.
• Tool allowlist with human approval for destructive actions. Enumerate what the agent may invoke; require explicit confirmation for irreversible operations. The operator's allowedActions is a starting point, not the ceiling.
• Audit trail of tool calls. Every action the agent took, with inputs, attributable after the fact. When — not if — something surprising happens, the log is how you learn whether it was malice, confusion, or your own misconfiguration.

If a sandbox proposal on your fleet cannot check all five boxes, it is not ready for untrusted input — which, for an agent reading chat messages, web pages, and repo contents, means it is not ready at all.

Contain the process, govern the decisions​

The OpenClaw operator's real contribution is not any single control — non-root pods and NetworkPolicies are old news — but the packaging: a default-deny baseline that arrives in one install instead of accreting over three incidents. Teams running agents on Kubernetes should steal that baseline wholesale. They should just remember what it is: containment for the process, not governance for the decisions. Prompt injection, credential scope, and tool authorization live one layer up, where the orchestrator cannot see them — and that layer is now the actual security boundary for every agent you deploy.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. AI agents are first-class operators there too, which is why sandboxing them properly matters. Star the repo on GitHub or deploy your first app today.