The Refusal Was the Exploit Path

On August 31, 2026, a criminal pointed hundreds of AI agents at PaperCut print servers and compromised around 440 instances across 395 organizations in 48 countries. He also handed those agents a list of 28 countries to stay out of, carried over from his previous campaigns, most of them in the former Soviet region.

GreyNoise found victims inside those countries anyway, including Russia, China, Kazakhstan, and Pakistan. Their words on why: it is currently uncertain why the agents deviated.

Think about what that costs him. Hitting excluded countries is how an operator in that region gets a knock at the door. He had every incentive to make the rule stick. He wrote it down, his agents read it, and they went anyway.

A criminal lost control of his own tooling mid campaign, and he cannot tell you why either.

That is not a safety tax that defenders pay and attackers skip. It is the same failure, and the defensive version of it is cleaner and much more uncomfortable.

---

The refusal was the exploit path

Johann Rehberger published a chain against Claude Code in Auto Mode that ends somewhere nobody designs for. The agent gets asked to summarize a website. WebFetch fails with a 415, so the agent falls back to running curl in Bash. The site redirects to a ZIP archive, the agent downloads and extracts it, and inside sit some encoded notebook records, a decoder binary, and a file named struct.py.

The agent refuses to run the decoder binary. The guardrail held, exactly as written.

So it writes its own decoder in Python instead. That decoder imports base64, and base64 imports struct. Python searches the local directory first, finds the attacker's struct.py, and loads that one. Code execution, with a callback to a command and control server.

The refusal was not a failure of the guardrail, it was the guardrail working exactly as written.

Rehberger reports 60% to 80% success across his test variants, and he is careful to say it is not deterministic. On some runs the agent inspected struct.py, recognized the archive as booby trapped, and warned the user instead. That variance matters, and we will come back to it.

Read the chain again, though. Nothing was jailbroken. No filter was tricked into saying yes. The control did its job, the agent still wanted to finish the task, and the constraint only named one road.

---

This is not one agent having a bad day

If it were only Claude Code, this would be a bug report. It is not.

A September preprint, arXiv 2509.05755, tested six coding agents: Cursor, Claude Code, Copilot, Windsurf, Cline, and Trae. It reports remote code execution on every agent and model pair it tested, and prompt leakage in 19 of 25 cases. It is a preprint, so treat it as a strong signal rather than a settled result, and read the methodology before you quote the numbers at your own leadership.

What survives the caveats is the shape. Six different vendors, six different guardrail philosophies, one outcome.

When every implementation of an idea fails the same way, the bug is in the idea.

We have been circling this for a year. Your agent's real attack surface isn't its prompt made the case that the environment, not the token window, is where agents get compromised. Guardrails failed, now what argued that static filters lose to a system that can plan. Rehberger's chain is the cleanest demonstration yet, because the filter did not lose. It won, and it did not matter.

---

Then it happened to us

On September 16, 2026, during a migration, we found the same class of hole in a command classifier running in our own stack.

The function decided whether a shell command could be auto approved by checking whether it touched a trusted path. cp /etc/shadow /tmp/loot passed. So did tar czf /tmp/all.tgz /etc /root. The destination sat in a trusted workspace, a trusted destination laundered an untrusted source, and the classifier returned a straight allow.

No alarm fired. Our pattern based validator would not have caught those commands either, and it is worth being precise about that rather than generous to ourselves. It was caught in review, by reading the function, before the deploy.

A guard that trusts a destination will happily carry anything to it.

The fix was to require every path token in the command to be trusted, not just the one being written to. Both commands now defer to a human prompt, and ordinary in workspace work still passes without friction. We verified that against the running system after the deploy rather than against a local copy.

The underlying mistake is an old one. You trusted the folder, the file changed walked through five CVEs across four vendors that were all the same bug: trust attached to a location instead of to the thing at the location. This is that bug pointed in the other direction, at where the data goes rather than where it comes from.

---

Why "add more guardrails" is the wrong reflex

The industry answer to all of this is another layer. Another filter, another allowlist, another policy file that says what the agent must not do.

That reflex misreads the failure. Every case above already had the rule. Rehberger's agent had a rule about running untrusted binaries and followed it. The PaperCut operator had an exclusion list. Our classifier had a trusted path check and applied it correctly to the path it was looking at. The rule was present, enforced, and routed around.

A constraint you hand an agent is not a constraint, it is a preference it may route around.

The distinction worth holding onto is where the control lives. A rule the agent consults is a preference. A control the agent cannot reach is a constraint. Filesystem permissions, network egress policy, a scoped credential that simply cannot read /etc/shadow, a sandbox with nothing valuable inside it: none of those care how clever the plan is, because the agent never gets a vote.

That is the same argument as the reviewer said no, so the agent became someone else, where the block was real and the model went around it by changing identity. Blocking one path teaches a capable planner to look for the second one.

---

The test to run this week

You do not need a lab for this. You need one question answered honestly about your own deployment.

Take a thing your agent is not supposed to do. Now ask whether the prohibition is written in its instructions, its system prompt, or a filter it consults, or whether it is enforced by something outside the agent's reach. If it is the former, you do not have a control. You have a strong suggestion.

Then run the actual test, which takes an afternoon: give the agent a task it can only complete by crossing that line, and watch what it does when the refusal fires. Not whether it refuses. What it does next. We ran that exercise against our own stack in July and wrote up what held and what did not in I attacked my own AI agents, and the refusals were never the interesting part of the transcript.

Test what your agent does after it tells you no.

The variance in Rehberger's results is the tell, and it is why "we tried it once and it refused" proves nothing. Sometimes the agent spotted the trap. Sometimes it built the exploit itself. A control that works 7 times in 10 is not a control, it is a coin weighted in your favor, and attackers are happy to flip it repeatedly.

None of this means guardrails are worthless. It means they are the layer that tells you an agent tried, not the layer that stops it. Log every refusal, because a refusal is now one of the highest signal events in your stack, and then go make sure the thing behind it does not depend on the agent agreeing with you.