Notifications
Clear all
Topic starter
21/08/2026 5:00 pm
TL;DR: OpenClaw reached 247,000 GitHub stars but also accumulated 512 vulnerabilities, including a CVSS 8.8 WebSocket auth bypass and over 53,000 exposed instances, according to AccuKnox. ClawArmor argues that application-layer fixes are not enough because prompt injection, tool abuse, and sandbox bypass require kernel-level enforcement that constrains runtime behaviour.
NHIMG editorial — based on content published by AccuKnox: Introducing ClawArmor and securing OpenClaw instances with sandboxing
By the numbers:
- A full audit identified 512 vulnerabilities in OpenClaw, including 8 critical issues.
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do application-layer controls often fail for AI agent security?
A: Because the agent’s dangerous actions happen after the model has already produced a decision.
Q: What breaks when AI agents are given broad inherited permissions?
A: Broad inherited permissions break the assumption that access is tied to a narrow business need.
Practitioner guidance
- Define kernel-enforced allowlists for agent workloads Restrict file paths, binaries, and outbound destinations at the Linux kernel layer so the agent cannot override policy through prompts or tool calls.
- Remove broad execution paths from agent containers Do not mount the Docker socket, do not grant privileged mode, and do not leave shell utilities or package managers available unless explicitly required.
- Separate agent secrets from general runtime context Store credentials outside the agent process and deny direct access to .aws, .kube, .ssh, and other key material from the workload identity.
What's in the full article
AccuKnox's full article covers the operational detail this post intentionally leaves for the source:
- The specific KubeArmor policy structure used to block file, process, and egress actions in OpenClaw deployments.
- The full default-configuration risk matrix showing how each exposed path maps to a control outcome.
- Deployment guidance for Kubernetes and bare metal environments, including policy application and telemetry flow.
- The practical differences between application-layer patching and kernel-level sandbox enforcement for AI agents.
👉 Read AccuKnox's analysis of OpenClaw sandboxing and kernel-level enforcement →
OpenClaw sandboxing and kernel enforcement: are runtime controls enough?
Explore further
21/08/2026 5:16 pm
Kernel-level sandboxing is now a governance requirement for agentic runtimes. When an AI agent can call tools, spawn processes, and reach the network, application policy alone cannot define trustworthy identity behaviour. The security question becomes which actions the runtime can never perform, even if the prompt is malicious. Practitioners should treat kernel enforcement as part of the identity control stack, not a separate hardening step.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for human identities.
A question worth separating out:
Q: How do security teams know if an AI agent sandbox is actually working?
A: A working sandbox should stop execution, block privilege expansion, and prevent the agent from touching sensitive context even when the model is manipulated. If the agent can still download files, run code, access credentials, or write back into its own queue, the sandbox is only containment in name, not in effect.
👉 Read our full editorial: ClawArmor shifts OpenClaw security to kernel-level sandboxing
