Abstract

Regulators on both sides of the Atlantic now expect AI systems to be stoppable, controllable and auditable. The EU AI Act requires effective human oversight, including the ability to interrupt a system (Article 14(4)(e)), automatic record-keeping (Articles 12 and 26), robustness and cybersecurity (Article 15), and additional safeguards for general-purpose models with systemic risk (Article 55), on the timeline set by the Digital Omnibus (Regulation (EU) 2026/1744). In the United States, federal proposals under debate would require frontier developers to:

  • keep a human shutdown capability;
  • comply with government suspension or restriction of models presenting imminent risk;
  • obtain approval of specific model versions;
  • report critical incidents, including model-weight theft and loss of control;
  • support independent verification.

State laws already set frontier-model transparency duties (California SB 53) and consumer protections for automated decisions (Colorado, from 2027). The NIST AI RMF and ISO/IEC 42001 ask organisations to turn risk responses into operating controls.

Engineers at AI laboratories and large platforms raise one objection first: latency. A cryptographic check before every tool call or action, they argue, will slow agents, raise compute costs and break production systems. This disclosure answers that objection, and the related objections about safe states and key control, for an execution-time enforcement architecture. In that architecture, every consequential AI operation is non-completable by default. It completes only when a protected enforcement point verifies five conditions and releases the needed capability (a key, release token, network path or enable signal). The five conditions are:

  • a scoped identity;
  • an authorised purpose;
  • a fingerprint of the approved model and code;
  • the applicable jurisdiction;
  • single-use temporal validity.

A signed receipt is written before release or refusal, and any uncertain check fails to a defined safe state.

The latency answer.

  • What is gated. The check applies only to consequential acts: payments, external sends, production writes, key releases and physical actuation. It does not apply to model inference, reasoning, retrieval, drafting or internal reads, so most steps in an agent workflow carry no added cost.
  • Cold path. Expensive work runs once per task or session: policy evaluation, remote attestation, jurisdiction appraisal and any human approval.
  • Hot path. At the moment of effect, the enforcement point performs only a deterministic check: digest comparison, counter comparison, one signature verification and nonce consumption. Reference implementations measured about 0.2–0.5 ms of local decision time.
  • No new network hop. The check can run inside commit points that already exist: database transactions with conditional writes, payment submission, API gateways, service-mesh sidecars, admission controllers and key-release services.
  • Repeated actions. Actions inside an approved envelope (same tool, purpose, destination and limits) use short-lived local authority, verified at the sink without a central round trip.
  • Where the cost is real. HSM or enclave calls, cross-region state lookups, fresh attestation and human approval add latency. They are reserved for high-consequence actions. Real-time trading and control loops need bounded envelopes and on-device enforcement.
  • Net effect. The overhead is a risk-weighted tax: near zero for computation, small for routine actions, and higher only where the consequence justifies it. Production-scale benchmarks remain a stated next step.

Safe states without broken workflows. Refused actions never start, so nothing is left half-finished. Applications receive typed outcomes (ALLOW, ESCALATE, REEVALUATE, HOLD, DENY) and handle them like any API result. Multi-step tasks use prepare-then-commit with a compare-and-swap decision log, in which the first COMMIT or ABORT is final. If the coordinator crashes, the task closes cleanly. Systems that cannot reserve are handled through separately authorised compensation actions. The deploying organisation defines safe states per domain. Crash recovery never blindly replays consumed authority.

Root-key control. Root keys stay with the accountable operator: the model provider, cloud operator or deploying enterprise. No government holds keys or a remote switch. A legal order, such as an EU market-surveillance measure or a US suspension order, enters through normal legal process and becomes an operator-signed policy update applied across all deployments. Receipts show when each deployment stopped. Regulators and auditors verify receipts rather than control systems. Where neutrality between companies matters, optional threshold signing, transparency logs and separation of duties are available.

Regulatory mapping.

  • EU AI Act and EU law. Withheld capability provides an Article 14 interruption that works even if the model or host does not cooperate. Pre-action receipts support Articles 12 and 26. Model-fingerprint gating supports Articles 15 and 55. Purpose checks support Articles 5 and 9. GDPR purpose limitation and sovereignty are enforced without blanket data localisation. The disclosure discusses whether a non-inferential cryptographic gate is itself an AI system.
  • US law.Without taking any political position, the disclosure shows how the same mechanism supports the requirements under debate:
    • a shutdown capability that does not depend on model cooperation;
    • suspension orders enforced through fingerprint revocation;
    • pre-deployment approval made technically binding;
    • incident reporting from tamper-evident timelines;
    • gated export of model weights;
    • verification by independent auditors.
  • Layered requirements. EU, US federal and US state requirements are encoded as layered policy sets on one mechanism, so a change in the federal-state settlement changes policy, not architecture.

Limits stated openly. Every effect path must be enforced, or prevention is not claimed. The method contains the consequences of prompt injection rather than detecting it. It does not solve post-release misuse, wrong policies, covert channels, aggregation across separately permitted requests, or total hardware compromise. No new hardware is mandatory. The approach complements OAuth, identity platforms, policy engines and attestation. Relevant standards venues include CEN-CENELEC JTC 21, ISO/IEC JTC 1/SC 42, NIST, the IETF and ETSI/3GPP.

The document contains forty-two questions and four drawings. It accompanies the full technical disclosure on Technical Disclosure Commons at https://www.tdcommons.org/dpubs_series/14228/.

This 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). Related family applications can be cross-checked on WIPO PATENTSCOPE.

The regulatory descriptions, including the status of US proposals, and the industry-pattern statements are AI-generated. They are not legal advice and must be cross-checked against official legal texts, the official legislative record and the original PCT filings before drawing any conclusion. Performance figures come from reference implementations in local test environments, not production systems. Licensed under CC BY-NC 4.0. The author is open to acquihire or strategic collaboration.

Keywords

execution-time enforcement; AI enforcement latency; performance overhead; hot path and cold path; AI agent tool-call authorization; AI kill switch; AI shutdown capability; model suspension; pre-deployment approval; AI incident reporting; model weight exfiltration; EU AI Act; Article 14 human oversight; Article 14(4)(e) interruption; Article 12 record-keeping; Article 15 cybersecurity; Article 55 systemic risk; Digital Omnibus; GDPR purpose limitation; US AI regulation; US federal AI legislation; California SB 53; Colorado AI law; NIST AI RMF; ISO/IEC 42001; policy enforcement point; API gateway authorization; service mesh sidecar; admission controller; database conditional commit; compare-and-swap; prepare and commit; saga compensation; safe state; fail-safe; crash recovery; root key governance; threshold signing; transparency log; signed receipts; tamper-evident audit; prompt injection containment; capability-based security; confidential computing; hardware security module; machine enforcement.

Creative Commons License

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

Download

Share

COinS