A common reaction to agent sandboxing is:
Why do we need another security layer? We already run the agent in Docker.
It is a fair question.
Docker provides valuable isolation primitives. NVIDIA OpenShell also uses container and workload runtimes.
The two technologies are better understood as solving different layers of the same problem.
Docker primarily gives you a workload isolation environment.
OpenShell adds an agent-specific security and policy layer around that workload.
What Docker already does well
Docker relies on Linux isolation primitives including namespaces and control groups. Its security model also uses capabilities and seccomp.
Docker's default seccomp profile blocks a number of system calls while allowing common application behavior.
That gives containers an important boundary from the host, other containers, and privileged kernel operations.
For ordinary applications, that is foundational.
For autonomous agents, it is necessary—but often not sufficient.
The agent adds a new question
Suppose Claude Code runs inside Docker.
That tells us where its process executes.
It does not automatically answer:
- Which websites may it reach?
- Can it access GitHub but not another SaaS service?
- Can it call only certain API operations?
- Which model provider may it use?
- Can it see the real API credential?
- Can it invoke every MCP tool?
- Can policy be centrally managed across hundreds of sandboxes?
- Which policy revision was active during an incident?
Those are agent-platform concerns.
A simple comparison
Docker
Think:
Where does this process run,
and how is it isolated from the host?
OpenShell
Think:
What is this autonomous workload
allowed to access and do while it runs?
OpenShell does not remove the need for Docker or Kubernetes. It runs on top of infrastructure runtimes and integrates with them.
Process isolation
Docker provides process isolation using namespaces and container runtime controls. It can also drop Linux capabilities and apply seccomp profiles.
OpenShell adds agent-oriented process policy and launches the agent as a restricted child process within its sandbox architecture.
The underlying runtime creates the workload boundary. OpenShell defines and manages how the agent operates inside that boundary.
Filesystem control
A Docker container gives the process its own filesystem view and whatever volumes are mounted.
Security still depends on how those mounts are configured.
OpenShell adds declarative filesystem policy. Its default policy includes a defined working directory and baseline runtime paths while restricting undeclared access.
That moves the question from:
What did somebody happen to mount?
Toward:
What filesystem capability does this agent's policy intentionally grant?
Network egress
Docker gives each container a network stack. You can implement firewall rules, network namespaces, Kubernetes NetworkPolicy, proxies, and other controls.
OpenShell adds agent-oriented network policy. Its restrictive default denies outbound access unless policy grants it.
Policies can then describe allowed destinations and, for supported protocols, richer request-level constraints.
This is one of the biggest differences.
Credentials
Docker can inject secrets or environment variables into a container. Once a secret is inside the process environment, the process may be able to read it.
OpenShell's provider model supports a different pattern.
The sandbox receives placeholder values, while the trusted proxy resolves actual credentials only for approved endpoints.
That is not container isolation. That is agent credential mediation.
Control plane
Docker itself does not provide an enterprise agent-security control plane.
OpenShell's Gateway owns concepts such as sandboxes, policies, providers, provider profiles, authorization, workspaces, inference configuration, and lifecycle state.
This becomes important when an organization moves from:
one developer
one container
one agent
To:
hundreds of agents
multiple teams
multiple policies
multiple model providers
multiple environments
Policy semantics
A container configuration says things such as:
mount this volume
drop these capabilities
use this network
run as this user
An agent policy may need to say:
This coding agent:
- may write /workspace
- may call GitHub
- may use this GitHub provider
- may reach this model endpoint
- may not reach the rest of the internet
OpenShell packages those agent-specific semantics into one policy model.
Observability
You can build logging around Docker and Kubernetes.
But you still have to establish higher-level context: which agent, which policy, which provider, which denied request, which sandbox, and which workspace.
OpenShell emits sandbox security/lifecycle logs and supports OCSF JSON export for security tooling.
Again, the difference is context.
When Docker alone may be enough
Docker may be sufficient when the agent is low risk, ephemeral, has no credentials, has no sensitive data, has no production access, and outbound networking is already tightly controlled.
The goal should not be adding technology for its own sake.
When an agent-specific layer becomes attractive
OpenShell becomes more compelling when coding agents need enterprise access, the organization has multiple agents, credentials need mediation, teams need reusable policy, inference endpoints differ by workload, security wants default-deny egress, MCP/tool use needs governance, or agent activity needs central auditability.
At that point, building every control independently can become expensive.
Use both layers
The stronger enterprise pattern is not:
Docker OR OpenShell
It is:
Infrastructure isolation
+
Agent policy
For example:
Kubernetes
|
v
OpenShell Sandbox
+-- process restrictions
+-- filesystem policy
+-- network policy
+-- provider credentials
`-- agent
Then underneath: CNI, cloud IAM, secret stores, node security, and SIEM.
Each layer has a job.
The bigger lesson
Agent security should not be reduced to a single sandbox primitive.
You need workload isolation, agent authorization, credential controls, network controls, tool controls, downstream IAM, and audit.
Docker is foundational infrastructure. OpenShell is an emerging agent-security layer that can sit on top of that infrastructure.
How Anpu Labs designs the stack
During our Secure Agent Infrastructure Assessment, we evaluate the controls the customer already has.
If Kubernetes, container security, workload identity, network policy, and secret management already solve parts of the problem, we keep them.
We then determine where an agent-specific policy layer adds value.
The target architecture should reuse strong enterprise controls—not rebuild everything in OpenShell.
References
- Docker Engine Security: https://docs.docker.com/engine/security/
- Docker Seccomp Profiles: https://docs.docker.com/engine/security/seccomp/
- NVIDIA OpenShell — How OpenShell Works: https://docs.nvidia.com/openshell/about/how-it-works
- NVIDIA OpenShell — Default Policy: https://docs.nvidia.com/openshell/latest/how-it-works/policies/default-policy
