Abstract

On-device AI assistants and agents on phones, tablets, PCs, smart glasses, headsets and cars increasingly act across apps. They send messages, attach files, fill forms, make payments, read the screen, and use the camera, microphone and location. Platforms want to open these capabilities to third-party assistants, and regulators increasingly expect it. But conventional app permissions and entitlements are broad and reusable, so opening them can expose user data and give an assistant more authority than the user intended.

This disclosure describes a device-side execution-control architecture that allows assistant interoperability while keeping privacy and security as built-in properties. It works as follows:

  • Requests are held. Each requested device action is held as a non-effective proposed action. This covers app-intent and app-function calls, shortcuts, accessibility actions, browser and computer-use actions, MCP tool calls, plug-in outputs and SDK uploads.
  • The OS supplies evidence but cannot grant authority. The operating system provides app identity, code signature, sandbox state, entitlement, user intent and foreground state. It cannot itself issue the authority to act.
  • A hardware-isolated domain decides. This can be a secure enclave, TrustZone trusted application, StrongBox, Titan M or Knox Vault, optionally combined with a confidential-cloud or HSM component. It checks the request against user intent, purpose, data scope, destination, runtime behaviour, on-device model identity, jurisdiction, revocation state and freshness.
  • Receipt first, then capability. The domain commits a tamper-evident receipt. It then releases a single-use, non-bearer, act-scoped capability bound to that app or agent, that resource, that recipient and that endpoint.
  • The endpoint verifies before acting. The endpoint performs the action only if the capability verifies; copied, replayed or redirected capabilities fail. Endpoints include message-send and file-export controllers, payment and wallet controllers, sensor-release controllers, display compositors, and network egress and IPC gates.
  • Every assistant is treated the same. First-party and third-party assistants face the same checks for equivalent actions. The receipts give platforms, enterprises, auditors and regulators machine-verifiable evidence of equal treatment.
  • Low latency. Preparation runs ahead of time, so the hot-path check is designed for sub-millisecond, hardware-assisted verification, subject to implementation and benchmarking.
  • Two deployment routes.The architecture works with native OS support, through kernel security hooks and an accessibility-route interposer. It also works without native OS integration, through:
    • app-side distributed endpoints;
    • hybrid device-cloud protected domains;
    • messaging-platform gates;
    • wearable sensor-capture and cloud-return gates.
  • Compromise resistance. Where the boundary is non-bypassable, a compromised OS process can stage an action but cannot independently complete it.
  • Act-bound freshness. This addresses time-of-check-to-time-of-use (TOCTOU) risks: stale approvals, changed recipients, substituted files and unauthorized delegation.

The 46 claims and 36 design-around closures cover:

  • export of on-device AI data as a separate act;
  • multi-step tool-call and sub-agent delegation without widening scope;
  • biometric step-up for high-value actions that no agent can satisfy independently;
  • on-device model identity checks;
  • alternate routes, accessibility paths, fragmentation, private first-party interfaces, policy downgrade and emergency modes.

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

  • Apple.The architecture can support Apple’s privacy-first approach to opening Siri-level capabilities to third-party assistants. A potential implementation would use:
    • Secure Enclave-rooted, act-by-act capabilities for App Intents, Shortcuts and Siri actions;
    • Private Cloud Compute as an optional hybrid component;
    • Face ID or passcode step-up for Apple Pay and Wallet actions;
    • per-act sensor governance on Apple Watch and Apple Vision Pro.
  • Google.Possible fits include:
    • Android AppFunctions and Android MCP tool calls;
    • Gemini on Android and Gemini in Chrome agentic browsing;
    • Titan M and Android Private Compute Core;
    • Wear OS and Android Automotive.
  • Samsung. Galaxy AI cross-app tasks, with Knox Vault as the protected domain.
  • Microsoft. The relevant products are Windows agent connectors and the on-device agent registry, the Windows MCP proxy, agent workspace, Copilot on Copilot+ PCs, Pluton, Copilot Studio and Agent 365.
  • Meta. The relevant products are Ray-Ban Meta and Oakley Meta glasses, Quest, Meta AI, and WhatsApp and Messenger third-party chat interoperability. Muse/Sentinel is relevant for agent egress.
  • Amazon. Alexa+ device and purchase actions; AWS Bedrock AgentCore Policy and Gateway for cloud-assisted agents.
  • Third-party assistant and agent providers:
    • OpenAI: ChatGPT agent and Codex;
    • Anthropic: Claude, Claude Cowork, Claude Code and Claude in Chrome;
    • Perplexity: the Comet browser;
    • Mistral AI (Le Chat) and Aleph Alpha.
  • Agent payments. Relevant schemes include Apple Pay, Google Wallet, Google Agent Payments Protocol (AP2), Stripe Shared Payment Tokens, Visa Intelligent Commerce and Trusted Agent Protocol, and Mastercard Agent Pay.
  • Chips and secure elements. Qualcomm Snapdragon secure processing, Arm TrustZone and Confidential Compute Architecture, MediaTek, NXP, Infineon, STMicroelectronics and NVIDIA (OpenShell and BlueField for hybrid enforcement).
  • Vehicles. In-car assistants and payments at Mercedes-Benz, BMW, Volkswagen Group and Stellantis.
  • Operators and enterprise. Nokia, Ericsson, Deutsche Telekom, Orange, Vodafone and SAP.

Future roadmap relevance (AI-generated). Siri, Gemini, Copilot, Meta AI, Claude, ChatGPT and other assistants are moving toward more autonomous, cross-application actions. As they do, the architecture could provide a common protected execution-authority layer that is independent of the underlying AI model. It could complement the Model Context Protocol (MCP), the Agent2Agent (A2A) protocol and enterprise agent orchestration. It does this by separating agent communication and task delegation from final permission to execute.

In Europe, the mechanisms may support objectives associated with:

  • Digital Markets Act, Article 6(7): interoperability with relevant operating-system, hardware and software features, subject to applicable conditions.
  • EU AI Act, Articles 12, 14 and 15: record-keeping, human oversight, and accuracy, robustness and cybersecurity, where applicable.
  • GDPR, Article 25: data protection by design and by default.

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

This disclosure is based on PCT/IB2026/055870 (WO 2026/150384, filed 10 June 2026, published 16 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; on-device AI agent security; AI assistant interoperability; privacy-preserving interoperability; per-action authorization; least privilege; capability-based security; non-bearer capability; proof-of-possession; secure enclave; trusted execution environment; Arm TrustZone; StrongBox; Titan M; Knox Vault; Pluton; Private Cloud Compute; confidential computing; App Intents; AppFunctions; Android MCP; Windows agent connectors; accessibility API security; computer-use agents; browser agents; MCP tool calls; Agent2Agent (A2A); agent delegation; TOCTOU protection; prompt-injection containment; data exfiltration prevention; on-device model attestation; biometric step-up; agent payments; AP2; fail-closed; Digital Markets Act Article 6(7); EU AI Act; GDPR; Siri; Gemini; Galaxy AI; Copilot; Meta AI; Alexa+; Claude; ChatGPT; Android; iOS; Windows; smart glasses; XR

Creative Commons License

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

Download

Share

COinS