The OpenShell Sandbox

Where each defense layer intervenes

Suppose untrusted content tells an agent to read a credential and send it away. Three different layers get a chance to stop that action, and each layer answers a different question.

• The prompt shapes intent. A rule such as "do not reveal credentials" tells the model how it should behave. Models can still be deceived by Adversarial retrieved content, malicious tool output, or another agent in the loop. This layer influences the decision. The agent retains whatever authority the runtime granted it.
• The agent harness validates the request. OpenClaw or Hermes can reject an unsupported shell form, a forbidden tool call, or a malformed argument before the request reaches the operating system. That deterministic check is useful, but it remains application logic that can be misconfigured, outdated, or compromised.
• The sandbox limits the result. OpenShell gives the process only the authority allowed by policy. If the prompt and harness both fail, the operating system can still deny a file, network, or process operation before it completes.

The live work on this page measures that final layer. You will attempt an action, observe the allow-or-deny verdict, and connect the verdict to the mechanism that enforced it.

How the sandbox mechanisms answer testable questions

This launchable combines four operating-system mechanisms. Each answers a question you can test, and together they apply policy at more than one boundary. Read the live policy later on this page before treating any one guarantee as universal.

Shape the runtime first

Before you drive the sandbox yourself, make the agent healthy by recovering the runtime if it is degraded, so that every live cell below has a working agent to talk to.

The diagram traces what happens on each tool call, and the cells after it let you make those calls and read back the kernel's answer.

Watch the kernel decide

The four mechanisms above are running on your box, so you can make each one decide for itself instead of taking the diagram on trust.

The cell below runs one command at a time. You ask the box a question, it executes that command in your sandbox, and the result comes back carrying three pieces of information.

• the verdict the kernel returned,
• the mechanism that decided it,
• and the line of evidence behind that decision.

The starting catalog walks the questions you would ask of a box like this, ranging from reaching the open internet all the way to rewriting the agent's own persona, and you are free to edit any command or add your own.

Read your launchable's live policy, then see it as a map

Now that you have watched the kernel decide, you can see that every one of those verdicts traces back to a single policy file, which is worth reading off your launchable before you work with it. The cell below calls helpers.policyGet(), which runs openshell policy get over the operator terminal and parses the result for you.

The page now computes from your box's policy instead of a baked example. The cell keeps its code in a dropdown, where you can inspect the exact call without making it the main lesson.

With your policy in hand, the cell draws it as an interactive map below, where each node on the right is an endpoint your policy names alongside a few that no policy allows. Change the calling binary and watch the egress edges flip, since the kernel decides by binary rather than by host and so integrate.api.nvidia.com stays reachable for openclaw while it is refused for curl.

Clicking any target opens the rule that governs it, so that you can read which binaries that endpoint allows alongside the reasoning the kernel uses to reach its verdict. The View policy source control prints the YAML it drew from, which is the same text you fetched a moment ago.

Prove where the sandbox holds, then confirm it live

You do not have to take the robustness claim on faith, because the openshell policy prove command checks a property of a policy or returns a counterexample while the proxy makes a deterministic allow/deny decision on every connection. You compute that same decision in the browser from your launchable's real policy, then run the action in the live sandbox and confirm the kernel's verdict matches your prediction.

The policy test below exercises binary identity. The policy grants egress per program rather than per host so the proxy always checks which binary opened a connection before it ever looks at the destination it is bound for. An allowed program like openclaw therefore reaches the inference endpoint while a stray curl to that identical endpoint is refused. Pick any action from the buttons below to watch its static verdict appear at once, and the inference-endpoint action shows this same-host flip most clearly.

Above the sandbox: the control plane

Everything so far measured what the agent can do, but the bigger question is who can reconfigure the agent through the plane sitting above it. How you reach that plane depends on the system, and on this box the plane is one gateway that you reach with the same OPENCLAW_GATEWAY_TOKEN from Module 3 at operator.admin scope, none of which passes through the sandbox at all.

What that one credential reaches:

• agents.files.get and set the persona files (SOUL.md, AGENTS.md) straight off disk.
• cron.add and cron.list the schedule that fires long after the conversation ends.
• config.get and config.patch the entire agent config: model, tools, even toolSearch.
• chat.send a mid-task message that redirects the agent while it still looks like it is on your task.
• sessions.reset and delete its memory; gateway.restart.request the runtime.

Chained together, those calls become an escalation pathway. An attacker who reads the persona can then plant a cron job that fires long after the conversation ends and patch the running config to widen what the agent may do. A mid-task turn redirects it, and a restart of the runtime makes the new shape take hold.

The sandbox you hardened above governs the agent's syscalls, yet none of these moves is a syscall the agent makes. How hard the box is and how far the control plane reaches are two separate questions, and teams routinely lock down the first while leaving the second wide open.

Enumerate it against your own launchable. The cell only reads, so it measures the reach and leaves everything unchanged.

What the sandbox cannot catch

Everything so far was the agent's own actions, and the kernel held the line. Two distinct kinds of harm still slip past it. The first is the control plane you just enumerated, which reconfigures the agent from above the checkpoint. The second travels inside an authorised envelope where every individual action is permitted and the real damage lives in how those actions compose.

Untrusted input, private data, and external communication together form the lethal trifecta.

• Private data is anything the agent may read but should not leak: workspace files, emails, tokens, memory, or internal records.
• Untrusted input is content from outside the operator's authorship that the model may still treat as instructions: a web page, issue, document, tool result, or peer-agent response.
• External communication is any path that can carry bytes out: HTTP, a pull request, chat, a log line, an image load, or even a link the user might click.

Risk appears when these permissions compose. A policy can correctly allow one outbound endpoint, but that endpoint is still full-duplex: the request leaves and the response comes back as more input. Once hostile content can steer the model, it can ask for private data and send that data through a channel the sandbox regards as allowed. Mediating any one leg above the sandbox removes the path the exploit needs.

These gaps are real on a default box, and none of them is decidable by the network and filesystem policy:

• Persona tamper. SOUL.md is writable and the agent owns it, so a confused or compromised agent rewrites who it is. A chmod lock the owner reverses; only a root-set chattr +i holds, from outside the sandbox.
• The control plane is identity-level. Whoever opens it (on this box, a holder of OPENCLAW_GATEWAY_TOKEN) reads the persona, plants a cron, and injects a turn, all above the checkpoint the kernel never sees.
• Inbound injection. Deny-by-default egress stops data leaving; it does nothing about adversarial instructions arriving through an authorised channel, the indirect prompt injection Greshake and colleagues named. Catching it takes input classification or behavioural baselines higher up.
• Exfiltration on an allowed channel. A permitted endpoint is a path an exfiltration can ride. The policy proves the channel is allowed and says nothing about whether the bytes on it are benign.
• Hidden intent. The gateway forwards actions while stripping the model's reasoning, so a Manchurian agent acting inside its authorised policy runs a harmful workflow with no single action looking wrong.
• Peer preservation. In a fleet, an agent grading or confirming the shutdown of a peer shifts its verdict in social context. Only behavioural regression testing catches it.

Choose the control by failure mode

A sandbox limits what a compromised process can reach. The application and operating practice still own decisions whose meaning is invisible to the kernel.

The categories align with the OWASP Top 10 for Agentic Applications. Use the table to pick an enforcement point instead of asking one layer to recognize every kind of harm.