Docker published a post this week about securing AI agents, and the most interesting part was not really Docker.

The post makes the now-familiar argument that agents need execution isolation, tool access control, identity and credential management, and runtime monitoring. It also says the quiet part clearly: permission prompts are not enough.

That should be obvious.

It is not obvious enough.

Most of the discussion around coding agents still treats the developer machine as a convenient place where the magic happens. The agent runs in your editor. It sees the repository. It can call tools. It can read logs, run tests, install packages, open browsers, hit APIs, and sometimes push code. If it asks nicely before doing the scary thing, we call that security.

This is backwards.

The developer laptop is becoming the first production environment for agents.

local does not mean low risk

We have a bad habit of treating local development as safer than production because it is smaller.

Production has customer data, uptime guarantees, compliance rules, and dashboards. The laptop has a half-finished branch, a terminal, and a human nearby, so we relax.

But a modern developer machine is a wonderful target.

It has source code, cloud credentials, package manager tokens, SSH keys, browser sessions, local databases full of copied production-shaped data, and access to staging systems that are often less locked down than production. It also has build scripts that can run arbitrary code.

Now put an agent on that machine and give it the same tool surface a senior engineer uses.

That is not a chatbot anymore.

That is an automation actor inside one of the most privileged environments in the company.

permission prompts are a user interface, not a boundary

The obvious answer is to ask the human for permission.

Can I run this command?

Can I edit this file?

Can I access the network?

Can I install this dependency?

Prompts are useful. I like them. They slow things down just enough that I sometimes notice the agent is about to do something silly.

But prompts are not a security model.

They depend on the human understanding the full consequence of an action at the moment the prompt appears. That is a lot to ask when the command is npm install, the dependency graph is 800 packages deep, and the agent presents it as the next obvious step.

The prompt says "run tests."

The test runner executes lifecycle scripts.

The lifecycle script reads an environment variable.

The environment variable contains a token that can deploy to staging.

The human clicked yes because running tests is normal.

This is why runtime containment matters. A useful prompt can ask for intent. A real boundary limits blast radius when intent and consequence drift apart.

agents need less trust than developers

There is an uncomfortable point here: agents should usually have less authority than the developer supervising them.

That sounds inefficient. It is also how every other automation system eventually grows up.

We do not give CI the CEO's laptop because it needs to run tests. We do not give a GitHub Action every cloud permission because one deployment step needs one credential. We do not let a build worker freely write to every repository because it might be convenient someday.

We scope automation because automation is fast, literal, and bad at knowing when the surrounding context has changed.

Coding agents are the same category of problem, just with a more charming interface.

An agent editing a README does not need AWS credentials. An agent refactoring a parser does not need the network by default. An agent generating a migration should not be able to apply it to a shared database unless that is an explicit, isolated workflow. An agent investigating a bug may need redacted logs through a narrow tool, not a shell with access to everything the human can reach.

The useful default is not "this is my assistant, so it inherits my machine."

The useful default is "this is an automation process, so it gets the smallest workspace and tool set that can complete the task."

the old sandbox conversation is back

This is the part I find funny in a tired way.

We spent years building containers, microVMs, CI isolation, network policies, service accounts, secret managers, and audit trails. Then AI coding tools arrived and a lot of demos quietly stepped around those lessons because the local magic was too good to interrupt.

Now we are rediscovering the same architecture.

Run the agent in an isolated workspace. Mount only the files it needs. Give it an explicit network policy. Pass credentials through scoped tools instead of ambient environment variables. Separate read-only inspection from write-capable actions. Keep enough evidence that a human reviewer can reconstruct the path from prompt to diff.

None of this is exotic. It is just platform engineering applied to the developer machine.

Docker talking about agent isolation is interesting because Docker already won the mental model for "this process gets a filesystem, a network shape, and a boundary." MicroVMs push the boundary further. Operating system features will keep moving in the same direction. Microsoft is already talking about agent runtime boundaries at the platform layer.

The direction is clear: agent security is moving below the app and editor.

It has to.

the laptop is where policy gets tested first

The enterprise version of this conversation will eventually become very formal.

There will be agent identities, audit APIs, policy engines, approved tool catalogs, model routing rules, and budget controls. There will be dashboards showing which agent touched which repo under which human supervisor.

Before that, there is a laptop.

That is where the first bad patterns appear:

• agents reading files they did not need
• agents installing packages from the public internet without review
• agents using broad human credentials because scoped credentials are annoying
• agents producing diffs without enough execution evidence
• agents running commands whose side effects nobody inspected
• agents mixing trusted project state with untrusted generated artifacts

Those are not hypothetical enterprise governance problems. They happen during ordinary development when the tool is good enough to keep using and not mature enough to fully trust.

The laptop is where the policy either becomes ergonomic or dies.

If the secure path is too slow, developers will route around it. If the isolated environment cannot run the project, they will turn it off. If credential scoping breaks every useful workflow, the broad token comes back. If the audit trail is unreadable, reviewers will ignore it.

Agent security has to be boring, local, and fast enough that people leave it on.

what i would do now

If I were responsible for rolling coding agents into an engineering team, I would start with local containment before writing a grand AI governance document.

First, separate workspaces. The agent should operate in a copy, branch, container, or sandbox where accidental writes are cheap. The human can review and promote the result.

Second, make network access explicit. Many coding tasks do not need the internet. The ones that do should say why. Package installation should be treated as a supply-chain event, not as background noise.

Third, remove ambient credentials. If the agent needs to call a service, give it a scoped tool or short-lived credential for that task. Do not let it inherit every token the developer happened to have in their shell.

Fourth, preserve evidence. Commands, outputs, files changed, tests run, and external calls should be visible in a reviewable trail. The human reviewer should not have to trust the agent's summary of what happened.

Fifth, make the safe path pleasant. This is the boring product work. If the sandbox takes five minutes to start, nobody will use it. If the policy requires twenty approvals for a typo fix, people will disable it. Security that cannot survive daily development is a memo, not a system.

the punchline

Local coding agents feel personal because they sit in the editor and speak in first person.

Operationally, they are automation systems running inside a privileged environment.

That distinction matters.

The developer laptop has source code, credentials, build tools, staging access, and a human who is busy trying to ship. It is not a toy environment just because it is local. For agents, it is the first production environment, and it deserves production-shaped boundaries.

Permission prompts are useful. They are not enough.

The real product is containment, identity, scoped tools, audit trails, and a workflow developers will actually keep turned on.

Welcome back to software engineering. The agent is new. The security problem is not.

references

• Docker: How to Secure AI Agents
• Docker: Why MicroVMs: The Architecture Behind Docker Sandboxes
• Windows Developer Blog: Windows platform security for AI agents

To test my projects, I use Railway. If you want $20 USD to get started, use this link.