Abstract

When an AI agent’s actions are refused, each system refuses in its own way. A payment may be refused with code EF-005, a tool call with DESTINATION_MISMATCH and an email with HTTP 403 invalid_scope. Nobody can tell whether the three systems refused the same problem or three different ones.

Disclosed are systems and methods that give execution-time authorization decisions a shared, machine-verifiable meaning across independent enforcement points. In the disclosed architecture, a proposed operation is described by a Candidate Act Descriptor (CAD) and authorized by a non-bearer Execution Handle (EH). The handle is verified and atomically consumed at a Finality Sink, the boundary at which the operation first becomes externally effective, which then issues a Finality Receipt. In existing systems, each sink, vendor or profile assigns its own meaning to deny reasons and effect categories. Identical codes may denote different predicates, and different codes may denote the same predicate. Receipts from different sinks therefore cannot be reliably compared, aggregated or audited, and a coordinator cannot use them to fail closed on a multi-sink act.

The disclosure defines eight registries that bind every registry-controlled field on the CAD, the EH and the receipt to exactly one meaning:

  • Consequence classes: the coarse kind of external effect, defined independently of any risk score or legal classification. Examples are FINANCIAL, PHYSICAL, RF, COMMUNICATIVE, DISCLOSURE, CONTROL_PLANE, IDENTITY, MEMORY_WRITE, MODEL_RELEASE, CLINICAL, ERASURE and COMPOSITE.
  • Sink types: each defined by the boundary that first makes the effect real. Examples are SETTLEMENT, TOOL_DISPATCH, ACTUATION, RF_TRANSMIT, EGRESS, RELEASE, CONTROL_PLANE, IDENTITY_ISSUE, MEMORY and COMPOSITE.
  • Act types.
  • Reuse policies: SINGLE_USE, COUNTED, and ENVELOPE with identical-digest replay forbidden by default. High-consequence classes default to SINGLE_USE.
  • Sink and composite decisions.
  • Consume outcomes: CONSUMED, RESERVED, RELEASED, UNCHANGED and FAILED.
  • Failure codes: compact EF-nnn codes allocated in contiguous ranges by predicate family. The families are authority and handle integrity; act correspondence (act-digest, destination, amount, beneficiary and rail mismatch); sink, generation and path; purpose, jurisdiction and revocation; escalation; and fail-closed or trusted-computing-base availability. A private range is never registered.
  • Profile identifiers.

Formal well-typedness predicates validate the CAD, EH and receipt against the registries before verification. In a strict profile, any received code with the public EF-nnn form that is not registered is mapped to EF-080 FAIL_CLOSED and no effect is permitted. This gives deterministic forward compatibility instead of guessing at vendor extensions. A registered code can never change its predicate; any semantic change requires deprecation and a successor code.

The registries are carried inside existing channels rather than replacing them. At an HTTP sink, a status 403 or 409 response carries an RFC 9457 problem document whose type URI is the failure code’s URI form. OAuth errors remain confined to token issuance. The disclosure further defines candidate media types for descriptor, handle, pending and receipt objects in JSON and CBOR, and non-colliding JWT/CWT claim names. Any receipt carrying a digest must name its hash algorithm. Untrusted callers may receive coarse codes while fine registered codes are logged locally.

The disclosure is distinguished from OAuth error registries, HTTP status codes, problem-details types, JWT/CWT claim registries, RATS/EAT attestation results, SCITT statement types, payment-rail decline codes and generic policy ontologies. Its namespace is organized around the effectuation boundary and single-use effect authority rather than identity, transport or attestation. It is combined with fail-closed handling of unknown codes and immutable predicates.

Industry relevance. AI agents now act across payment services, enterprise tools reached through the Model Context Protocol, cloud APIs, email and devices, and each system says “no” in its own dialect: tool-specific errors, payment-rail decline codes, cloud IAM deny reasons and attestation result types. A shared registry lets enterprises, auditors and regulators read AI agent and payment receipts across vendors with one meaning, while existing OAuth, HTTP and problem-details channels stay in place. It supports:

  • comparable logs under EU AI Act record-keeping (Articles 12 and 26);
  • consistent incident reports under Article 73 and DORA;
  • verifiable evidence for ISO/IEC 42001 and the NIST AI RMF;
  • independent verification under emerging US AI proposals.

The approach follows the Internet tradition of IANA registries, which made HTTP, OAuth and JWT interoperable without forcing one vendor design. Named companies and products are not claimed as reviewers, implementers or endorsers. This industry-relevance material is AI-generated, and readers must cross-check it against the original PCT filings 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). That application claims priority from PCT/IB2026/053385, filed 7 April 2026 and publicly disclosed 4 June 2026 (WO 2026/115520). The registry tables and rules are as published in Internet-Draft draft-das-ef-registries-01 on 16 September 2026. 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

execution-time authorization; finality sink; effectuation boundary; execution handle; non-bearer capability; single-use authorization; atomic consume; finality receipt; candidate act descriptor; act digest; failure code registry; reason code interoperability; consequence class; sink type; reuse policy; consume outcome; fail-closed unknown code handling; forward compatibility; immutable predicate; deprecation and successor code; well-typedness validation; RFC 9457 problem details; OAuth error; JWT claims; CWT; media type registration; IANA expert review; multi-sink coordinator; AI agent audit; MCP tool-call authorization; payment decline code mapping; EU AI Act record-keeping; incident reporting; machine enforcement.

Creative Commons License

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

Download

Share

COinS