AI Coding Agent Horror Stories: Security Risks Explained | Docker

Secure, minimal container images for every team, free with enterprise features, if needed.
This is issue 1 of a new series called Coding Agent Horror Stories where we examine critical security failures in the AI coding agent ecosystem and how Docker Sandboxes provide enterprise-grade protection against these threats.
AI coding agents are everywhere. According to Anthropic’s 2026 Agentic Coding Trends Report, developers are now using AI in roughly 60% of their work. The report describes a shift from single agents to coordinated teams of agents, with tasks that took hours or days getting compressed into minutes. Walk into almost any engineering team in 2026 and you’ll find AI coding agents sitting somewhere in the workflow, usually in more than one place.
The productivity story is real, and if you’ve watched an agent ship a feature in an afternoon that would have taken your team a sprint, you already know why. But the same agents that ship features in an afternoon can also delete your home directory in a few seconds. The same loop that lets an agent autonomously refactor a 12-million-line codebase will, given the wrong context, autonomously drop your production database.
Over the past sixteen months, these aren’t hypothetical failure modes, they’re documented incidents with named victims, screenshotted agent outputs, and in several cases, public apologies from the vendors. This issue is the first in a new series mapping how those failures happen and how Docker Sandboxes can contain them.
Unlike a traditional AI assistant that answers your question and waits for the next one, a coding agent reads your files, runs shell commands, writes and deploys code, queries databases, sends emails, and makes a chain of decisions to get a task done, none of which require you to approve each step along the way.
If you’ve worked with any of the current coding agents such as Claude Code, Cursor, Replit Agent, GitHub Copilot Workspace, Amazon Kiro, Google Antigravity, you’ve seen the pattern. They plug straight into your local machine, your cloud accounts, and increasingly your production systems. Adoption has been faster than almost any developer tool in recent memory: by late 2025, the vast majority of working developers were using AI coding tools as part of their daily workflow, and the question on most engineering teams shifted from “should we use this?” to “how do we use this without something going wrong?”
The simplest mental model I’ve found: an AI coding agent is a junior developer with root access, the ability to type at 10,000 words per minute, and no instinct for when to stop and ask. That combination is a lot of capability with no built-in sense of where the boundary is an entire reason this series exists.
Under the hood, every agent in this category runs the same loop: observe, plan, act, repeat.
You give it a task, something like “fix this bug” or “refactor this module” or “clean up these old files,” and the agent goes off and pulls in whatever context it figures it needs. Your files, sure, but also your logs, your environment variables, whatever happens to be accessible from wherever you launched it. Then it reasons through the problem and starts firing off tool calls to actually do the work. Write a file, run a command, hit an API, check the result, decide what’s next, loop. That’s the whole thing.
The part that catches people off guard is that the agent runs as you. Whatever permissions your shell has at the moment you typed the command to launch the agent, the agent inherits them wholesale. Logged in with admin rights? Congratulations, so is the agent. Got AWS credentials sitting in ~/.aws from that thing you set up six months ago and forgot about? The agent can read them. Production database connection string tucked into a .env file the agent scoops up as part of “project context”? It’s already in the model’s working memory before you’ve typed your second prompt. There isn’t a separate identity for “the agent acting on your behalf.” There’s just you, and the agent is, for all practical purposes, operating as you.
And here’s where it gets interesting, in the bad way. Traditional software does exactly what its source code says it does. You read the code, you know what’s going to happen, end of story. An AI coding agent doesn’t work like that. It’s reasoning its way through the task in real time, and its reasoning can produce decisions you didn’t expect and definitely wouldn’t have signed off on if anyone had bothered to ask. Maybe it decides that the cleanest way to resolve a schema conflict is to drop and recreate the table. Maybe it decides that wiping a directory is faster than going through and pruning the files you actually wanted to keep. Maybe it decides that a half-finished test file is better to be committed than sitting there in a dirty working tree. These calls happen in milliseconds. There’s no confirmation prompt, no approval step, no chance for you to say “wait, what?” before the action has already happened. By the time you notice, the thing is done.
That’s the gap this series is about. The model makes a decision. The execution layer carries it out. Nothing sits in between.
Caption: Comic depicting AI coding agent enthusiasm and the small matter of unrestricted filesystem access
The scale of security failures with AI coding agents is not speculation. It is backed by documented incidents, CVE disclosures, and empirical research spanning late 2024 through early 2026.
As of February 2026, at least ten documented incidents across six major AI coding tools including Amazon Kiro, Replit AI Agent, Google Antigravity IDE, Claude Code, Claude Cowork, and Cursor have been publicly attributed to agents acting with insufficient boundaries, spanning a 16-month window from October 2024 to February 2026.
The failures cluster around six critical risk categories:
What it is: AI coding agents run with the full filesystem permissions of the operating user. Without an explicit workspace boundary,