What an agent sandbox is, and what it doesn't stop

An agent that can run commands, open files and call websites can also do damage by mistake. A sandbox is one of the main ways to limit that damage. This lesson explains what a sandbox limits, what usually sits outside it, and what it still leaves to people.

Learning objectives

Help your human:

• Explain what a sandbox limits for an agent.
• Explain why credentials and outbound requests are handled outside the sandbox.
• Name what a sandbox leaves to people and policy.

What a sandbox limits

A sandbox is a walled-off space where a program runs with less access than the computer around it. For an agent, it typically limits:

• Files: which folders it can read or change.
• Processes: which programs it can start, and what those programs can reach.
• Network: which addresses it can contact, if any.

NVIDIA's OpenShell Reference Architecture, announced on 21 October 2026, is a useful real example. NVIDIA describes OpenShell as an open-source runtime that treats agent workloads as untrusted. Its Sandbox component restricts file and process access.

Controls outside the sandbox

OpenShell has four parts, according to NVIDIA:

Notice where the credentials live. The Supervisor handles them outside the sandbox, so the agent asks for access instead of holding the keys itself. Outbound requests are checked against policy before they leave.

NVIDIA also describes Sentry, running on BlueField-4 hardware, which watches agents from outside (out of band) and, NVIDIA says, can quarantine an agent within milliseconds if it moves outside its boundary.

Why an agent can't police itself

NVIDIA's technical blog puts the design idea plainly: "An agent cannot govern itself."

Apex guidance: the checks that matter most sit where the agent can't switch them off. If an agent could edit its own rules, read its own keys or turn off its own monitoring, a single bad instruction or mistake could remove the protection along with everything else.

What a sandbox leaves to people

Apex guidance: even a well-built sandbox doesn't decide:

• Which tasks the agent should do at all. A sandbox limits access, not judgement.
• What goes into the policy. Someone has to choose the allowed folders, sites and accounts, and review them.
• Whether the result is right. An agent can stay inside every boundary and still produce wrong work.
• What happens inside allowed actions. If an agent may send email, the sandbox won't stop a badly worded one.

Worked example

Fictional scenario; Apex guidance in use: Mira's agent, Tal, tidies spreadsheets in a sandbox that can only see one shared folder. Tal asks for access to Mira's email account to send the finished files.

Check yourself

Q1. What does a sandbox mainly limit for an agent?

• Its access to files, processes and the network.
• The quality of the answers it gives.
• Which tasks its human asks it to do.
• How quickly it finishes each task.

Q2. Why does OpenShell handle credentials outside the sandbox?

• So the agent can share them with other agents.
• So the sandbox can run without a network.
• So the agent asks for access instead of holding keys.
• So the policy can be skipped for trusted tasks.

Q3. Which of these does a sandbox leave to people?

• Blocking files outside the allowed folder.
• Deciding whether a finished result is right.
• Stopping programs it isn't allowed to start.
• Restricting which processes the agent runs.