Somewhere in the last two years, "AI agent" stopped meaning a chatbot and started meaning a headless process with your build credentials. The security model for that process, in most shops, is still whatever a tired human notices in a PR at 6pm. Docker took a swing at that gap on 18 August 2026 with a blog post called "17,600 Actions: Agent Security Is a Systems Problem." The argument, in one line: you cannot code-review an actor that fires thousands of actions in a session. So stop trying.
What Docker is actually claiming
The post points at an OpenAI/Hugging Face incident in which an attacker generated 17,600 actions through an agent, and argues that agent security "can't rely on human review." Docker's phrasing for the alternative is that controls have to "constrain, observe, and govern agents at speed." Translation for the pipeline crowd: policy engines, sandboxes, and audit trails have to live inside the same loop as the agent, not after the fact.
Fair, as far as it goes.
Why the human-review model breaks
Think about how you would review 17,600 tool calls. You wouldn't. You would eyeball the first ten, notice they look reasonable, approve the batch, and go to lunch. That is the honest workflow. It works for a forty-line diff and falls apart the instant the actor is faster than you.
Every classic CI safeguard we lean on assumes bounded, discrete events. A pull request has a diff. A push is one commit. A deploy has a version. Agents don't respect that shape. One session can rewrite a workflow file, mint a token, push a container, and open ten PRs before you finish your coffee. The human-in-the-loop is not slow because of the human. It's slow because the batch size moved.
What "systems-level" has to mean in practice
The Docker post is thin on prescriptions, which is the frustrating part of an argument that is otherwise correct. If you want to constrain, observe and govern at agent speed, three unglamorous things have to be in place before you invite the bot to the party:
- A capability boundary the agent physically cannot cross. Not a system prompt, not a "please don't". A sandbox with no network by default, scoped credentials with a stated TTL, filesystem writes pinned to a workspace directory. Guardrails that hold when the model is wrong, or hostile.
-
Machine-speed policy, not human-speed approval. Every action the agent proposes has to pass a policy check that runs in milliseconds. Deny a
sudo, deny a push tomain, deny an outbound to an unallowlisted host, and record the attempt. The reviewer is code. - An audit stream you can actually replay. A structured log of every tool call, prompt fragment and permission decision, with a stable id per session. If you cannot reconstruct what the agent did between 02:14 and 02:19, you don't have security. You have optimism.
The unglamorous version of "agent security" is a policy engine, a sandbox runtime, and an append-only log. It looks a lot like the trust boundary you already have around your build runners. That should not be a surprise.
Where the argument bends
Where the post overreaches is the implicit "abandon human review." Human review is not the fix at 17,600 actions per session, but it is still the fix for the ten that matter: the ones where the agent asks for a new secret, a new external endpoint, or a change to CI configuration itself. A well-designed system escalates those to a human and lets the rest go. The system is not a replacement for review. It is a triage layer that makes review possible.
The verdict
Docker is right that "watch the PR" is no longer a security model for a class of actors that can outpace your attention. Where the post is thin, the answer is unglamorous and already known to anyone who has hardened a CI runner: sandbox the runtime, mediate every action with policy, keep an audit trail you would testify from. Which is the real story here. Your agent is a runner with a better prompt. Treat it as one, and stop expecting the pull request to save you.
Top comments (0)