Abstract

AI agents increasingly run inside sandboxes, containers, microVMs and WebAssembly runtimes. Isolation keeps the agent process in, but it does not keep the consequences in. A confined agent can still:

  • ask a privileged broker or operating-system service to act for it;
  • reach the network through a route the proxy does not see;
  • use a credential daemon or connector;
  • submit work to a GPU or NPU command queue that keeps running after revocation;
  • reach memory through DMA or peer-to-peer device access;
  • touch firmware and out-of-band management paths.

A kernel tracing hook or telemetry sensor may watch these effects without being able to stop them. The agent may also change the security policy that governs it, roll a tool back to an older version, or present a signed attestation or witness report that is stale or shares a compromised source. A sandbox policy or permission check does not bind the eventual resource mutation to the exact operation that was authorised.

This disclosure keeps every consequential operation non-effective until a blocking Finality Sink on the actual effect path verifies five things: current source authority, the actual pending operation, enforcement-route coverage, scoped non-bearer finality, and sink-local consumption. It covers eight mechanisms:

  1. Dynamic discovery of new effect paths, including tools, routes, GPUs and devices.
  2. Classification of monitor-only versus genuinely blocking controls, with runtime bypass detection and hardware attribution.
  3. Integration of OAuth, ACE, OS permissions, RATS attestation and COSE evidence as inputs that prove only what they prove.
  4. A separate, source-authorised transition before sandbox output or broker requests become privileged effects, with credentials isolated from the workload.
  5. Generation-safe tool and runtime installation, upgrade and rollback.
  6. Treatment of security-policy and configuration mutations as consequential acts that need a separate competent authority and change-impact analysis.
  7. Qualification of witnesses and attestation by freshness, competence and independence, so common-mode or replayed evidence is refused.
  8. Fences on GPU queues, DMA scopes and firmware paths where these are actually controllable.

Trusted hardware may protect parts of the process, but it is never assumed to verify effects it cannot block. Claims for each platform are limited to its supported interfaces.

The disclosure includes:

  • key points for examiners, with search terms
  • architecture and decision-gate drawings for each source unit
  • reference structures and algorithms
  • ten implementation variations
  • sixteen threat models
  • thirty-six proposed validation tests
  • IETF and EU AI Act mappings

Industry relevance (AI-generated): the patterns apply to publicly described environments, including:

  • Apple iOS, iPadOS and macOS sandboxing, App Intents, Siri and Apple Intelligence
  • Google Android, Binder, Keystore and Gemini; Samsung Galaxy AI
  • Microsoft Windows, virtualization-based security, agent sandboxes and Copilot
  • Linux seccomp, eBPF, LSM and microVMs
  • OpenAI Codex; Anthropic Claude Code; Google Cloud
  • Meta Muse/Sentinel credential-proxy designs
  • NVIDIA OpenShell, Sentry, BlueField and GPU egress
  • Qualcomm Snapdragon TEEs and modems; Huawei HarmonyOS and telecom controllers; Arm TrustZone and confidential execution
  • AWS, Azure and Google Cloud AI workload isolation
  • AI PCs and NPUs; gVisor and WebAssembly sandboxes; browser agents; confidential AI clouds; baseboard management controllers
  • software-defined vehicles; medical devices; industrial control; drones and robotics; satellite ground segments

Names identify engineering problem classes only. No vulnerability, implementation, copying or infringement is alleged, and no endorsement is implied. This material is AI-generated and must be cross-checked against the original PCT filings and primary sources before drawing any conclusion.

This technical disclosure is based on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026 (WO 2026/150382). That application claims priority from PCT/IB2026/053385, filed 7 April 2026 and publicly disclosed 4 June 2026 (WO 2026/115520).

The source text corresponds to the cross-platform foundation, Miscellaneous Embodiments M-1 and M-2, and Embodiments 14, 25, 26, 33 and 38 of the 3,567-page specification published on Zenodo (https://zenodo.org/records/23657985), at pages 1–14, 555–609, 1222–1308, 1898–1952, 2092–2168, 2169–2245, 2826–2913 and 3282–3378. Those page numbers refer to that specification, not to the PCT page count. It is expanded here from Internet-Draft draft-das-hardware-execution-finality-00, dated 26 October 2026 (Part 11 of a 12-part series).

Diagrams, schemas, implementation variations, threat classifications and proposed tests are newly authored explanations, not claimed as filed content or experimental results. Related family applications can be cross-checked on WIPO PATENTSCOPE. Licensed under CC BY-NC 4.0. The author is open to acquihire or strategic collaboration.

Keywords

AI agent sandbox; container escape; microVM; gVisor; WebAssembly sandbox; seccomp; Linux Security Module; eBPF monitoring versus enforcement; privileged broker; confused deputy; network egress bypass; credential daemon; credential laundering; GPU command queue; NPU; DMA; IOMMU; peer-to-peer device access; firmware; BMC; virtualization-based security; TrustZone; TEE; confidential computing; remote attestation; RATS; TEEP; SUIT; witness independence; policy hot-swap; configuration change control; tool rollback; runtime generation; execution finality; Finality Sink; EU AI Act.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS