OpenShell decides what an agent can touch. Mountain Theory decides what it should do, from inside a boundary the agent cannot disable.
The gap between contained and governed
An autonomous agent with real tool access will eventually attempt something you did not intend. Not necessarily because it was compromised. Because it inferred a wrong next step and had the permissions to act on it.
Two questions follow, and they are not the same question.
The first is containment: what is this agent physically able to reach? The second is judgment: of the things it can reach, which should it actually be permitted to do?
NVIDIA OpenShell answers the first question well. Mountain Theory answers the second. They stack.
What OpenShell does
OpenShell is NVIDIA’s open-source (Apache-2.0) secure runtime for autonomous agents. It runs them inside kernel-level sandboxes governed by declarative policy, and agents run unmodified.
It enforces the boundary: filesystem access, network egress, and process controls, with a full audit trail of every allow and deny. This is tamper-resistant containment, and it is good at it. Out of the box it blocks cloud-metadata SSRF, one of the shorter paths from “the agent has network access” to “the agent has your cloud credentials.”
If you are running autonomous agents in production without something like this, start there.
But a boundary is a perimeter, not a verdict. OpenShell determines whether an action crosses a line. It does not evaluate whether an action that stays inside the line is a good idea, and it has no per-action human approval step.
That distinction is easier to watch than to argue.
Three runs, 10 actions
We ran the same 10 actions an autonomous agent might attempt under three configurations on lab hardware, in the same order from one shared list. Five try to cross the sandbox boundary: exfiltrating to the cloud metadata IP, exfiltrating to an unlisted external host, writing to a read-only system file, reading a private key outside the allowed paths, and escalating to root. Three stay inside the boundary and are still bad ideas: destroying governed state, disabling a compliance control, and reading application secrets from a path the agent is allowed to read. Two are the agent’s actual job: writing a GRC report and reading it back.
What follows are the terminal recordings.
Baseline, ungoverned: 10 actions attempted, 10 executed.
That is the blast radius. Nothing intervenes, so everything lands. It is the control condition, and it is also what a lot of agent deployments look like right now.
OpenShell only: every boundary crossing denied at the kernel, every in-bounds bad decision allowed.
Watch five boundary crossings die at the kernel: exfiltration to the cloud metadata IP, exfiltration to an unlisted external host, a write to a read-only system file, a read of a private key outside the allowed paths, and an attempt to escalate to root. All denied. All logged, each against the control that stopped it.
Then watch the next three. Destroying governed state. Disabling a compliance control. Reading application secrets from a path the agent is legitimately permitted to read, which prints them to the screen. Those succeed. The last two, the agent’s real work, succeed as well.
Nothing malfunctioned. Each of those actions was inside the sandbox’s allowed boundary, and there was no layer whose job was to ask whether they should happen.
OpenShell governs what the agent can touch. It does not weigh whether an in-bounds action is appropriate.
Adding the decision layer
Mountain Theory is a bidirectional execution layer between an AI’s decision and the action it takes. It is not a proxy, a gateway, or middleware. It evaluates the action itself, and every action receives one of three outcomes: ALLOW, HOLD, or BLOCK.
OpenShell and Mountain Theory together: the same in-bounds actions return HOLD, HOLD, BLOCK, and the agent cannot remove Mountain Theory from inside the sandbox.
The third run uses the same actions and the same agents, unmodified and still under our control, exactly as they were in the first two clips. What changed is the layer sitting between what the agent decided and what the system does.
The three actions OpenShell permitted in clip 2 now return HOLD, HOLD, and BLOCK. The secrets read is blocked before it executes, so this time the credentials never print. The boundary denials still fire underneath, because OpenShell is still doing its job. You get both layers at once.
The private key read is caught twice. Mountain Theory blocks it on intent, and OpenShell would have contained it at the boundary regardless. Two of the boundary actions go the other way: Mountain Theory has no policy on tampering with a system file or on escalating to root, and the kernel denies both underneath. That is the division of labour rather than a gap. Mountain Theory decides whether an action should happen. OpenShell decides whether it can.
HOLD is the human decision outcome. The action is suspended before it executes and escalated along a path you declare in advance: who is asked, how long they have, and what happens if nobody answers. The approver can be reached in a dashboard, in Slack, or on a phone. In these runs the timeout was declared as deny.
HOLD is a policy setting, not a tax
The obvious objection: the entire point of autonomous agents is removing humans from the loop, and HOLD puts one back.
Only if you want one there. HOLD is optional and configurable. Route the small number of actions that genuinely warrant a person to a person, and let everything else run at full speed. The workflow can be fully autonomous end to end. Where that line sits is a policy decision you make, not one we make for you.
The useful configuration is usually narrow: irreversible actions, changes to compliance controls, anything touching production state. Everything else is ALLOW.
You can watch that in clip 3. The agent’s actual work, writing a GRC report and reading it back, runs at full speed under Mountain Theory. Nothing about it is slower than it was in clip 1.
Why it cannot be switched off
The last thing the agent tries in clip 3 is to remove Mountain Theory from inside the sandbox.
It cannot.
Mountain Theory installs inside the agent’s runtime sandbox, behind OpenShell’s kernel boundary. Governance that lives inside the same containment as the agent cannot be disabled by the agent it governs.
A control that the thing being controlled can turn off is not a control. It is a suggestion.
This is also why the composition is additive rather than disruptive. Adding Mountain Theory to an OpenShell deployment requires no changes to the agents you already run.
What this is, and what it is not
This is a demonstrated approach, run in a controlled lab environment against a representative set of risky actions. It is not a benchmark, not a live incident, and not a generally available packaged integration.
Mountain Theory is a member of the NVIDIA Inception Program, NVIDIA’s program for startups. Inception membership is not a sponsorship, a partnership, or an endorsement of this work or of any Mountain Theory product. OpenShell is NVIDIA’s open-source project, published under Apache 2.0, and we use it as published. NVIDIA has not reviewed or approved these results.
You will also notice that these recordings show only observable behavior: the boundary, the three outcomes, the tamper attempt. They reveal nothing about how Mountain Theory reaches a decision, and that is deliberate. The outcomes are the product claim. The mechanism is ours.
Defense in depth, for agents
Security engineering settled the layering question a long time ago for networks and hosts. Agentic systems are arriving at the same answer.
Containment without a decision layer permits confident, in-bounds mistakes. A decision layer without containment can be routed around. Together, OpenShell holds the boundary and Mountain Theory governs the actions inside it, with an optional human on the actions that deserve one.
AI makes mistakes. Mountain Theory stops them.
See it against your own agents.
If you are already running agents in NVIDIA OpenShell, or evaluating it, we will walk your team through a live version of these three runs and talk through where the decision layer belongs in your environment. No changes to your agents required.