cd /news/ai-safety/pillar-research-says-the-ai-coding-a… · home topics ai-safety article
[ARTICLE · art-69438] src=dev.to ↗ pub= topic=ai-safety verified=true sentiment=↓ negative

Pillar research says the AI coding agent sandbox leaks through trusted files

Pillar Security's research demonstrates that AI coding agents can be manipulated to bypass their sandbox through trusted files and tools, posing a security risk in CI/CD pipelines. The researchers showed sandbox-bypass techniques and prompt-injection attacks embedded in READMEs, code comments, and dependencies. OpenAI, Google, and Cursor have patched several reported flaws.

read2 min views1 publishedJul 23, 2026

Pillar Security's latest research says AI coding agents can be pushed to act outside their sandbox through files and tools they were told to trust, and the operational read for anyone wiring one of these into CI/CD is straightforward: an agent invocation now behaves closer to a build runner reaching your production plane than to a chat window. DevOps.com's Jeff Burt covered the work on July 22.

The researchers demonstrated multiple sandbox-bypass techniques and a parallel class of prompt-injection attacks embedded in READMEs, code comments and dependencies, per the DevOps.com writeup. OpenAI, Google and Cursor have patched several of the reported flaws. Pillar's argument, as summarised there, is that the injection surface reaches every file the agent trusts on the way to the model's prompt, and every tool it can call on the way back.

None of this is entirely new to anyone who has already read Cyberhaven Lab's May note that adoption of AI coding agents is outpacing the security tools built to protect them. What Pillar adds is a concrete demonstration of the gap. A coding agent asked to do a legitimate job can be steered to take actions outside its supposed security boundary through content that arrives on paths the sandbox was not asked to police. Those are the same paths your CI already fetches for you: dependency manifests, README files, the code comments the model reads as context.

That surface has been named before. HalluSquatting and GhostApproval, both referenced in the DevOps.com piece, already gave teams a taxonomy for how AI-adjacent supply-chain attacks reach developers and their tools. Pillar's research is the sandbox counterpart. Same theme, one layer deeper into the runtime.

Two things fall out for anyone who owns a runner fleet. First, the agent's identity, network scope and filesystem access have to be tighter than the developer who invoked it, not looser. Second, a patched-vendor list is not a coverage statement. The writeup names fixes at OpenAI, Google and Cursor. It does not name a coverage floor, and until one exists, the working assumption for a team wiring an agent into a build is that every file the agent reads is part of the attack surface.

── more in #ai-safety 4 stories · sorted by recency
── more on @pillar security 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/pillar-research-says…] indexed:0 read:2min 2026-07-23 ·