Abstract

An AI agent or app can hold a valid identity token, a signed request, an OAuth access token, an app permission or a historic approval, and still have no current authority for the operation that is actually about to happen. This is evidence-to-effect authority confusion, and it takes several forms:

  • Tokens are bearer instruments: whoever holds them can use them for anything in scope, at any endpoint, until they expire.
  • A signature over the agent’s stated intent proves nothing if the request that reaches the resource differs from that intent.
  • Approvals go stale as grants are revoked or narrowed.
  • Evidence collected by one component can be forged, replayed, swapped between operations, or produced by a validator that is not really independent.
  • When a process crashes after authority is consumed but before the outcome is known, systems either duplicate the effect or lose track of it.

This disclosure separates the evidence that an operation is permitted from the lower-trust agent output. It then converts that evidence into narrowly scoped authority that is verified at the actual effect boundary:

  1. The original source permission defines the maximum effect envelope.
  2. A collection-time Protected Enforcement Domain records protected evidence of who asked, under which grant and scope.
  3. An independent execution-time domain records fresh evidence of the current operation and context.
  4. The two are cross-committed to the specific Candidate Act, so evidence cannot be substituted between operations.
  5. Only then is a scoped, non-bearer finality enablement constituted. It is bound to the act digest, the designated sink, the current generation and a nonce, and is useless if copied.
  6. The Finality Sink reconstructs the actual pending operation and atomically consumes the enablement.
  7. A crash-consistent effect-intent journal records prepared, consumed, dispatched and confirmed states. Lost acknowledgements produce explicit unknown states that are quarantined and reconciled, never blindly retried.

OAuth, OIDC, DPoP, mTLS, attestation, COSE signatures and OS permissions are adapted as evidence of exactly what they prove, never as finality.

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
  • six threat models
  • twenty proposed validation tests
  • IETF and EU AI Act mappings

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

  • Apple iOS, iPadOS, macOS, Apple Intelligence, Siri and App Intents
  • Google Android, Gemini, Intents, Binder IPC and Android Keystore
  • Samsung Bixby
  • Microsoft Windows, Azure, agent execution containers and Copilot
  • Amazon Alexa
  • OpenAI Responses API, Agents SDK, Codex and computer use
  • Anthropic Claude, Claude Code and managed agents
  • Google Cloud enterprise agents
  • Meta Muse/Sentinel and brokered credentials
  • NVIDIA OpenShell, Sentry, GPUs and DPUs
  • Qualcomm Snapdragon; Huawei; Arm TEEs
  • payment and digital-signature systems
  • cloud SaaS, Kubernetes and service mesh
  • telecom, IoT and edge
  • robotics and critical infrastructure

Names identify technical 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), 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, 63–79, 1309–1384, 1385–1465 and 1898–1952:

  • the cross-platform foundation
  • Common Workflows CW-1 and CW-2
  • Embodiments 15 and 16
  • Miscellaneous Embodiment M-2

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

bearer token risk; token replay; sender-constrained token; proof of possession; DPoP; mTLS; OAuth Rich Authorization Requests; token exchange; OIDC; authorization evidence; evidence binding; cross-commitment; independent validation; collusion; attestation appraisal; RATS; COSE; SCITT; non-bearer capability; one-time authorization; act digest; request signing; HTTP message signatures; write-ahead journal; idempotency; exactly-once; crash recovery; indeterminate outcome; reconciliation; revocation race; scope widening; 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