A developer running autonomous OpenClaw agents around the clock audited their own deployment’s security configuration and scored 26 out of 100. The audit, published on Dev.to by ClawGear, identified five critical misconfigurations that collectively turned an autonomous agent system into what ClawGear described as “a publicly accessible command interface.”
The findings are specific and reproducible. They apply to any self-hosted OpenClaw deployment running with default or hastily configured settings.
The Five Findings
The first vulnerability involved API keys stored in costs.json instead of the intended agent-accounts.json credential store. The file has no special protections and regularly gets read during debugging, committed to repositories, or pasted into logs. ClawGear noted that the agent-accounts.json file exists specifically to centralize credentials, but nothing prevents keys from landing in other configuration files where they become leak vectors.
The second, and most severe, finding: exec.ask was set to off. With that configuration, any command the agent’s exec tool receives runs immediately with no confirmation and no review. A prompt injection attack embedded in an email, web page, or API response processed by the agent could execute arbitrary shell commands on the host. As earezki.com summarized, “setting exec.ask to ‘off’ allows prompt injection attacks to run arbitrary shell commands like ‘rm -rf’ without human intervention.”
The third finding flagged elevated tools accessible from group chats. Tools marked elevated: true, including host-level operations and file system access, inherited default access levels and were reachable from any Telegram group where the agent was a member. Group chats have a fundamentally different threat model than private DMs: unknown members, forwarded messages, and redirected commands all expand the attack surface.
Fourth, one Telegram group had groupPolicy: open, meaning any member could task the agent without an allowlist or mention requirement. ClawGear wrote that open policy turns a private assistant into “a publicly accessible command interface.”
The fifth finding involved third-party skills containing obfuscated code patterns, including eval() and base64 blobs, that could exfiltrate credentials or execute hidden commands. The OpenClaw skill marketplace allows community-contributed tools, and earezki.com noted that without review, these become a supply chain risk.
The Fix Checklist
Each vulnerability has a corresponding one-line configuration change. Setting exec.ask to on-miss requires confirmation for commands not in an allowlist. Restricting elevated tool channels to ["webchat", "telegram:dm"] removes group chat exposure. Switching group policy to allowlist limits who can command the agent. Moving API keys to agent-accounts.json centralizes credential management.
The audit used ClawArmor, a security scanning tool for OpenClaw deployments. The tool flagged each misconfiguration with severity levels ranging from MEDIUM (open group policy) to CRITICAL (raw API keys in non-credential files).
Deployment Defaults and Builder Responsibility
The 26/100 score came from a developer who built and ran an autonomous agent company — someone doing serious production work. The findings highlight a gap between OpenClaw’s flexibility as a self-hosted platform and the security posture that autonomous agents running 24/7 actually require.
OpenClaw’s architecture gives operators full control over sandboxing, credential management, and tool gating. That same flexibility means the default configuration path of least resistance leaves multiple attack surfaces open. Operators who deploy agents that process untrusted external content, which is most agents handling email, web pages, or API calls, inherit the full burden of hardening.
The audit adds to a growing body of evidence that agent deployment security is lagging behind agent capability. For builders running OpenClaw in production, ClawGear’s five-item checklist is a minimum starting point.