The problem
Containment and safety are different properties
Thirty years of sandbox engineering solved a real problem. It is not this one. A sandbox bounds where computation can reach; it says nothing about what legitimately granted authority can do.
The deputy does not have to be malicious
In 1988 Norm Hardy described a compiler that ran with the authority to write its own billing file. A user passed the billing file's name as the output argument, and the compiler — behaving exactly as designed — destroyed the billing record.1 The program was not compromised. It was plainly confused: it held authority for one purpose and was induced to spend it on another.
Broadly every property of that scenario now applies to an agent that reads a web page, a support ticket, a sensor label, or a PDF. The agent holds permissions you deliberately granted. Attacker-controlled text arrives through a channel you deliberately opened. The agent tends to spend your authority on the attacker's goal, and every individual action is authorized.
This is clearly why "the model goes rogue" is the wrong threat to design against. It is speculative, it invites an argument about machine intentions, and it is strictly weaker than the attack that already works.
The attacks are documented, not hypothetical
In 2024 researchers reported a 100% jailbreak success rate against three deployed robot systems — a self-driving LLM simulator, a Clearpath Jackal ground vehicle running GPT-4o, and a Unitree Go2 quadruped — including black-box attacks where only the public API was available.2 Separately, a Bluetooth provisioning flaw yielded root access across Unitree's Go2, B2, G1 and H1 platforms.3
What has not been documented, and we will not claim, is an injury caused by a language model driving a robot. The demonstrated gap is attackability. That is probably enough to act on, and overstating it would likely be the fastest way to lose the audience that matters.
Software guardrails for agent systems exist and are improving: CaMeL enforces capability and provenance metadata around a planner;4 FIDES applies information-flow labels to an agent loop;5 RoboGuard synthesises temporal-logic safety specifications over robot plans.6
Each runs on the same computer as the agent, and RoboGuard uses a language model inside its own trust boundary. They reduce risk. They do not survive the compromise of the machine they run on.
Harm inside a perfectly enforced envelope
Assume the sandbox never fails, and that the capability table is exactly right. The following are all authorized, and all plausibly harmful.
Resonance inside every limit
A setpoint stream whose instantaneous velocity never exceeds the configured limit, and whose per-tick delta never exceeds the rate limit, can still excite a drivetrain resonance. Mechanical Q typically does the rest. Per-axis kinematic limits are instantaneous predicates; they do not bound energy accumulated over time.
Cartesian composition
Every joint can sit inside its own position and velocity envelope while the tool tip traverses the space a person occupies. Speed-and-separation limits are defined in Cartesian space; joint-space limits are not a sound approximation of them. ISO/TS 15066 says so in its own normative note: a speed limit that monitors only the tool centre point "does not monitor other parts of the robot that might pose hazards to the operator."7
Field confusion in a signing gate
A gate that signs bytes and enforces "amount ≤ cap" is checking a field it
believes is the amount. An ERC-20 approve call carries a value of
zero while granting unlimited future spend. A partially-signed Bitcoin transaction can
route change to an address the policy never inspected. The cap is satisfied; the account may be drained.
The lesson we took from this is architectural: the trusted side must construct the effect, not inspect bytes handed to it.
What the theory says is possible
This is the part most safety pitches skip, and it is the part that determines what can honestly be promised.
Schneider established that a policy enforceable by monitoring a single execution must be a safety property on traces, meaning informally that its violation is witnessed at a specific moment.8 Clarkson and Schneider later showed that noninterference, the property that secret inputs do not influence public outputs, holds of no single execution at all. It is a hyperproperty, a predicate over sets of executions.9
Read naively, that says a runtime monitor can never enforce information flow, and a great deal of security marketing quietly depends on readers not knowing this.
Those separation results rest on the undecidability of halting. Under a fuel bound, every execution is finite and enumerable, and the obstruction weakens: termination-insensitive noninterference is 2-safety, and Clarkson and Schneider show that a k-safety hyperproperty reduces to an ordinary safety property of the k-fold self-composition, which amounts to running the bounded interpreter more than once.
We treat this as a design direction, not a delivered feature. It is the reasoning behind fuel-bounded execution and capability partitioning in the architecture, and we state it here so it can be checked rather than taken on faith.
The practical consequence: strict limits, rate ceilings, envelope containment and effect confinement are enforceable at runtime and are what the product delivers. Claims about what a bounded agent cannot infer or leak require far more care, and we make none of them today.
References
- Hardy, The Confused Deputy, ACM SIGOPS OSR 22(4), 1988. doi:10.1145/54289.871709
- Robey et al., Jailbreaking LLM-Controlled Robots, 2024. arXiv:2410.13691
- Reported by IEEE Spectrum, 2025: a Bluetooth Wi-Fi provisioning flaw giving root access on Unitree Go2, B2, G1 and H1.
- Debenedetti et al., Defeating Prompt Injections by Design (CaMeL), 2025. arXiv:2503.18813
- Costa et al., Securing AI Agents with Information-Flow Control (FIDES), 2025. arXiv:2505.23643
- RoboGuard, 2025, reporting unsafe-plan execution reduced from 92% to under 3% under adversarial prompting. arXiv:2503.07885
- ISO/TS 15066:2016, clause 5.5.4.2.3, note. A companion note at 5.5.5.4 states that force limiting may be effective only below a speed limit, requiring a combination of safety functions.
- Schneider, Enforceable Security Policies, ACM TISSEC 3(1), 2000.
- Clarkson & Schneider, Hyperproperties, Journal of Computer Security 18(6), 2010.