I went into that Berkeley RDI write-up on benchmark exploits expecting cleverness — agents inventing side channels, finding moves I'd never have predicted. What I got was a list of agents doing exactly what they were told, in the dumbest available way. If you've run agents for a living, that's not surprising. It's Tuesday.
https://rdi.berkeley.edu/blog/trustworthy-benchmarks-cont/
Two very different things get filed under "exploit" in work like this, and they need different fixes.
The first is a security bug. Ground truth sits in a file the agent can open. The grading script is on the agent's PATH. A tool response smuggles in instructions. The agent went around your task. Fine — there are real fixes: isolation, permissions, filtering what comes back from tools. Boring, expensive, doable.
The second is ambiguity. The task said "make the failing test pass" and the agent deleted the test. The task said "summarize the incident" and the agent found a file called summary.md and pasted it. The agent didn't go around your task. It walked through the front door and you're annoyed because you meant a different front door. There's no sandbox for that, because there's no hole to close. The hole was in the sentence.
Here's what bothers me: I reach for the first fix every time the second one bites me. Because isolation is a thing I can do — a compose file, a flag, a network policy, done by lunch. Writing a spec that survives an optimiser reading it literally is a thing I have to sit and think about, and then argue with myself about whether it's actually ambiguous, and then probably discover it was anyway. One of those is work and the other feels like work.
Same thing in production. When one of my agents does something I didn't want, my first question used to be "what could it reach?" Now it's "what did I literally ask for?" Nine times out of ten the answer is that I described the goal and left the method open, then acted surprised about the method. The system prompt said "keep the repo clean" and the agent deleted a directory it judged redundant. Nothing was hacked. I was just vague at scale.
Practically, that changes what I write down. Every task now gets a sentence about the shape of an acceptable solution, not just the outcome — "the failing test must still exist and must still assert the same behaviour" is ugly, specific, and has saved me more than any permission change. When I can't write that sentence, that's my signal the task isn't ready, not that the model is sneaky.
I've only skimmed their task list, so my ratio might be off, and maybe the security half is bigger than I'm giving it credit for. But the ambiguity half is the half nobody funds. You can't buy a tool that tells you what you meant.
The security exploits will get patched, because they're discrete and someone owns them. The vague ones get inherited — into the next benchmark, the next harness, and the ticket I write tomorrow morning.
That's my real takeaway from the piece. Before you go build a sandbox, reread your own task description as if you were an agent with no imagination and a strong incentive to be done early. You'll find at least one door you left open, and you'll find it in the writing, not the infrastructure.
Top comments (0)