AI coding agents have crossed an awkward line. They are no longer just autocomplete with a chat box. In many teams they can read a repository, edit files, run commands, install dependencies, call APIs, write tests, open pull requests and, if wired badly, reach secrets or production-like systems.
Docker’s new post on AI coding-agent security is explicitly written to make the case for Docker Sandboxes. Read it with that filter on. But the useful part is not the product pitch; it is the checklist of failure modes that should now be part of how agencies think about AI-assisted delivery.
The old safety model was mostly social. Tell the model what not to do. Ask it to explain itself. Review the diff. Keep a human in the loop. That is still useful, but it is not enough if the agent is executing in the same local environment as the developer, with access to the same filesystem, shell, credentials and network.
For a Laravel team, the obvious risk is not that an agent writes an ugly controller. That is visible in review. The higher-risk path is infrastructure adjacency: an agent discovers .env, reads local credentials, rewrites migration state, talks to a real database, installs an unsafe package, or runs a destructive command outside the intended project directory.
Docker’s framing is that these failures fall into repeatable categories: unrestricted filesystem access, inherited credentials, prompt injection, malicious extensions or “skills”, and autonomous action without a hard approval boundary. Its answer is to move agent execution into isolated microVM-backed sandboxes with workspace scoping, blocked credential paths, network policies, audit logs, secret injection and disposable Git worktrees.
The architectural point matters even if you never use Docker’s specific product. A coding agent should not inherit your laptop by default. It should get a deliberately small workspace. It should not see ~/.ssh, ~/.aws, ~/.docker, .netrc, package-manager tokens or production credentials unless there is a narrow, auditable reason. It should not be able to call arbitrary hosts from a task that only needs GitHub and a model API. If it proposes a destructive database operation, the approval gate should live outside the prompt.
That last distinction is the one worth taking into stand-up. “Do not touch production” is an instruction. “This execution environment has no route to production and no production credentials” is a control. AI agents make that distinction more important because they are specifically designed to keep working around obstacles.
There is also a workflow lesson here. Agencies adopting agentic tooling should treat it less like installing a new IDE plugin and more like introducing a junior engineer with shell access at machine speed. Give it a branch. Give it a test database. Give it a throwaway filesystem. Give it package and network constraints. Review the output before merge. Do not give it the keys to the client estate just because it is running locally.
The practical baseline is not complicated. Run agents in containers, VMs or sandboxed worktrees. Keep real secrets out of the agent context. Use separate development credentials. Block production egress by default. Require human approval for migrations, deletes, deploys, outbound customer messaging and billing-related operations. Log what tools the agent ran. Make it easy to throw the whole environment away.
This is where agent adoption becomes less glamorous and more real. The successful teams will not be the ones with the boldest prompts. They will be the ones that can define which repositories, commands, networks and credentials an agent may touch for each class of work, then make the safe path the default. That means policies, but it also means tooling: disposable worktrees, per-task credentials, network allow-lists, CI gates and review rules that do not rely on everyone remembering the latest internal memo.
The pattern also needs to be legible to clients. If an agency is going to use coding agents on paid work, it should be able to explain the boundary in plain English: the agent works on a branch, inside a disposable environment, without production credentials, and its output is reviewed by a human before it ships. That is a stronger story than “we use AI but carefully”, and it turns an anxious procurement conversation into a concrete delivery-control conversation.
There is a second-order benefit. Once agents are sandboxed properly, developers can be more ambitious with them. A safe environment makes it easier to let an agent run tests, attempt a refactor, inspect a failing build or explore a migration path without hovering over every command. The goal is not to slow agents down with bureaucracy. It is to move the risky parts out of the prompt and into the infrastructure, so speed and safety are not fighting each other every time someone opens a terminal.
The future of AI-assisted development will not be decided only by which model writes the best patch. It will also be decided by which teams can let agents move quickly without giving them an unbounded blast radius. Docker’s post is a sales-led reminder, but the underlying advice is sound: prompts are not permissions, and trust is not an isolation strategy.