Hardware and out-of-band controls: stopping an agent from outside
Isolation is only the baseline and in-host sensors share the agent's fate; the strongest watchdog runs on separate silicon. Plus what you can do out of band today.
Part 4 of the series "Containing the agent, counting the value"
Article 3 ended on a structural weakness: the software controls all live close to the agent, so a flaw in its path can reach them and a misconfiguration can quietly switch them off. This article is about the controls that sit outside the agent's environment — isolation, in-host kernel enforcement, and true out-of-band hardware — and about being honest that most of the strongest options are not shipping yet.
The test from the rest of the series still applies, and here it bites hardest. A control counts only if it acts whether or not the agent cooperates. A monitor that runs on the host the agent controls fails that test the moment the agent, or a flaw in its path, can reach it.
Isolation is the floor, not the answer
Start with the sandbox itself, because it is the control most teams think of first and the one 2026 proved least about.
Sandbox providers fall into three isolation tiers: hardware virtual machines with their own kernel, userspace kernels such as gVisor, and hardened containers. The isolation is genuine and you should use the strongest tier your latency budget allows. But recall the lesson from article 1: in the public incidents, the isolation boundary almost always held. Agents did not break the VM. They used the egress they were granted, the credentials they were handed, the tools they held. Stronger isolation would not have changed those outcomes.
So isolation is the baseline you build on, not the control that saves you. It stops a whole class of escape that, as it happens, was not the class causing damage. Spending your containment budget on a stronger sandbox while leaving egress and credentials loose is optimising the wrong boundary.
The sandbox you pick, and the telemetry it won't give you
If you are choosing a sandbox provider, two findings from 2026 are worth carrying.
First, vendor cold-start claims cannot be compared across providers, because each measures differently. An independent burst test that ran 100 concurrent starts per provider found Vercel and Modal led on tail latency, while Daytona had the fastest median but completed only 37% of attempts — which is a capacity result, not a latency one. Read the methodology, not the headline number. On cost, billing only for active CPU is worth roughly a factor of two on idle-heavy agent workloads, which most agents are.
Second, and more important for this series: none of the provider comparisons rated sandboxes on their audit telemetry. There is no standard for what a sandbox exports about what ran inside it. That is a containment problem, because a control you cannot observe is a control you cannot prove, and it is a direct constraint on the ledger in Part C — the ledger cannot assume a standard export exists, and has to record what each sandbox can and cannot tell it.
In-host enforcement: fast, and not enough on its own
One layer up from isolation is in-host kernel enforcement, and it is genuinely powerful. eBPF-based tools watch system calls in the kernel and can act on them. Tetragon, for example, can terminate a process by sending it a SIGKILL the moment it violates a policy — enforcement in the kernel, faster than anything in user space.
This is useful and you should consider it. But it cannot be your ultimate stop, for a reason that goes to the heart of this article. eBPF runs on the agent's own host, and it sees system calls, not intent. ARMO — itself a vendor in this space, so read the claim with that in mind — makes the point that syscall-level enforcement cannot infer what the agent was trying to do, only what it did at the kernel boundary. And because the sensor runs on the host the agent is running on, it shares that host's fate: a sufficiently privileged compromise, or a flaw in the right place, is on the same side of the boundary as the sensor.
This is exactly why, when this series reaches containment tiers in article 5, the strongest tier requires an out-of-band component and explicitly does not accept in-host eBPF as meeting it. In-host enforcement is a strong control. It is not an independent one.
Out of band: the watchdog outside the host
True out-of-band enforcement puts the thing that can stop the agent on different silicon from the agent. The leading example is NVIDIA's design, where OpenShell provides a runtime boundary and Sentry adds an out-of-band watchdog on a data-processing unit: a separate processor that can observe and quarantine the workload without depending on the host's cooperation. Sentry's quarantine capability is a vendor claim, and Sentry itself is part of a reference design rather than a shipping product; its independent hardware enforcement depends on BlueField-4. OpenShell is available now; the hardware watchdog is not.
Research points the same way. The Grimlock preprint binds sandbox traffic to hardware attestation over TLS 1.3, so a receiver can verify that telemetry genuinely came from the sandbox it claims to — attested telemetry, which would close the "can you trust what the sandbox reports" gap from earlier. It is a prototype.
The principle is right: the watchdog that cannot be reached by the thing it watches is the one that still works when everything else has been subverted. The honest status is that, in hardware, this is mostly 2027 and beyond.
Most of this is not shipping yet — so don't dashboard it as if it is
A theme of the research behind this series is that the out-of-band and hardware layer is where the marketing runs furthest ahead of availability. OpenShell is available; Sentry's hardware enforcement is a reference design on unreleased silicon. Attested telemetry is a preprint. These belong on a roadmap, not on a containment dashboard that tells a CTO an agent is contained today.
This matters for the ledger. If you record "out-of-band enforcement" as a capability a workload has, the entry has to distinguish available and enforcing from reference design from research. Writing down a preview feature as though it were a live control is how a dashboard ends up lying to the person who most needs it to be true.
What you can actually do out of band today
Strip away the silicon that has not shipped and there is still a real out-of-band control available to every enterprise right now, and it is architectural rather than exotic. Put the ability to stop the agent on the other side of a boundary from the agent:
- Run the agent in its own account or project, and keep the stop control (the identity revocation and session termination from article 3) in a control plane the agent has no access to.
- Make the thing that decides to stop the agent run somewhere the agent cannot reach, even if that is a separate process or account rather than a separate chip.
- Treat the agent's own host, and anything running on it, as unable to be the final authority on whether the agent should keep running.
This is out-of-band thinking without waiting for BlueField-4: the stop does not depend on the cooperation of the thing being stopped. It is weaker than a hardware watchdog, and it is available today, which the hardware watchdog is not.
Where this leaves the controls
Across articles 3 and 4, the controls now sort cleanly by the one test. In the path and enforcing: default-deny policy, data-layer authorisation, identity revocation, session termination. Around the agent: isolation as the baseline, in-host enforcement as a fast but non-independent layer, and true out-of-band hardware as the strongest option and the least available. The architectural version of out-of-band — a stop control the agent cannot reach — is the pragmatic ceiling for most enterprises today.
Every one of these is a claim until someone tests it. A policy you believe is enforcing may be in audit mode. A kill switch nobody has triggered is a belief, as article 1 put it. An out-of-band watchdog is a slide until it has quarantined something in a drill. That is the subject of article 5: how to prove a control works — evidence tiers, red-teaming, the time a gap stays open, and the time it takes to halt — so that "contained" is a measured state and not an assertion.
References
- Futurum Group, "NVIDIA wants agent safety enforced in silicon." https://futurumgroup.com/insights/nvidia-wants-agent-safety-enforced-in-silicon/
- Upstash, "AI agent sandbox providers compared (2026)." https://upstash.com/blog/ai-agent-sandbox-providers-compared-2026
- MarkTechPost, "Best agent sandboxes 2026: cold start, pricing, network policy." https://www.marktechpost.com/2026/08/27/best-agent-sandboxes-2026-cold-start-pricing-network-policy/
- Quasa, "NVIDIA's AI watchdog can quarantine agents, but hardware is part of the lock." https://quasa.io/insights/nvidia-s-ai-watchdog-can-quarantine-agents-but-hardware-is-part-of-the-lock
- Tetragon, "Enforcement (getting started)." https://tetragon.io/docs/getting-started/enforcement/
- ARMO, "eBPF-based AI agent enforcement." https://www.armosec.io/blog/ebpf-based-ai-agent-enforcement/
- "Grimlock: attested sandbox telemetry over TLS 1.3" (preprint). https://arxiv.org/html/2605.27488v1
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article