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.
What the sandbox actually covered
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.
The pipeline read
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.
Top comments (1)
"Every file the agent reads is part of the attack surface" is the line that reframes the whole risk, because most of us picture the threat as the user's prompt and forget the input that arrives sideways — the README, the dependency, the comment. I hit the low-budget version of this recently: I have tools that feed a model external text it didn't author (fetched articles, uploaded docs), and the model genuinely can't tell my instructions from instructions hidden in the thing it fetched. Same attack surface, one tier down from a build pipeline.
The reframe I'd underline is "an agent invocation behaves closer to a build runner reaching your production plane than to a chat window." That's the mental-model correction that actually changes behavior — a chat window feels contained, so you reason about it loosely; a build runner with production reach gets least-privilege, audit, and a kill switch by reflex. The danger is that agents feel like the first and act like the second, so the instinct people bring is calibrated to entirely the wrong picture.
"The agent's access must be more restrictive than the developer invoking it" is the concrete version, and the one most setups get backwards — the agent usually inherits the human's full credentials because that was easiest, which means an injection through a trusted file borrows the developer's entire blast radius. Trusted-file injection is nasty precisely because the trust was granted for a different reason than the one being exploited. Sobering summary — the supply-chain framing is the part that should keep people up.