OpenShell: Out-of-Process Enforcement for Secure LLM Agents

OpenShell enables secure agent runtimes through out-of-process enforcement

OpenShell is the security and runtime layer that enables the deployment of LLM agents within a trust boundary. Unlike traditional agent safety methods that rely on system prompts, OpenShell uses a "supervisor" to enforce policies from outside the agent process, ensuring that security constraints remain intact even if the agent is compromised via prompt injection or jailbreaking.

The NemoClaw Blueprint Pattern

NemoClaw is an open blueprint for building specialized agents. A complete NemoClaw blueprint consists of three interchangeable components:

1. The Harness: The agent loop responsible for planning and tool calling (e.g., OpenClaw, Hermes, or LangChain DeepAgents).
2. The Model: The reasoning engine, typically an NVIDIA Nemotron model.
3. The Runtime: OpenShell, which handles sandboxing, policy enforcement, and network isolation.

While the harness and model can be swapped based on the use case, OpenShell serves as the constant runtime that ensures the agent operates within defined security parameters.

LangChain DeepAgents as a Harness

LangChain's Deep Agent framework is a model-agnostic harness designed for long-horizon tasks. It implements production-ready agent patterns, including:

• Planning Loops: Structured processes for tracking work via to-do lists.
• Sub-agents: The ability for a main agent to spawn specialized agents for sub-tasks.
• Integrated File Systems: Capabilities for reading and writing files to manage state and data.

When paired with OpenShell, these capabilities are restricted to a trust boundary, preventing the agent from accessing the host machine's sensitive data.

Out-of-Process Enforcement vs. Prompt-Based Safety

Traditional agent safety relies on system prompts (e.g., "You must not do X"). Because LLMs are conditional probability machines, they can be manipulated to ignore these rules through prompt injection.

OpenShell replaces this with out-of-process enforcement. The supervisor component starts before the agent and launches the agent as a restricted child process. The supervisor evaluates every action—network connections, file writes, or inference calls—against a policy before the action is executed. Because the enforcement happens outside the agent's process, the agent cannot bypass these rules, regardless of its internal state or instructions.

The Four Pillars of Supervisor Control

The OpenShell supervisor controls the following attack surfaces:

1. Network Isolation

OpenShell employs a "default deny" posture. No traffic can leave the sandbox unless the destination is explicitly added to an allowlist (e.g., a specific search API or inference endpoint). This provides a verifiable guarantee for compliance teams that data cannot be exfiltrated to unauthorized external servers.

2. File System Sandboxing

Agents operate within a dedicated workspace. Host directories are not mounted in the sandbox, meaning the agent cannot access the host's home directory, SSH keys, or environment files.

3. Managed Inference Calls

All model calls are routed through a managed internal endpoint (inference.local). The supervisor determines the actual routing destination, ensuring that provider credentials for external LLM APIs are never exposed to the agent.

4. Credential Management

API keys are not stored on disk within the sandbox. They are injected at runtime by the gateway through the supervisor only along the configured policy paths. If an agent is compromised, there are no persistent secrets on disk to steal.

Implementing OpenShell Policies

Policies in OpenShell are defined as YAML files, allowing them to be treated as code (versioned in repositories and reviewed via pull requests).

• Network and Inference Policies: These can be hot-reloaded without restarting the sandbox.
• File System Policies: These are locked when the sandbox starts and require a sandbox recreation to change.

To deploy a policy to a sandbox, the openshell policy set command is used, linking the sandbox name to the specific YAML policy file.