Docker Agent security controls: why a container is not an agent permission model

FuturPulse analysis · 11 October 2026

Docker Agent exposes four safety modes, while a caller can disable an agent’s configured sandbox for one run. That makes container isolation useful, but insufficient as an agent permission model.

What is the difference between containment and permission?

Containment limits where a program runs. Permission decides which consequential actions it may take. A Docker container can narrow filesystem, process and network exposure, but it does not automatically decide whether an agent should read a particular file, send a particular request, or use a particular credential.

That difference matters because an agent is not a fixed web service. It reads untrusted text, chooses tools, changes plans and can delegate work. An agent permission model therefore needs an explicit answer to four questions: which tool may run, with which arguments, against which target, and under which credential.

A tool approval prompt answers only part of that problem. It can ask a person whether to run a command. It does not necessarily constrain the command’s later file reads, network connections or downstream API effects. A sandbox can constrain those effects, but only if its mounts, egress rules and credentials are narrow enough.

What did Docker promise, and what has shipped?

The timeline shows a change from protecting packaged applications to describing the authority an agent needs around its package. That is progress, but the current Docker Agent controls remain split between session approvals, sandbox settings and external runtime policy.

The important distinction is not that Docker lacks controls. It has several. The issue is deciding which controls are advisory defaults, which are interactive workflow choices, and which are enforced below the agent process.

Which Docker Agent controls are permissions?

Docker Agent’s safety modes are chiefly tool-call approval controls. They classify or route proposed calls toward automatic approval, a question to the operator, or denial. This is valuable for reducing accidental actions, especially in attended work where someone can inspect a command before it runs.

But an approval policy should not be mistaken for complete authority control. The schema says safety is a default for new sessions and does not override a user choice. In other words, it is designed to guide a session’s behaviour, not necessarily to impose an administrator’s immutable boundary.

The readonly setting is similarly useful but narrow. Docker Agent filters out tools that lack a read-only annotation. That is a tool catalogue decision. It depends on accurate annotations and does not itself turn every remaining tool effect into a harmless operation.

Secret redaction is another separate control. Docker Agent enables redaction by default and applies it to tool arguments, model-bound messages and tool responses. Redaction can reduce accidental secret exposure in the agent’s context. It does not make a broadly scoped secret safe to hand to a tool in the first place.

Which controls belong below the agent?

Filesystem mounts, network egress and credentials should be treated as external authority, not as instructions for the model to follow. The agent should receive only the working directory it needs, only the network destinations required for the task, and a credential that cannot exceed the task’s intended effect.

Docker’s sandbox documentation describes a default-deny network proxy and says configured or inferred destinations are opened for a run. It also says the working directory, agent configuration directory and staged kit are mounted, while other host files are not visible. Those are containment controls because they govern what code can reach after approval.

The boundary still needs review. A broad working-directory mount can expose source code, build files and local secrets. A broad network allowlist can turn a restricted coding task into a data-exfiltration path. A credential delivered directly to a process can be copied even if the original task did not intend that outcome.

Container-security guidance updated in December 2025 makes the same general point from a conventional workload perspective: image scanning is a baseline, not the complete security program. For agents, the equivalent mistake is treating an isolated image as proof that an autonomous tool user has limited authority.

How should teams secure Docker Agents?

Use two policies, written for different failure modes. The first is a runtime containment policy. The second is an agent permission policy. Do not let either stand in for the other.

1. Make the sandbox hard to bypass

• Run unattended agents in a sandbox by default.
• Restrict who can pass a host-execution override.
• Mount a task directory, not a home directory or repository parent.
• Start with default-deny egress and add named destinations one at a time.

2. Give tools narrow authority

• Expose read-only tools for research and inspection tasks.
• Separate read, write, deploy and account-management toolsets.
• Use credentials scoped to one service and one task outcome.
• Keep destructive APIs out of the agent’s default environment.

3. Treat approval as a workflow, not a wall

• Use strict or balanced operation when a human is present.
• Use restricted operation for unattended work.
• Do not use autonomous mode unless containment and credentials already limit the blast radius.
• Record approvals, denials, network blocks and tool results for later review.

For high-impact tasks, split work across stages. Let one agent inspect and propose a patch. Let a separate, more restricted step test it. Put deployment behind a distinct credential and a separate approval. This prevents a single prompt or compromised tool result from gaining research, code-writing and production authority at once.

Where should each security decision live?

This comparison is the missing operational map. It separates the control plane from the execution boundary, so a team can see where an approval is merely a preference and where a denied action is technically unreachable.

Our framework is deliberately layered. A permission prompt should decide intent. A sandbox should limit reach. A credential should limit effect. Logging should establish what actually happened. Removing any one layer leaves the next layer carrying a job it cannot fully perform.

Why are container controls not enough for agents?

A conventional application usually has a narrow, designed request path. An agent can create a new path while it works. It can search a repository, run a package manager, call an MCP server, invoke a shell and then make an API request based on the output.

The paper submitted on 8 October describes this as a need for continuous assurance across the execution system. That conclusion should be treated as a research proposal, not a settled incident record. Its useful operational lesson is still clear: verify scope while the agent acts, because the agent’s next operation may not resemble the first.

That is why a container is not an agent permission model. Containers answer, “Where can this program execute?” Agent permissions answer, “What authority can this changing sequence of decisions exercise?” Secure deployments need both answers, with separate owners and separate logs.

What we could not verify?

Docker’s public Docker Agent materials do not establish an administrator-only switch that permanently forbids a user from supplying --sandbox=false. Docker could settle that point with a documented policy ceiling or centrally managed enforcement mode.

Public material also does not establish a universal, production-ready policy language for inspecting every shell effect, MCP argument, filesystem action and credential use across all Docker Agent deployments. Docker, runtime operators and tool providers would need to publish the relevant enforcement boundaries and audit semantics.

Finally, the 8 October paper’s descriptions of agent-security incidents are not independent incident reports. The organisations named in those accounts, or primary technical postmortems from them, could settle the detailed causes and scope.

Sources

• Docker Agent configuration schema
• Docker Agent sandbox configuration
• Docker overview documentation
• NIST SP 800-190 publication page
• NIST SP 800-190 PDF
• Docker Sandbox Kit Specification v3 announcement
• From Reactive Containment to Proactive Assurance
• Container Security Best Practices in 2026