Abstract

Abstract

Disclosed are systems and methods that prevent an AI model, AI agent, tool runtime or computer-use agent from causing an unauthorised external effect by bypassing the path on which policy is enforced. In existing agent platforms, controls are usually applied at a tool gateway, policy engine or approval prompt. The same agent can often reach the same resource through other effect-capable routes:

  • raw sockets or direct HTTP;
  • file commits;
  • clipboard, sharing and inter-process communication;
  • accessibility automation;
  • privileged host connectors reachable from a sandbox;
  • device or accelerator queues.

Monitoring, logging and detection observe such effects but cannot refuse them. Approvals given through a user interface can diverge from the request that actually reaches the backend. Routing, tool installation, credential rotation and hardware assignment can also change between approval and execution.

In the disclosed architecture, every consequential operation is a Candidate Act held in a Non-Effective State. A Protected Enforcement Domain validates source authority and evidence and issues scoped, non-bearer finality enablement. A coverage controller then:

  • discovers and classifies all effect-capable paths to the governed resource;
  • verifies whether each interface can actually block an effect or can only monitor it;
  • records a protected coverage commitment bound to the current topology, workload identity, attributed hardware resources and an enforcement coverage epoch.

Material runtime changes advance the coverage epoch and invalidate pending acts until coverage is re-established. Examples are tool installation or upgrade, route or proxy changes, container restarts, credential rotation, GPU or device reassignment and privilege transitions.

A blocking Finality Sink at the last preventable boundary reconstructs the actual operation as presented for effect, using canonicalisation: destination after redirects, resource identity, method, parameters, body digest and resource version. It verifies the reconstructed operation against current source authority, the scoped enablement and the coverage epoch. It then atomically consumes single-use authority in rollback-resistant sink-local state, so replay, concurrent first use and snapshot restoration are refused.

For computer-use and browser agents, human confirmation is bound to the action digest, target element identity, window focus and UI state. The backend sink refuses any request that differs from the approved one, which covers focus swaps, overlays, DOM changes and screenshot/backend mismatch.

For sandboxed tools, any output promotion or host-resource access requires a separate, source-authorised escape-finality permission; no privilege is inherited implicitly. OAuth, Rich Authorization Requests, DPoP, remote attestation, COSE-signed evidence, OS permissions and IPC identity are consumed as qualified inputs establishing only what they prove, never as finality by themselves. Where an unprivileged mobile application cannot mediate system-wide effects, the guarantee is limited to enumerated enforceable boundaries, and residual bypass paths are stated.

The disclosure includes:

  • key points for examiners with search terms;
  • architecture and fail-closed decision-gate drawings for each source unit;
  • reference data structures and algorithms for actual-effect descriptors, coverage graphs and assurance levels, path discovery, sink-local consumption, computer-use approval and sandbox output promotion;
  • ten implementation variations: gateway with egress lockdown, container without host connectors, browser backend binding, mobile receiver-side sink, accessibility guard, GPU job gate, database commit gate, payment redirect pinning, IoT actuator gate and CI coverage scanning;
  • six threat models;
  • twenty proposed validation tests;
  • IETF and EU AI Act mappings.

The disclosure is distinguished from API gateways and policy engines that enforce on one path; from EDR, DLP and monitoring that detect but do not block; from sandboxes that isolate but do not govern escape effects; from anti-clickjacking and confirmation prompts that do not bind approval to the backend request; and from attestation that proves platform state but not act-specific coverage.

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

  • Apple iOS, iPadOS and macOS (App Intents, Shortcuts, desktop sandboxing, computer use, Siri)
  • Google Android, Binder IPC and Intents, Google Cloud, Gemini and agent gateways
  • Samsung Bixby
  • Microsoft Windows, Azure, agent execution containers and Copilot
  • Amazon Alexa
  • OpenAI agent APIs, Codex and computer-use systems
  • Anthropic Claude and sandboxed development agents
  • Meta Muse/Sentinel-style isolated agent architectures
  • NVIDIA OpenShell, Sentry, BlueField and accelerators
  • Qualcomm Snapdragon, Arm and embedded hardware
  • Huawei device platforms
  • banking and payment APIs
  • cloud API gateways, databases and SaaS
  • telecom, IoT and robotics

Names identify engineering problem classes only. They are not certifications, 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), which 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 following units of the 3,567-page specification published on Zenodo (https://zenodo.org/records/23657985), at pages 1–14, 15–62, 555–609, 1222–1308, 1626–1682, 1898–1952 and 2093–2168:

  • the cross-platform foundation
  • Common Workflow CW-1
  • Miscellaneous Embodiments M-1 and M-2
  • Embodiments 14, 19 and 25

Those page numbers refer to that specification, not to the PCT page count. It is expanded here from Internet-Draft draft-das-finality-sink-enforcement-00, dated 26 October 2026 (Part 4 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

complete mediation; reference monitor; policy enforcement point; blocking enforcement; monitoring versus blocking; bypass prevention; alternate effect path; effect-path discovery; attack surface inventory; coverage proof; coverage commitment; enforcement coverage epoch; runtime topology change; configuration drift; hardware resource attribution; GPU reassignment; egress control; raw socket bypass; HTTP redirect; request canonicalization; actual-operation reconstruction; body digest; single-use authorization; anti-replay; snapshot rollback; compare-and-swap; computer-use agent; browser agent; UI overlay; clickjacking; focus swap; accessibility automation; human approval binding; sandbox escape; container escape; privileged host connector; output promotion; OAuth RAR; DPoP; remote attestation; COSE; App Intents; Android Intents; Binder IPC; agent gateway; 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