Abstract

AI agents now do much more than answer questions. They:

  • call tools and MCP servers;
  • run shell commands and apply code patches;
  • operate browsers and desktops;
  • invoke app intents;
  • write to databases, vector stores and agent memory;
  • send messages and payments;
  • send personal context to cloud models.

Today’s safeguards include prompt guardrails, safety classifiers, sandboxes, app permissions, OAuth tokens, tool schemas and audit logs. These decide whether an agent may generally use an interface. They do not decide whether this specific act, on this data, for this purpose, should happen now. They also do not stop data purpose laundering: data collected for one purpose being turned into embeddings, summaries, memories or training data and reused for another.

This disclosure describes a pre-execution enforcement architecture for agentic AI that closes both gaps:

  • Non-effective hold. Every proposed tool call, MCP action, function call, app intent, browser or computer-use action, shell command, apply-patch edit, database or vector-store write, memory update, cloud-assist request, payment or message is held as a non-effective proposed action.
  • Out-of-agent validation.A protected enforcement domain outside the agent validates the action before anything is released. It can be a TEE, secure enclave, HSM, TPM, confidential-computing enclave, DPU or SmartNIC. It checks:
    • agent and model identity, and runtime behaviour;
    • a sealed instruction context (system, developer and user instructions, permitted tools and policies), so prompt-injection drift is caught;
    • the provenance of retrieved documents, embeddings, memory items, tool descriptions and webpages;
    • purpose, output class, tenant, jurisdiction, and policy and revocation freshness.
  • Receipt first, then handle. The domain commits a tamper-evident validation receipt. It then derives a single-use, non-bearer execution handle from that receipt, bound to the act hash, the endpoint and a nonce. Without the receipt, no valid handle can exist.
  • Endpoint enforcement.The endpoint performs the action only after verifying the handle and atomically marking it consumed. Endpoints include:
    • the tool dispatcher, MCP boundary or API gateway;
    • shell, code-patch and kernel boundaries (eBPF, Linux Security Modules, seccomp, Landlock);
    • database commit controllers, payment interfaces and egress points.
  • Typed tool contracts. The endpoint accepts only typed parameters into a locked tool template. Raw model-generated commands are rejected, so arbitrary command execution becomes structurally inexpressible.
  • Governed derivative data. Authorised outputs, embeddings, memories and model updates carry an output binding manifest: permitted future purpose, training use, recipients and expiry. Any later reuse is itself a governed act.
  • Further coverage.The 50 claims also cover:
    • device-bound handles;
    • private cloud-assist with no-retention evidence, where the cloud reply is held until verified;
    • multi-authority quorum;
    • jurisdiction-conflict receipts;
    • risk-tiered fresh validation;
    • equal treatment of first-party and third-party assistants;
    • fail-closed denial.
  • Design-around closures. Sixteen closures address model swaps, purpose relabelling, consent rollback, backups and logs, embedding laundering, unauthorised training, insider and break-glass access, shadow pipelines, replay and cross-tenant leakage.
  • Agentic bypasses. A separate section closes agent-loop shortcuts, raw command injection, poisoned retrieval and kernel-level escape.

Industry relevance (AI-generated). This section was generated with AI assistance and describes technical relevance only. Readers must cross-check it against the original PCT filing on WIPO PATENTSCOPE and official company sources before drawing any conclusion. Naming a company or product is not an endorsement, a validation, a criticism or a statement of infringement, and no company named is affiliated with the inventor. These are potential integration scenarios, not confirmed company implementations or product commitments.

The filing itself names the following as non-limiting implementation contexts:

  • Apple: Apple Intelligence, Siri, App Intents, Private Cloud Compute, the Foundation Models framework.
  • Google: Android, Gemini, Gemini Nano, AICore, Chrome.
  • Meta: Meta AI, Llama Stack, WhatsApp.
  • Anthropic: Claude, Claude computer use, Claude Desktop, the Model Context Protocol.
  • OpenAI: ChatGPT Enterprise, the OpenAI Agents SDK, the Responses API, function calling, ComputerTool, ShellTool, ApplyPatchTool, Codex.

The architecture could complement current public agent-safety directions:

  • Anthropic: sandboxing, egress proxies and credential isolation in Claude Code and Cowork.
  • OpenAI: the Agents SDK native sandbox with shell, apply_patch and MCP.
  • Google: Agent Gateway, Agent Identity and Model Armor; Android AppFunctions for Android MCP.
  • Microsoft: Windows agent connectors behind an MCP proxy; Agent 365 and Entra Agent ID.
  • AWS: Bedrock AgentCore Policy and Gateway.
  • Meta: Muse/Sentinel egress control.
  • NVIDIA: OpenShell and BlueField-4 Sentry.

In each case it would add per-act, receipt-derived authority verified at the endpoint, plus purpose-bound governed derivative data. It is also relevant to:

  • Coding agents: GitHub Copilot agent, Google Jules, Cursor, Replit.
  • Enterprise agent and data platforms: Salesforce Agentforce, ServiceNow, SAP Joule, Workday, Snowflake, Databricks, MongoDB.
  • Confidential-computing silicon: Intel TDX, AMD SEV-SNP, Arm CCA, AWS Nitro Enclaves.
  • Security vendors: Okta, CrowdStrike, Palo Alto Networks, Zscaler, Cloudflare.

In Europe, the mechanisms may support objectives associated with:

  • GDPR: purpose limitation (Article 5(1)(b)) and data protection by design (Article 25).
  • EU AI Act: data governance (Article 10), record-keeping (Article 12), human oversight (Article 14), and robustness and cybersecurity (Article 15).
  • Digital Markets Act: equal treatment of first-party and third-party assistants.

Technical alignment with these provisions does not itself establish regulatory compliance.

This disclosure is based on PCT/IB2026/056058 (WO 2026/154461, filed 13 June 2026, published 23 July 2026). That filing builds on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026. The inventor is open to acquihire or strategic collaboration.

Keywords: AI safety; agentic AI safety; agentic AI security; AI agent tool-call authorization; tool abuse prevention; MCP security; Model Context Protocol; function calling security; computer-use agent security; browser agent security; coding agent security; shell tool sandbox; apply_patch; sandbox escape prevention; prompt injection defence; indirect prompt injection; instruction hierarchy; RAG poisoning; retrieval integrity; vector-store integrity; memory poisoning; tool-description poisoning; data purpose laundering; purpose limitation; function creep; training-data governance; data lineage; derived data governance; output laundering; typed tool contracts; least privilege; zero-trust execution; non-bearer capability; proof-of-possession; single-use authorization; receipt-before-release; exactly-once execution; anti-replay; confidential computing; TEE; HSM; TPM; DPU; SmartNIC; eBPF; Linux Security Modules; seccomp; Landlock; kernel-level enforcement; private cloud compute; no-retention inference; multi-party authorization; human-in-the-loop; fail-closed; break-glass control; insider threat; cross-tenant isolation; GDPR Article 5(1)(b); GDPR Article 25; EU AI Act; Digital Markets Act; Claude; Claude Code; ChatGPT; Codex; OpenAI Agents SDK; Gemini; Agent Gateway; Copilot; Agent 365; Apple Intelligence; App Intents; Meta AI; Llama Stack; Bedrock AgentCore; OpenShell

Creative Commons License

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

Download

Share

COinS