The Agent Security Split: Tool Layer vs Sandbox Layer

When an enterprise asks, "Is your agent platform secure?", the question is almost always a bundle of two distinct architectural concerns:

1. Tool layer: Can the agent only call the tools we approved? Are the tool inputs and outputs validated? Are credentials kept out of the LLM's context? Are calls audited?
2. Sandbox layer: When a tool runs code, browses the web, or shells out — is that execution isolated from the host? Can it reach internal networks? Can it write outside its working directory?

These look adjacent, but they fail differently. A tool layer fails when an agent calls something it shouldn't have access to — fixable by tightening the tool registry. A sandbox layer fails when an approved tool gets compromised mid-execution (e.g., a Chromium zero-day exploited via a malicious page) — fixable only by reducing what the execution environment can reach.

In building helmdeck — an open-source MCP server and pack-based agent infrastructure — our thesis has been that the immediate bottleneck for production-grade agents is the tool layer. We shipped schema-validated Capability Packs, an MCP server that exposes them uniformly, and a vault that injects credentials into outbound HTTP without the agent ever seeing them. 

But for true enterprise hardening, the tool layer isn't enough. You need a sandbox layer that provides hardware isolation. This is why we designed a composed architecture using NVIDIA OpenShell to handle the execution environment.

The Credential Split

The most common concern when composing two security layers is a tug-of-war over credentials. If both the agent platform and the sandbox engine handle secrets, who owns what?

After mapping the integration between helmdeck and OpenShell, the responsibilities proved entirely non-overlapping:

The sandbox layer injects into the process environment. The tool layer injects into the outbound HTTP request body. The layers never collide because they intercept at different points in the request lifecycle. 

What Changes When You Compose Them

Today, agents call helmdeck's 39 packs via MCP. The packs run in Docker containers with seccomp profiles and dropped capabilities. An egress guard rejects outbound URLs against a blocklist. That is solid for most operators.

The composed architecture changes one specific thing: helmdeck's SessionRuntime interface — the seam between the pack engine and execution backends — gains a third backend. Instead of shelling out to the Docker SDK, the pack engine calls OpenShell's Gateway API, which provisions the sidecar in a MicroVM with a pack-family-specific OPA policy attached. 

The pack code doesn't change. The MCP surface doesn't change. The agent doesn't know. But the enterprise reviewing the architecture notices three things:

• Dedicated kernel isolation: A browser sidecar runs in a dedicated kernel. A zero-day exploit cannot escape to the host because the libkrun MicroVM boundary is a hardware-virtualization line, not a namespace.
• L7 policy per pack family: A python.run sidecar can be policy-restricted to deny any outbound HTTP — even to internal services — while a browser.screenshot_url sidecar can be allowed to reach exactly the user-supplied target.
• Landlock filesystem enforcement: Even if the LLM generates code attempting to read /etc/passwd, the kernel returns EACCES before the process can act.

Why This Matters to You

If you are designing an agentic platform for enterprise deployment, do not attempt to merge the tool layer and the sandbox layer into a single monolithic API. The abstractions will leak. 

A two-stack story is more honest about what each layer does. An enterprise reviewing a composed architecture can audit each layer independently: they can read the sandbox's policy YAML to verify network isolation, and read the tool layer's pack schemas to verify credential injection. That decoupling is a security property of the architecture, not just an aesthetic preference.

If you are an architect reviewing agent infrastructure for production, we are actively prioritizing the next phases of this integration based on community needs. We need to know which pack family worries you most (browser, Python, vision) and what you are isolating against (Chromium zero-days, internal SSRF). You can shape the roadmap by commenting on issue #193, or help us build the deterministic tool layer by contributing SaaS API wrappers following our contribution guide.

Note: NVIDIA OpenShell is currently in alpha. The composed architecture described here is our post-v1.0 roadmap for enterprise hardening, ensuring the base tool layer is stable before binding it to an alpha contract.