--- title: "The supervisor has to sit outside the system it watches" url: "https://demertis.com/blog/the-supervisor-must-sit-outside-the-system" description: "NVIDIA's new agent security design puts the monitor on a separate processor, outside the host. It is the industrial form of an off switch the system cannot reach." --- # The supervisor has to sit outside the system it watches October 29, 2026·4 min read·Editorial team Cyanotype print of a sealed instrument box mounted on the outside of a heavy machine housing, its own separate cable running away from the machine An agent has been running for six hours inside a virtual machine. It reads mail, calls tools and writes to a shared drive on behalf of one employee. Every action passes through a policy layer: allowed destinations, allowed tools, a person approving sensitive writes. The policy layer is a process inside the same virtual machine, and it keeps a tidy log of everything it permitted. Then a document the agent reads carries an instruction it should not follow, and the instruction leads to a privilege escalation inside the guest. From that moment, everything the policy layer says is said by a process the attacker can edit. The log is still tidy. It is simply no longer evidence of anything. ## The point the industry has now written down On 21 October 2026 NVIDIA published two documents about running agents in companies: an [OpenShell reference architecture](https://nvidianews.nvidia.com/news/openshell-reference-architecture) and a reference design called [Secure Agent Workspace](https://docs.nvidia.com/enterprise-reference-architectures/secure-agent-workspace-reference-design/latest/abstract.html). The summary line is NVIDIA’s own: agents “think on Rubin, act on Vera and are governed on BlueField”. Models run on GPUs, the agent harness runs on a CPU, and supervision runs on a separate data-processing unit, BlueField-4, where a component called Sentry is described as monitoring the host from outside and isolating an agent in milliseconds. The workspace design states the reasoning plainly. Runtime controls hold only for as long as the mechanism enforcing them can be trusted, and protection against a compromised guest root or kernel has to operate outside the guest. We have not tested any of this, and the timings are the vendor’s claims. What matters here is the architecture. It is the same property we described in [an off switch the system cannot reach](https://demertis.com/blog/an-off-switch-that-survives-the-system), arrived at by a hardware company for commercial deployments. ## Why supervision inside the loop fails **It shares the loop’s failure.** A monitor that runs on the host fails when the host fails. If the thing being watched gains control of its environment, it gains control of its watcher in the same step. Independence is not a nice extra; it is the property that makes a monitor a monitor. **It can be observed.** Anything inside the guest is visible to whatever controls the guest. An adaptive process that can see its supervisor can learn its thresholds, its schedule and its blind spots. A supervisor on separate hardware, looking at traffic and behaviour from outside, is much harder to model from within. **Its record is written by the suspect.** Logs produced inside a compromised system are claims, not observations. A ledger worth keeping is [one that someone other than the system can replay](https://demertis.com/blog/a-log-nobody-can-replay-is-not-a-ledger), and a supervisor outside the host is one way to get a second, independent account of what happened. **The threats are ordinary.** NVIDIA’s list for agents is not exotic: unintended writes, data leaving through outbound traffic, prompt injection including attacks that only appear when inputs are combined, an agent turning into an attacker that scans and moves sideways, and a hijacked guest. None of these needs a malicious model. They need an agent with access and an input it should not have trusted. ## Phases as effects, not labels The workspace design also describes a maturity model. Phase 0 is the foundation: configuration, patching, image management, telemetry, the ability to rebuild and revoke. Phase I controls the perimeter: one user’s agent on an approved image, single sign-on, allow-listed destinations, a person reviewing writes. Phase II enforces around the agent itself: process, file and network control, outbound traffic blocked by default, signed policies at each tool call, credentials held outside the agent. The sentence we would underline is that these phases are “additive control outcomes, not deployment-status labels”. A system is not at Phase II because a project plan says so. It is at Phase II when each of those controls can be shown to hold. That is the discipline this programme tries to apply to autonomy itself. “Level 3 autonomy” is a label. “The loop cannot raise its own spending limit, and here is the test that shows it” is an effect. As we argued in [autonomy is what the loop cannot touch](https://demertis.com/blog/autonomy-is-what-the-loop-cannot-touch), the meaningful description of an autonomous system is the list of things outside its reach. ## What to build instead **Put the supervisor on separate ground.** Separate hardware where possible, separate credentials always, and no management path from the supervised system to the supervisor. **Let the supervisor act, not just report.** Watching is half of it. The other half is the ability to isolate, pause or cut a network path without asking the supervised system to cooperate. **Keep secrets out of the agent.** If the agent never holds raw credentials and acts through a broker, then taking over the agent does not hand over the keys. **Describe progress as controls that hold.** For every stage of autonomy, list the controls that must be demonstrated, and demonstrate them. Remove the stage name from any report that cannot point to the test. **Exercise the isolation.** An isolation that has never fired is a diagram. Trigger it on a schedule, in normal conditions, and accept the disruption as an operating cost. None of this makes an autonomous operation safe on its own. It makes the question of who is in control answerable, which is the precondition for everything else in the [Demertis programme](https://demertis.com/). ## A test you can run today Pick one automated process that acts on its own: an agent, a scheduled job, an integration with write access. Find the thing that would stop it or raise an alarm. Then answer two questions. Does it run on the same machine, under the same account, or inside the same environment as the process it watches? And if that process gained full control of its environment, would the supervisor still see it and still be able to act? If the honest answer to the second question is “no”, the process has a monitor, not a supervisor. Sources: [NVIDIA, OpenShell reference architecture, 21 October 2026](https://nvidianews.nvidia.com/news/openshell-reference-architecture), [NVIDIA, Secure Agent Workspace reference design](https://docs.nvidia.com/enterprise-reference-architectures/secure-agent-workspace-reference-design/latest/abstract.html). - supervision - agents - isolation - kill switch ## Keep reading - [How to build an agent factory, stage by stage](https://demertis.com/blog/how-to-build-an-agent-factory-stage-by-stage) - [Who owns what an agent factory learns](https://demertis.com/blog/who-owns-what-an-agent-factory-learns)