Notifications
Clear all
Topic starter
02/08/2026 12:01 pm
TL;DR: OpenClaw’s own hardening guidance and the security research around it show that exposed instances, malicious skills, and prompt injection remain practical attack paths for AI agents running with broad user-level access, according to Aikido. The core problem is that agents must process untrusted content to be useful, so the attack surface is intrinsic rather than an edge case.
NHIMG editorial — based on content published by Aikido: Why Trying to Secure OpenClaw is Ridiculous
By the numbers:
- Early versions were bound to port 0.0.0.0:18789 by default, so tens of thousands of instances on cloud servers were exposed to the entire internet.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when AI agents can call tools after reading untrusted content?
A: The system stops being a text processor and becomes an execution surface.
Q: Why do NHIs complicate zero trust and least privilege efforts?
A: NHIs complicate zero trust because they are numerous, persistent, and often tightly integrated into applications and pipelines.
Q: What do security teams get wrong about prompt injection defence?
A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload.
Practitioner guidance
- Classify every agent as a governed identity Assign an owner, purpose, permitted tools, and a revocation path for each AI agent.
- Remove public exposure from agent control planes Bind agent services to localhost or private networks, disable open interfaces by default, and force authentication for every connection.
- Constrain tool use to pre-approved actions Disable shell execution, unrestricted web fetching, and browser control unless a workflow explicitly requires them.
What's in the full article
Aikido's full blog post covers the operational detail this post intentionally leaves for the source:
- Concrete hardening steps for running OpenClaw on localhost, in Docker, and with restricted network exposure
- The specific unsafe features the article says should be disabled, including shell execution, browser control, and web fetching
- The security trade-off analysis behind sandboxing, where tighter controls reduce risk but also reduce the assistant’s usefulness
- The article’s discussion of marketplace risks, including malicious skills and the limits of scanning alone
👉 Read Aikido's analysis of why OpenClaw is hard to secure →
OpenClaw and prompt injection: are your controls keeping up?
Explore further
02/08/2026 1:07 pm
OpenClaw exposes the core governance flaw in agentic AI: delegated runtime access is being treated like a feature, when it is really a control boundary. The article shows that utility depends on the agent seeing content, using tools, and making decisions in the same session. That means identity, authorisation, and content trust cannot be separated cleanly. For practitioners, the implication is that agent governance must start with runtime permission design, not model prompts.
A question worth separating out:
Q: How should organisations govern AI agents that need database access?
A: Organisations should give AI agents narrow read access by default, separate write privileges from query privileges, and require human approval for any session that can modify data. That keeps agent activity inside a clearly bounded role while preserving auditability and reducing the chance of unsupervised state change.
👉 Read our full editorial: OpenClaw shows why agentic AI security collapses at runtime
