Execution Finality for Agentic AI: Stopping Unauthorized Tool Calls, Memory Writes, and Real-World Consequences Before They Happen (DAS -- Decoupled Authorisation System)
draft-agentic-ai-tool-execution-finality-00

Independent Submission                                            S. Das
Internet-Draft                                               Independent
Intended status: Informational                               August 2026
Expires: 28 February 2027

  Execution Finality for Agentic AI: Stopping Unauthorized Tool Calls,
  Memory Writes, and Real-World Consequences Before They Happen (DAS —
                    Decoupled Authorisation System)
              draft-agentic-ai-tool-execution-finality-00

Abstract

   Agentic AI systems now call tools, write memory, move money, change
   infrastructure, and trigger physical actions.  Most safety layers
   still decide permission upstream and then trust the downstream path.
   Once that path is compromised, or once the approved request is
   widened, replayed, or substituted, the act becomes real before any
   audit can stop it.

   This document specifies a protected execution-finality architecture
   of the Decoupled Authorisation System (DAS).  It is built on four
   mechanisms: (1) two-instance binding that separates collection-time
   evidence from execution-time validation, (2) mutually load-bearing,
   cross-committed protected evidence so that no single artifact
   authorizes effectuation, (3) scoped non-bearer finality authority
   whose possession alone is never enough, and (4) independent Finality
   Sink reconstruction that re-derives the actual pending operation at
   the effectuation boundary and permits the act only when every
   required condition still matches.

   A Candidate Act remains in a Non-Effective State until the Finality
   Sink has reconstructed the operation, verified the protected evidence
   against sink-local monotonic state, and advanced that state.  Failure
   at any step produces fail-closed denial before effectuation rather
   than post-event remediation.  The architecture is applicable to
   agentic tool use, MCP and connector frameworks, RAG and vector-memory
   systems, cloud control planes, financial settlement, telecom routing,
   and cyber-physical control.

   The document elaborates the problem space, compares the approach with
   representative existing techniques, presents the detailed solution
   and its advantages, supplies JSON Schema definitions for core
   protected objects, and includes an industry-relevance section.
   Related Indian provisional applications and PCT filings appear in the
   final appendix.

Das                     Expires 28 February 2027                [Page 1]
Internet-Draft           DAS Execution Finality              August 2026

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 2 February 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Problem Space . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Technical Field . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Background and the Escalation Path from Computation to
           Consequence . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Core Technical Weaknesses of Upstream-Only
           Authorization . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Specific Risks in Agentic AI and Tool-Using Systems . . .   7
   3.  Limitations of Representative Existing Approaches . . . . . .   7
     3.1.  Policy Engines and Upstream Authorization . . . . . . . .   7
     3.2.  Bearer Tokens and Capability Objects  . . . . . . . . . .   7
     3.3.  Trusted Execution Environments Alone  . . . . . . . . . .   8
     3.4.  AI Moderation, Guardrails, and Output Filtering . . . . .   8
     3.5.  Logging, Monitoring, and Post-Hoc Audit . . . . . . . . .   8
     3.6.  Agent Frameworks and Tool-Calling Middleware  . . . . . .   8
     3.7.  Simulation and Digital-Twin Checks Alone  . . . . . . . .   8
   4.  Proposed Solution: Protected Execution-Finality
           Architecture  . . . . . . . . . . . . . . . . . . . . . .   9

Das                     Expires 28 February 2027                [Page 2]
Internet-Draft           DAS Execution Finality              August 2026

     4.1.  Key Concepts  . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Two-Instance Binding  . . . . . . . . . . . . . . . . . .   9
     4.3.  Mutually Load-Bearing, Cross-Committed Validation
           Evidence  . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Scoped Non-Bearer Finality Authority  . . . . . . . . . .  10
     4.5.  Independent Finality Sink Reconstruction  . . . . . . . .  10
     4.6.  Additional Embodiments and Strengthening Mechanisms . . .  10
     4.7.  Core Rule . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Detailed Finality Sequence  . . . . . . . . . . . . . . . . .  11
   6.  Non-Completability and Authority-Withholding Embodiments  . .  13
   7.  Comparison and Betterment Relative to Existing Approaches . .  13
   8.  JSON Schema Definitions for Core Protected Objects  . . . . .  15
     8.1.  Candidate Act . . . . . . . . . . . . . . . . . . . . . .  15
     8.2.  Collection-Time Binding Artifact  . . . . . . . . . . . .  15
     8.3.  Execution-Time Validation Artifact  . . . . . . . . . . .  16
     8.4.  Scoped Non-Bearer Execution Handle  . . . . . . . . . . .  17
     8.5.  Ledger-Anchored Validation Receipt  . . . . . . . . . . .  17
   9.  Representative Workflows  . . . . . . . . . . . . . . . . . .  18
     9.1.  Agentic Tool Dispatch Workflow  . . . . . . . . . . . . .  18
     9.2.  Memory and Retrieval Operational-Use Workflow . . . . . .  19
     9.3.  Multi-Agent Delegation Workflow . . . . . . . . . . . . .  19
     9.4.  Cloud Control-Plane Mutation Workflow . . . . . . . . . .  19
   10. Threat Model Notes and Residual Risks . . . . . . . . . . . .  19
   11. Industry Relevance and Applicability  . . . . . . . . . . . .  20
     11.1.  Agentic AI, MCP, and Tool Ecosystems . . . . . . . . . .  20
     11.2.  Cloud Control Planes and DevOps / CI-CD  . . . . . . . .  20
     11.3.  Financial Settlement and Digital Assets  . . . . . . . .  20
     11.4.  Telecom, 5G/6G, and Network Control  . . . . . . . . . .  21
     11.5.  Cyber-Physical, Robotics, OT/ICS, and Satellites . . . .  21
     11.6.  Data Governance, Privacy, and Regulated Systems  . . . .  21
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   14. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   15. Normative References  . . . . . . . . . . . . . . . . . . . .  22
   16. Informative References  . . . . . . . . . . . . . . . . . . .  22
   Frequently Asked Questions (Critical Technical Concerns)  . . . .  22
     Q1.  Does Finality Sink reconstruction add unacceptable
           latency?  . . . . . . . . . . . . . . . . . . . . . . . .  22
     Q2.  How does this work with legacy systems that cannot host a
           Finality Sink?  . . . . . . . . . . . . . . . . . . . . .  23
     Q3.  What is the performance impact of two-instance binding and
           cross-committed evidence? . . . . . . . . . . . . . . . .  23
     Q4.  Why not just use existing capability tokens or OAuth-style
           tokens? . . . . . . . . . . . . . . . . . . . . . . . . .  24
     Q5.  What happens if the Finality Sink or protected domains are
           unavailable?  . . . . . . . . . . . . . . . . . . . . . .  24
     Q6.  Will this break interactive agent UX with many small tool
           calls?  . . . . . . . . . . . . . . . . . . . . . . . . .  24

Das                     Expires 28 February 2027                [Page 3]
Internet-Draft           DAS Execution Finality              August 2026

     Q7.  How does Finality Sink work in a distributed multi-region
           deployment? . . . . . . . . . . . . . . . . . . . . . . .  25
     Q8.  How does this apply to Model Context Protocol (MCP) and
           plugin servers? . . . . . . . . . . . . . . . . . . . . .  25
     Q9.  Can streaming or partial outputs be handled without holding
           everything non-effective? . . . . . . . . . . . . . . . .  25
     Q10.  Where does human approval fit?  . . . . . . . . . . . . .  25
     Q11.  Does this require new cryptographic primitives or global
           key infrastructure? . . . . . . . . . . . . . . . . . . .  26
     Q12.  How does this relate to audit and compliance logging? . .  26
     Q13.  Can multiple Finality Sinks be composed in a workflow?  .  26
     Q14.  What about false denials and operational brittleness? . .  26
     Q15.  Why is this proposed as an Internet-Draft rather than only
           as product architecture?  . . . . . . . . . . . . . . . .  26
     Q16.  Is a TEE or confidential VM mandatory?  . . . . . . . . .  27
     Q17.  How are replay and rollback of protected state
           prevented?  . . . . . . . . . . . . . . . . . . . . . . .  27
     Q18.  What is explicitly out of scope for the strongest
           guarantees? . . . . . . . . . . . . . . . . . . . . . . .  27
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
   Appendix A.  Intellectual Property Disclosure — Related
           Applications  . . . . . . . . . . . . . . . . . . . . . .  27
     A.1.  Related Indian Provisional Applications . . . . . . . . .  28
     A.2.  Related International (PCT) Applications  . . . . . . . .  29
     A.3.  Relationship to the Mothership Application  . . . . . . .  30
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   The Internet solved communication; it never solved authority
   [Zenodo-Authority].  Modern AI systems no longer only generate text.
   They invoke tools, write to memory, issue API calls, change cloud
   resources, route network traffic, settle payments, and command
   physical devices.  The moment such an operation becomes capable of
   producing its intended consequence is the moment of effectuation.
   Existing safety and authorization layers rarely control that precise
   boundary.

   This document describes a protected execution-finality architecture
   of the Decoupled Authorisation System (DAS).  In this architecture a
   Candidate Act is held in a Non-Effective State until independent
   protected enforcement stages confirm that the act is authorized,
   bounded, current, non-replayed, and identical to the operation that
   is about to become consequence-bearing.  Final authority arises only
   at the effectuation boundary after two-instance binding, cross-
   committed validation evidence, scoped non-bearer capability release,
   and independent Finality Sink reconstruction have all succeeded.

Das                     Expires 28 February 2027                [Page 4]
Internet-Draft           DAS Execution Finality              August 2026

   The architecture is designed so that upstream approval is never
   treated as effectuation.  A policy decision, model decision, or token
   issuance may contribute protected evidence, but it does not by itself
   complete the transition from computation to consequence.  That
   transition is controlled at the boundary where the consequence would
   actually occur.

2.  Problem Space

2.1.  Technical Field

   The present disclosure relates to computer systems, artificial-
   intelligence execution systems, distributed computing systems, secure
   hardware and protected-state enforcement systems, telecom and network
   control systems, cloud infrastructure, financial settlement systems,
   data-governance systems, and cyber-physical control systems.

   More particularly, it relates to systems and methods for preventing a
   computed, generated, routed, delegated, transmitted, written,
   actuated, settled, emitted, disclosed, committed, or otherwise
   effect-capable operation from becoming consequence-bearing unless
   independent protected enforcement stages confirm that the operation
   is authorized, bounded, current, non-replayed, and identical to the
   operation permitted to reach an effectuation boundary.

2.2.  Background and the Escalation Path from Computation to Consequence

   Modern digital systems increasingly perform actions that cause
   external, durable, financial, physical, legal, administrative,
   safety-relevant, network-visible, machine-visible, or user-visible
   effects.  Such actions include AI-agent tool calls, database writes,
   cloud-control-plane operations, telecom routing instructions,
   financial settlements, memory commits, actuator commands, model-
   output releases, data exports, credential releases, access-control
   changes, enterprise workflow approvals, marketplace communications,
   satellite commands, and other effect-capable operations.

   Existing authorization systems commonly evaluate permission at an
   upstream stage.  A software policy engine, application-layer access-
   control component, trusted execution environment, hardware security
   module, agent-governance middleware, gateway, or approval service may
   determine that a request appears permitted.  After this upstream
   approval, a downstream component may simply accept the approval
   result and complete the requested operation.

   This creates a structural gap.  The system that decides “this looks
   allowed” is often not the same system that finally makes the act
   real, and the evidence used for the decision is often not re-verified

Das                     Expires 28 February 2027                [Page 5]
Internet-Draft           DAS Execution Finality              August 2026

   against the actual pending operation at the moment of effectuation.
   The result is an escalation path from computation to consequence that
   can be exploited by replay, substitution, widening, stale policy, or
   compromise of an intermediate path.

2.3.  Core Technical Weaknesses of Upstream-Only Authorization

   The following weaknesses recur across conventional designs:

   1.  *Collapsed separation of duties.* The same component that
       collects or binds relevant data may also validate downstream
       execution, so a single compromise or logic error can both
       fabricate evidence and authorize the corresponding effect.

   2.  *Blind trust of upstream results.* A downstream component may
       merely trust an upstream approval result without independently
       reconstructing the actual pending operation at the effectuation
       boundary.

   3.  *Bearer or weakly bound authority.* A token, receipt, capability,
       or validation result may be replayed, copied, widened,
       substituted, delegated, rerouted, or used in a stale session.

   4.  *Policy and revocation drift (TOCTOU).* Policy or revocation
       state may change after approval.  A system that checks once and
       executes later may effectuate a consequence that is no longer
       valid under current protected state.

   5.  *Misbinding and operation substitution.* Data or descriptors may
       be misbound to an unrelated operation.  The operation observed
       upstream may differ from the operation actually presented at the
       final effectuation boundary.

   6.  *Post-event remediation instead of pre-effectuation denial.* Many
       systems rely on audit, logging, rollback, compensation, or human
       review after an operation has already become effective.  These
       mechanisms may provide evidence, but they do not prevent the
       unauthorized effect from occurring in the first instance.

   There is therefore a need for an execution-finality architecture in
   which authority is not completed merely because an upstream component
   approves a request, issues a token, or validates a policy.  There is
   a need for a system in which a candidate operation remains
   technically non-effective until protected evidence, protected state,
   and an independent finality-boundary reconstruction all agree on the
   same operation, scope, state, sink, and effect.

Das                     Expires 28 February 2027                [Page 6]
Internet-Draft           DAS Execution Finality              August 2026

2.4.  Specific Risks in Agentic AI and Tool-Using Systems

   Agentic systems amplify the above weaknesses because they chain
   tools, memory writes, delegations, and external effects.
   Representative failure modes include:

   *  Tool-supply-chain substitution: a tool definition, connector, or
      MCP server identity differs from the one that was approved.

   *  Schema or parameter widening: the actual arguments presented at
      dispatch exceed the scope that was validated.

   *  Memory and retrieval operationalization: readable embeddings or
      documents are immediately usable for inference, training, or tool
      influence without a separate authority check for that operational
      primitive.

   *  Multi-agent delegation drift: a downstream agent widens, replays,
      or re-targets authority that was scoped only for an upstream task.

   *  Long-running workflow branch effects: a parallel subagent or
      scheduled run effectuates an action under stale or incomplete
      context.

3.  Limitations of Representative Existing Approaches

3.1.  Policy Engines and Upstream Authorization

   Policy engines and access-control systems answer whether a principal
   is allowed to request an operation.  They do not, by themselves,
   guarantee that the operation that reaches the effectuation boundary
   is the same operation that was approved, that the policy epoch is
   still current, or that the downstream path has not been substituted.
   An allow decision can therefore travel further than the conditions
   under which it was issued.

3.2.  Bearer Tokens and Capability Objects

   Ordinary bearer tokens or capability objects authorize by possession.
   Once copied, stolen, forwarded, or replayed they can authorize
   operations outside the original context.  They typically lack
   mandatory binding to an independently reconstructed operation
   descriptor at the final boundary and lack mandatory consumption
   against sink-local monotonic state.

Das                     Expires 28 February 2027                [Page 7]
Internet-Draft           DAS Execution Finality              August 2026

3.3.  Trusted Execution Environments Alone

   TEEs and HSMs can protect computation and secrets.  They do not
   inherently enforce a two-instance separation between collection-time
   binding and execution-time validation, nor do they force independent
   reconstruction of the pending operation at every effectuation
   boundary.  Protected computation without boundary-local
   reconstruction still leaves a trust gap at the moment of
   effectuation.

3.4.  AI Moderation, Guardrails, and Output Filtering

   Content moderation and guardrail models may suppress certain
   generations.  They do not control the machine boundary at which a
   tool call, memory write, or actuator command becomes effective.  A
   moderated text can still reach an effectuation interface through
   another path, and moderation scores are not the same as operation-
   specific, sink-verified finality.

3.5.  Logging, Monitoring, and Post-Hoc Audit

   Audit systems record what already happened.  They support
   accountability and forensics, but they do not prevent an unauthorized
   effect from occurring.  The architecture described here requires
   fail-closed denial before effectuation rather than remediation after
   the fact.

3.6.  Agent Frameworks and Tool-Calling Middleware

   Many agent runtimes, MCP servers, plugin systems, and orchestration
   layers treat a successful policy check or model decision as
   sufficient to dispatch a tool.  They rarely require independent sink-
   side reconstruction of the actual pending tool identity, schema,
   parameters, and destination before dispatch.  As a result, tool
   substitution, schema widening, and endpoint replacement remain
   practical attack and failure modes.

3.7.  Simulation and Digital-Twin Checks Alone

   Simulation can estimate consequences but is often advisory.  Without
   binding the simulation result into protected, mutually load-bearing
   evidence and without requiring Finality Sink verification, a
   simulated-safe act can still be effectuated through a different path
   or under changed state.

Das                     Expires 28 February 2027                [Page 8]
Internet-Draft           DAS Execution Finality              August 2026

4.  Proposed Solution: Protected Execution-Finality Architecture

   The Decoupled Authorisation System (DAS) architecture maintains every
   effect-capable operation as a Candidate Act in a Non-Effective State
   until four cooperating mechanisms succeed.  Final authority is not
   completed upstream; it arises only at the effectuation boundary.

4.1.  Key Concepts

   *Candidate Act* — any proposed effect-capable operation held in a
   Non-Effective State until verified finality authority permits it to
   become consequence-bearing.

   *Non-Effective State* — a technical state in which the Candidate Act
   may be generated, staged, buffered, simulated, or prepared, but is
   not permitted to become consequence-bearing.

   *Effectuation* — the first protected transition by which a Candidate
   Act becomes capable of producing its intended consequence.

   *Finality Sink* — a component positioned at, within, or proximate to
   the effectuation boundary that independently reconstructs the actual
   pending operation and permits effectuation only when protected
   evidence and sink-local state agree.

4.2.  Two-Instance Binding

   A first Protected Enforcement Domain performs Collection-Time
   Binding.  It associates input material, context, source, purpose,
   scope, logic, behavioral envelope, provenance, and permitted effect
   with protected descriptors at or near the point of collection or
   ingestion.  Collection-Time Binding does not authorize effectuation;
   it creates protected evidence that later stages must verify.

   A second, independent Protected Enforcement Domain performs
   execution-time validation of the Candidate Act prepared for possible
   effectuation.  It produces protected validation evidence only when
   the Candidate Act remains within the scope originally bound.  The two
   domains are separated by hardware root, execution instance, trust
   domain, key material, protected-state namespace, or equivalent
   isolation so that compromise of one does not automatically forge the
   evidence of the other.

Das                     Expires 28 February 2027                [Page 9]
Internet-Draft           DAS Execution Finality              August 2026

4.3.  Mutually Load-Bearing, Cross-Committed Validation Evidence

   The collection-time binding artifact and the execution-time
   validation artifact are mutually load-bearing.  Neither alone can
   authorize effectuation.  They cross-commit through hashes,
   signatures, MACs, chained commitments, monotonic counters, policy
   epochs, revocation epochs, or protected-state references.
   Alteration, substitution, or reuse of one artifact without the other
   is detectable.  In stronger embodiments a sequence of Ledger-Anchored
   Validation Receipts forms a chained, replay-resistant validation path
   in which no individual receipt is sufficient by itself.

4.4.  Scoped Non-Bearer Finality Authority

   Upon successful validation a Scoped Non-Bearer Capability, Execution
   Handle, or Execution Authority Receipt may be generated.  Possession
   of the artifact alone does not authorize effectuation.  The artifact
   is bound to operation identity, purpose, jurisdiction, sink identity,
   policy epoch, revocation epoch, and related constraints.  It may be
   single-use, limited-use, non- transferable, non-delegable, and sink-
   bound.  The Finality Sink treats the artifact as insufficient by
   possession and requires correspondence with the reconstructed pending
   operation and sink-local protected state.

4.5.  Independent Finality Sink Reconstruction

   A Finality Sink is positioned at, within, or proximate to the
   boundary where the Candidate Act would otherwise become consequence-
   bearing.  The Finality Sink independently reconstructs descriptor
   elements of the actual pending operation (operation type, payload
   commitment, destination, tool identity, schema, parameters,
   recipient, account, actuator target, etc.) and compares the
   reconstructed descriptor against the protected evidence, the scoped
   non-bearer authority, and sink-local monotonic protected state.

   Effectuation is permitted only when the reconstructed operation
   matches the authorized scope and required sink-local protected-state
   transitions succeed.  If any required condition is missing, stale,
   inconsistent, replayed, revoked, unverifiable, unreconstructable,
   non-monotonic, mismatched, or incomplete, the Candidate Act remains
   in a Non-Effective State and is denied before effectuation.
   Associated pending authority may be poisoned, burned, marked spent,
   quarantined, or revoked to prevent replay or probing.

4.6.  Additional Embodiments and Strengthening Mechanisms

   The base architecture can be strengthened by one or more of the
   following embodiments:

Das                     Expires 28 February 2027               [Page 10]
Internet-Draft           DAS Execution Finality              August 2026

   *  *Measurement-path attestation.* When the Finality Sink obtains
      descriptor elements through a measurement path (register, bus,
      sensor, driver, network-egress observation, etc.), it may require
      attestation of that path before relying on the reconstructed
      values.

   *  *Atomic verify-and-effectuate.* Verification and the first
      consequence-producing transition can be bound into a single
      protected operation (compare-and-commit, write-once release,
      protected latch, etc.) so that a verified act cannot be replaced
      before commit.

   *  *Operational inertness of readable data.* Data, memory objects, or
      retrieval results may remain readable while still being denied for
      high-risk operational primitives (indexing, training admission,
      export, cross-tenant serving) until a scoped non-bearer authority
      is verified for that primitive.

   *  *Share-based and distributed finality.* Multiple independent
      share-producing nodes may contribute partial enablement shares;
      effectuation requires satisfaction of a share policy in addition
      to sink verification.

   *  *Sink-side finality evidence for subsequent operations.* After
      effectuation or denial, the Finality Sink may emit sink-rooted
      evidence that subsequent workflow steps, memory updates, or
      downstream agents must verify before continuing.

   *  *Boundary-local policy and revocation epochs.* The Finality Sink
      maintains its own policy and revocation epochs and rejects
      authority artifacts that are stale relative to those local epochs.

4.7.  Core Rule

   Final authority arises only at the effectuation boundary, after
   independent protected evidence corroborates the Candidate Act, after
   the Finality Sink reconstructs the actual pending operation, after
   sink-local protected state is advanced, and only where the operation
   permitted to become effective is the operation that was bound and
   validated.

5.  Detailed Finality Sequence

   A representative end-to-end sequence is as follows.

   1.   An effect-capable output or request is generated (model output,
        agent plan, automation request, sensor-triggered instruction,
        etc.).

Das                     Expires 28 February 2027               [Page 11]
Internet-Draft           DAS Execution Finality              August 2026

   2.   The system converts it into a Candidate Act and places it in a
        Non-Effective State.  No consequence-bearing transition is
        permitted yet.

   3.   The first Protected Enforcement Domain performs Collection-Time
        Binding and produces a Collection-Time Binding Artifact that
        commits input, context, source, purpose, scope, and related
        descriptors.

   4.   The second Protected Enforcement Domain performs execution-time
        validation against the bound scope and produces an Execution-
        Time Validation Artifact that is cross-committed to the
        collection-time artifact.

   5.   Optional intermediate Ledger-Anchored Validation Receipts are
        generated at validation points and chained so that no single
        receipt is sufficient.

   6.   If validation succeeds, a Scoped Non-Bearer Execution Handle is
        released.  The handle is bound to the operation digest, sink
        identity, epochs, and permitted effect, and is not usable by
        possession alone.

   7.   At the effectuation boundary the Finality Sink independently
        reconstructs a descriptor of the actual pending operation from
        the boundary-local view (payload, destination, tool identity,
        schema, parameters, etc.).

   8.   The Finality Sink verifies the reconstructed descriptor against
        the protected evidence, the Execution Handle, and sink-local
        monotonic protected state (including policy and revocation
        epochs).

   9.   On success, the sink advances protected state and permits
        effectuation (optionally under an atomic verify-and-effectuate
        primitive).  On failure, the Candidate Act remains non-
        effective, the handle may be burned, and the act is denied
        before any consequence occurs.

   10.  Sink-rooted evidence of the outcome may be emitted for use by
        subsequent workflow steps, memory updates, or downstream agents.

Das                     Expires 28 February 2027               [Page 12]
Internet-Draft           DAS Execution Finality              August 2026

6.  Non-Completability and Authority-Withholding Embodiments

   In stronger embodiments the Finality Sink is not merely instructed to
   refuse unauthorized acts; it is technically unable to complete the
   Candidate Act unless protected finality validation supplies,
   reconstructs, unseals, or activates missing execution material.
   Readable data or staged results may remain operationally inert for
   selected primitives even when the underlying bytes are accessible.
   Authority-withholding therefore separates the presence of data or
   computation from the authority to make that data or computation
   consequential.

   This is particularly relevant for RAG stores, vector indexes, agent
   memory, and tool result caches: storage and inspection can be allowed
   while indexing, context injection, training admission, and export
   remain gated by scoped non-bearer authority verified at a Finality
   Sink.

7.  Comparison and Betterment Relative to Existing Approaches

   The following table summarizes the principal differences between
   typical existing approaches and the DAS execution-finality
   architecture.

Das                     Expires 28 February 2027               [Page 13]
Internet-Draft           DAS Execution Finality              August 2026

     +================+====================+========================+
     | Aspect         | Typical Existing   | This Architecture      |
     |                | Approach           | (DAS)                  |
     +================+====================+========================+
     | When authority | Upstream policy or | Only at Finality Sink  |
     | is completed   | token issuance     | after reconstruction   |
     +----------------+--------------------+------------------------+
     | Binding of     | Often single-stage | Two-instance, mutually |
     | evidence       | or loosely bound   | load-bearing, cross-   |
     |                |                    | committed              |
     +----------------+--------------------+------------------------+
     | Token /        | Frequently bearer  | Scoped non-bearer;     |
     | capability     |                    | possession             |
     | semantics      |                    | insufficient           |
     +----------------+--------------------+------------------------+
     | Operation      | Trusted from       | Independently          |
     | identity at    | upstream           | reconstructed by       |
     | boundary       |                    | Finality Sink          |
     +----------------+--------------------+------------------------+
     | Policy /       | Often checked once | Epochs re-verified     |
     | revocation     |                    | against sink-local     |
     | freshness      |                    | state                  |
     +----------------+--------------------+------------------------+
     | Failure mode   | Often post-event   | Fail-closed denial     |
     |                | audit or rollback  | before effectuation    |
     +----------------+--------------------+------------------------+
     | Agent tool /   | Usually policy +   | Sink reconstructs tool |
     | MCP dispatch   | model decision     | identity, schema,      |
     |                |                    | parameters             |
     +----------------+--------------------+------------------------+
     | Memory / RAG   | Readable data      | Readable data may      |
     | operational    | often immediately  | remain operationally   |
     | use            | usable             | inert                  |
     +----------------+--------------------+------------------------+
     | Multi-agent    | Often trusts       | Each step bound; sink  |
     | delegation     | upstream scope     | verifies before        |
     |                |                    | effectuation           |
     +----------------+--------------------+------------------------+
     | Measurement    | Often assumed      | Optional measurement-  |
     | integrity      |                    | path attestation       |
     +----------------+--------------------+------------------------+

                    Table 1: Comparison of Approaches

Das                     Expires 28 February 2027               [Page 14]
Internet-Draft           DAS Execution Finality              August 2026

   The architecture therefore improves on existing techniques by moving
   the decisive authority point to the effectuation boundary, requiring
   independent reconstruction of the pending operation, making evidence
   mutually load-bearing, eliminating bearer semantics for finality
   enablement, and enforcing fail-closed behavior before any consequence
   occurs.

8.  JSON Schema Definitions for Core Protected Objects

   Illustrative JSON Schema (draft 2020-12) definitions.
   Implementations may extend these schemas while preserving the
   required binding, non-bearer, and cross-commitment properties.

8.1.  Candidate Act

   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://das-protocols.example/schemas/candidate-act-v1.json",
     "title": "CandidateAct",
     "type": "object",
     "required": ["actId", "operationDigest", "status", "createdAt"],
     "properties": {
       "actId": { "type": "string", "format": "uuid" },
       "operationDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
       "operationType": { "type": "string" },
       "originatingSystemId": { "type": "string" },
       "modelId": { "type": "string" },
       "toolId": { "type": "string" },
       "intendedSinkId": { "type": "string" },
       "purpose": { "type": "string" },
       "jurisdiction": { "type": "string" },
       "tenantId": { "type": "string" },
       "permittedEffect": { "type": "string" },
       "policyEpoch": { "type": "integer", "minimum": 0 },
       "revocationEpoch": { "type": "integer", "minimum": 0 },
       "status": {
         "type": "string",
         "enum": ["non-effective", "under-validation", "capability-issued",
                  "effectuated", "denied", "quarantined", "spent"]
       },
       "createdAt": { "type": "string", "format": "date-time" }
     },
     "additionalProperties": false
   }

8.2.  Collection-Time Binding Artifact

Das                     Expires 28 February 2027               [Page 15]
Internet-Draft           DAS Execution Finality              August 2026

   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://das-protocols.example/schemas/collection-binding-v1.json",
     "title": "CollectionTimeBindingArtifact",
     "type": "object",
     "required": ["artifactId", "actId", "bindingDigest", "policyEpoch", "nonce"],
     "properties": {
       "artifactId": { "type": "string", "format": "uuid" },
       "actId": { "type": "string", "format": "uuid" },
       "bindingDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
       "alfId": { "type": "string" },
       "rbdId": { "type": "string" },
       "ipsId": { "type": "string" },
       "easoId": { "type": "string" },
       "sourceIdentity": { "type": "string" },
       "purpose": { "type": "string" },
       "permittedEffect": { "type": "string" },
       "prohibitedEffect": { "type": "string" },
       "finalitySinkId": { "type": "string" },
       "policyEpoch": { "type": "integer", "minimum": 0 },
       "revocationEpoch": { "type": "integer", "minimum": 0 },
       "nonce": { "type": "string", "minLength": 16 },
       "timestamp": { "type": "string", "format": "date-time" }
     },
     "additionalProperties": false
   }

8.3.  Execution-Time Validation Artifact

   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://das-protocols.example/schemas/validation-artifact-v1.json",
     "title": "ExecutionTimeValidationArtifact",
     "type": "object",
     "required": ["artifactId", "actId", "collectionArtifactDigest", "validationDigest"],
     "properties": {
       "artifactId": { "type": "string", "format": "uuid" },
       "actId": { "type": "string", "format": "uuid" },
       "collectionArtifactDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
       "validationDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
       "policyEpoch": { "type": "integer", "minimum": 0 },
       "revocationEpoch": { "type": "integer", "minimum": 0 },
       "scopeConfirmed": { "type": "boolean" },
       "ledgerAnchoredReceiptId": { "type": "string" },
       "timestamp": { "type": "string", "format": "date-time" }
     },
     "additionalProperties": false
   }

Das                     Expires 28 February 2027               [Page 16]
Internet-Draft           DAS Execution Finality              August 2026

8.4.  Scoped Non-Bearer Execution Handle

   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://das-protocols.example/schemas/execution-handle-v1.json",
     "title": "ScopedNonBearerExecutionHandle",
     "type": "object",
     "required": [
       "handleId", "actId", "operationDigest", "sinkId",
       "policyEpoch", "revocationEpoch", "expiresAt", "oneTimeUse"
     ],
     "properties": {
       "handleId": { "type": "string", "format": "uuid" },
       "actId": { "type": "string", "format": "uuid" },
       "operationDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
       "collectionArtifactDigest": { "type": "string" },
       "validationArtifactDigest": { "type": "string" },
       "sinkId": { "type": "string" },
       "permittedEffect": { "type": "string" },
       "purpose": { "type": "string" },
       "jurisdiction": { "type": "string" },
       "policyEpoch": { "type": "integer", "minimum": 0 },
       "revocationEpoch": { "type": "integer", "minimum": 0 },
       "nonce": { "type": "string" },
       "expiresAt": { "type": "string", "format": "date-time" },
       "oneTimeUse": { "type": "boolean", "const": true },
       "consumed": { "type": "boolean", "default": false }
     },
     "additionalProperties": false
   }

8.5.  Ledger-Anchored Validation Receipt

Das                     Expires 28 February 2027               [Page 17]
Internet-Draft           DAS Execution Finality              August 2026

   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://das-protocols.example/schemas/lavr-v1.json",
     "title": "LedgerAnchoredValidationReceipt",
     "type": "object",
     "required": ["receiptId", "actId", "receiptDigest", "policyEpoch", "timestamp"],
     "properties": {
       "receiptId": { "type": "string", "format": "uuid" },
       "actId": { "type": "string", "format": "uuid" },
       "receiptDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
       "priorReceiptDigest": { "type": "string" },
       "collectionArtifactDigest": { "type": "string" },
       "validationArtifactDigest": { "type": "string" },
       "operationDigest": { "type": "string" },
       "sinkId": { "type": "string" },
       "policyEpoch": { "type": "integer", "minimum": 0 },
       "revocationEpoch": { "type": "integer", "minimum": 0 },
       "monotonicCounter": { "type": "integer", "minimum": 0 },
       "timestamp": { "type": "string", "format": "date-time" }
     },
     "additionalProperties": false
   }

9.  Representative Workflows

9.1.  Agentic Tool Dispatch Workflow

   An AI agent proposes a tool call.  The proposal is converted into a
   Candidate Act and placed in a Non-Effective State.  Collection-time
   binding captures the originating model or agent identity, the
   declared tool identity, the intended schema and parameter
   commitments, the purpose, and the policy and revocation epochs.
   Execution-time validation confirms that the Candidate Act remains
   within the bound scope and produces cross-committed validation
   evidence.  A scoped non-bearer Execution Handle is issued only after
   mutual corroboration.  At the tool-dispatch boundary the Finality
   Sink reconstructs the actual tool identity, server or connector
   identity, schema, parameters, and destination, compares them with the
   protected evidence and sink-local state, and only then permits
   dispatch.  Mismatch, staleness, or missing evidence causes fail-
   closed denial and may burn the handle.

Das                     Expires 28 February 2027               [Page 18]
Internet-Draft           DAS Execution Finality              August 2026

9.2.  Memory and Retrieval Operational-Use Workflow

   A memory object, embedding, or retrieved document may be stored and
   remain readable.  High-risk operational primitives (indexing into a
   production index, injection into an agent context that can trigger
   tools, admission into a training pipeline, cross-session reuse, or
   export) remain denied until a scoped non-bearer authority artifact is
   verified for that specific primitive.  The Finality Sink reconstructs
   the requested operational use and the target of influence before
   permitting the primitive.  Readable does not mean operationally
   effective.

9.3.  Multi-Agent Delegation Workflow

   When a Candidate Act is delegated across agents, each delegation step
   is bound to a protected delegation artifact that includes delegating
   actor, receiving actor, delegated scope, permitted and prohibited
   effects, purpose, epochs, and prior artifact digests.  A downstream
   agent cannot widen, replay, substitute, or self-effectuate delegated
   authority without Finality Sink verification at the boundary where
   the delegated effect would occur.

9.4.  Cloud Control-Plane Mutation Workflow

   An AI-assisted or automated request to mutate cloud resources is held
   as a Candidate Act. Collection-time binding captures the requested
   resource identity, environment, action type, and authorization scope.
   Execution-time validation and cross-committed evidence confirm
   continued consistency with that scope.  The Finality Sink at the
   control-plane boundary reconstructs the actual resource identifier,
   environment, and mutation parameters before permitting the change.
   Stale or widened requests are denied before the control plane commits
   the mutation.

10.  Threat Model Notes and Residual Risks

   The architecture targets threats in which an upstream approval is
   valid at one time but the effectuation path is later abused through
   replay, substitution, widening, stale epochs, or compromise of an
   intermediate component that is not the Finality Sink.  It also
   targets cases in which readable data is misused for high-risk
   operational primitives without separate authority.

Das                     Expires 28 February 2027               [Page 19]
Internet-Draft           DAS Execution Finality              August 2026

   Residual risks include full compromise of every Protected Enforcement
   Domain and every Finality Sink simultaneously, physical attacks
   outside the assumed hardware root, and social or procedural bypasses
   that route an effect through an unprotected alternate path.
   Implementations MUST close alternate effectuation paths or bring them
   under equivalent Finality Sink control.

11.  Industry Relevance and Applicability

   The Decoupled Authorisation System (DAS) architecture is industrially
   applicable across multiple domains in which an AI-generated or
   automated decision can produce real-world consequence.

11.1.  Agentic AI, MCP, and Tool Ecosystems

   Teams building agentic systems at Anthropic, OpenAI, Google DeepMind,
   Microsoft, Meta, Amazon, xAI, Cohere, Mistral, and other frontier and
   enterprise AI organizations can place a Finality Sink at every tool-
   dispatch, Model Context Protocol (MCP) server, plugin, or connector
   boundary.  The sink reconstructs tool identity, schema, parameters,
   and destination before dispatch, preventing tool-supply-chain
   substitution, schema widening, and unauthorized escalation.  Memory
   and retrieval objects can remain operationally inert until a scoped
   non-bearer authority is verified for the specific operational
   primitive (indexing, context injection, training admission, etc.).

11.2.  Cloud Control Planes and DevOps / CI-CD

   Cloud resource mutations, infrastructure-as-code changes, container
   deployments, and secret accesses generated by AI agents or automation
   at Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud,
   and enterprise DevOps platforms can be held non-effective until the
   Finality Sink reconstructs the actual resource identity, environment,
   and permitted effect.  This reduces the risk of an upstream policy
   decision being widened or replayed against production.

11.3.  Financial Settlement and Digital Assets

   Payment initiation, settlement, procurement, and marketplace
   transactions proposed by AI agents can be required to pass sink-side
   reconstruction of merchant, amount, account, and contractual terms
   before funds move.  This is relevant to payment networks, digital-
   asset platforms, and financial institutions that integrate agentic
   automation.  The non-bearer property and epoch checks limit replay
   and stale-authority attacks.

Das                     Expires 28 February 2027               [Page 20]
Internet-Draft           DAS Execution Finality              August 2026

11.4.  Telecom, 5G/6G, and Network Control

   Routing instructions, network-configuration changes, and control-
   plane actions at operators and vendors in the 5G/6G and O-RAN
   ecosystem can be treated as Candidate Acts.  The Finality Sink at the
   forwarding or control boundary reconstructs the actual instruction
   and verifies it against protected evidence and sink-local state
   before the network acts.

11.5.  Cyber-Physical, Robotics, OT/ICS, and Satellites

   Actuator commands, robotic motion, industrial-control instructions,
   and satellite commands can be held non-effective until the Finality
   Sink reconstructs the actual target, command parameters, and
   permitted effect.  Atomic verify-and-effectuate primitives further
   reduce the window for substitution.  This applies to robotics,
   autonomous systems, OT/ICS/SCADA, and space-operations environments.

11.6.  Data Governance, Privacy, and Regulated Systems

   Readable data can remain operationally inert for high-risk primitives
   (export, join, training admission, cross-tenant serving) until a
   scoped non-bearer authority is verified.  This supports data-
   residency, privacy, and regulated-use constraints in healthcare,
   financial services, and other regulated industries without requiring
   every byte to be inaccessible for low-risk inspection.

12.  Security Considerations

   The architecture assumes that the Protected Enforcement Domains and
   the Finality Sink (or their critical sub-components) remain
   uncompromised under the applicable threat model.  Simultaneous
   compromise of every protected domain and every alternate effectuation
   path falls outside the claimed assurance.

   Implementations MUST enforce fail-closed behaviour.  Possession of a
   binding artifact, validation artifact, or Execution Handle MUST NOT
   be treated as sufficient authority without verification of the
   reconstructed operation, epochs, sink identity, and sink-local
   protected state.  Spent, poisoned, or revoked handles MUST be
   rejected.

   Measurement paths used for reconstruction SHOULD be attested where
   the threat model includes tampering with observation interfaces.
   Atomic verify-and- effectuate primitives are RECOMMENDED for high-
   impact effectuation boundaries.

Das                     Expires 28 February 2027               [Page 21]
Internet-Draft           DAS Execution Finality              August 2026

13.  IANA Considerations

   This document has no IANA actions.

14.  Conclusion

   Upstream approval is not effectuation.  By separating collection-time
   binding from execution-time validation, making evidence mutually
   load-bearing, issuing only scoped non-bearer finality authority, and
   requiring independent Finality Sink reconstruction of the actual
   pending operation, the Decoupled Authorisation System (DAS)
   architecture ensures that a Candidate Act becomes consequence-bearing
   only when every required condition still holds at the boundary where
   the consequence would occur.

   The result is fail-closed protection for agentic tool calls, memory
   writes, cloud mutations, financial settlements, network actions, and
   cyber-physical commands — before the unauthorized effect, not after
   it.

15.  Normative References

16.  Informative References

   [PCT-Mothership]
              Applicant, "THE DAS PROTOCOLS", PCT PCT/IB2026/055615,
              June 2026.

   [Zenodo-Authority]
              Das, S., "The Internet Solved Communication. It Never
              Solved Authority", Zenodo 10.5281/zenodo.22082995, 2026,
              <https://zenodo.org/records/22082995>.

Frequently Asked Questions (Critical Technical Concerns)

   This section addresses questions that implementers, reviewers, and
   standards participants commonly raise regarding latency, legacy
   integration, and operational practicality of the execution-finality
   architecture.

Q1.  Does Finality Sink reconstruction add unacceptable latency?

   *A.* Reconstruction cost is bounded and can be engineered to fit the
   effectuation class.  Descriptor reconstruction is not a full re-
   execution of the AI model; it is a boundary-local derivation of
   operation type, payload commitment, destination, tool identity,
   schema digest, and related fields already present at the dispatch
   interface.

Das                     Expires 28 February 2027               [Page 22]
Internet-Draft           DAS Execution Finality              August 2026

   For low-latency paths (e.g., in-process tool dispatch), the Finality
   Sink can run co-located with the dispatch boundary, reuse digests
   computed during Candidate Act formation, and perform constant-time or
   near-constant- time comparisons against pre-bound evidence.
   Cryptographic verification can use hardware acceleration (AES-NI, SHA
   extensions, HSM offload) where available.  Atomic verify-and-
   effectuate primitives further avoid a second round-trip between
   “check” and “commit.”

   High-impact effectuation classes (financial settlement, cloud
   control-plane mutation, physical actuation) already tolerate or
   require stronger checks; the added finality step is typically small
   relative to the cost of an incorrect consequence.  Implementations
   SHOULD profile sink latency per boundary class and MAY apply
   graduated finality (lighter checks for low-risk, full reconstruction
   for high-risk) without abandoning the non-effective-until-verified
   rule.

Q2.  How does this work with legacy systems that cannot host a Finality
Sink?

   *A.* Legacy effectuation endpoints need not be rewritten in full.  A
   Finality Sink can be deployed as a mediating gateway, sidecar, proxy,
   or adapter immediately in front of the legacy interface so that every
   consequence-bearing call still passes through reconstruction and
   verification.  The legacy system continues to perform its existing
   commit or dispatch logic; it simply never receives an unauthorized
   Candidate Act.

   Where mediation is impossible, a compromise path is to treat the
   legacy boundary as an intermediate hop and place the Finality Sink at
   the last controllable point before the unprotected interface,
   combined with strict network and identity controls so that no
   alternate path reaches the legacy endpoint.  Completely open,
   unmediated legacy paths remain out of scope for the strongest
   guarantees; the architecture’s value is highest when all effectuation
   paths are brought under sink control or equivalently gated.

Q3.  What is the performance impact of two-instance binding and cross-
committed evidence?

   *A.* Collection-time binding and execution-time validation can be
   pipelined with existing request handling.  Binding artifacts are
   typically small (digests, epochs, identifiers, nonces) rather than
   full payloads.  Cross-commitment is hash- and MAC-oriented and
   amortizes well across batch or streaming agent workflows.  Ledger-
   anchored receipts, where used, can be appended asynchronously for
   audit while the critical path only requires the receipts needed for

Das                     Expires 28 February 2027               [Page 23]
Internet-Draft           DAS Execution Finality              August 2026

   the current finality decision.

   The dominant cost is intentional: verification at the moment of
   effectuation.  That cost is the price of closing TOCTOU and
   substitution windows that purely upstream checks leave open.

Q4.  Why not just use existing capability tokens or OAuth-style tokens?

   *A.* Bearer and many capability tokens authorize by possession and
   are evaluated away from the final effectuation boundary.  They do not
   require independent reconstruction of the actual pending operation at
   the sink, nor mandatory consumption against sink-local monotonic
   state.  A stolen, replayed, or widened token can still drive
   effectuation.  Scoped non-bearer handles in this architecture remain
   insufficient by possession; the Finality Sink must still match the
   reconstructed operation and advance protected state.

Q5.  What happens if the Finality Sink or protected domains are
unavailable?

   *A.* The default is fail-closed: if required evidence, epochs, or
   sink verification cannot be completed, the Candidate Act remains in a
   Non-Effective State and is denied.  Operators MAY define explicit,
   narrowly scoped degraded modes (for example, human-approved emergency
   actuation under a separate protected path), but those modes must
   themselves be sink-visible and auditable.  Silent fail-open behavior
   would reintroduce the very escalation path the architecture is
   designed to close.

Q6.  Will this break interactive agent UX with many small tool calls?

   *A.* Interactive agents often issue many low-risk tool calls.
   Implementations can classify effectuation boundaries by risk and
   apply lighter finality profiles (cached scope, short-lived handles,
   co-located sinks) to low-risk classes while retaining full
   reconstruction for high-risk classes (payments, production mutations,
   external communications, credential release).  The architecture does
   not require identical latency budgets for every tool; it requires
   that no class skips the non-effective-until-verified rule without an
   explicit, controlled degradation policy.

Das                     Expires 28 February 2027               [Page 24]
Internet-Draft           DAS Execution Finality              August 2026

Q7.  How does Finality Sink work in a distributed multi-region
deployment?

   *A.* Each effectuation boundary that can produce consequence needs
   sink coverage in the region or path where the consequence occurs.
   Sinks do not require a single global coordinator for every check;
   they require local ability to reconstruct the pending operation and
   verify against protected evidence and sink-local monotonic state.
   Cross-region policy and revocation epochs can be propagated with
   standard secure distribution; the critical property is that
   effectuation does not proceed on stale local state.  Handles remain
   sink-bound or sink-class-bound so that a handle issued for region A
   is not blindly accepted in region B without explicit scope.

Q8.  How does this apply to Model Context Protocol (MCP) and plugin
servers?

   *A.* MCP servers, plugin hosts, and connector gateways are natural
   Finality Sink placement points.  Before tool dispatch, the sink
   reconstructs tool identity, server identity, declared schema,
   parameter commitments, and destination, then compares them to the
   protected evidence bound to the Candidate Act. Schema widening,
   endpoint replacement, and tool-supply-chain substitution are denied
   at the boundary rather than discovered after the tool has already
   run.

Q9.  Can streaming or partial outputs be handled without holding
everything non-effective?

   *A.* Yes, with segment-level or cumulative-budget finality.  Stream
   segments that are not yet consequence-bearing (e.g., partial text for
   display) can be released under a lighter profile, while any segment
   that would trigger a tool call, memory write, payment, or external
   commit remains a Candidate Act subject to full sink verification.
   Cumulative disclosure or effect budgets can be enforced so that many
   small releases cannot silently assemble an unauthorized high-impact
   consequence.

Q10.  Where does human approval fit?

   *A.* Human approval is modeled as a protected finality predicate, not
   as a free-floating click.  A Protected Human Approval token can be
   bound to the specific Candidate Act, predicted consequence, approver
   identity, time, and epochs, and is verified by the Finality Sink
   together with other evidence.  Stale, unbound, or replayed approvals
   do not satisfy finality.  Escalated Conditional Finality modes can
   require human approval only for elevated-risk classes while leaving
   low-risk classes on automated sink paths.

Das                     Expires 28 February 2027               [Page 25]
Internet-Draft           DAS Execution Finality              August 2026

Q11.  Does this require new cryptographic primitives or global key
infrastructure?

   *A.* No new exotic primitives are required.  Standard digests, MACs,
   signatures, monotonic counters, and optional HSM/TEE sealing suffice
   for binding, cross-commitment, and non-bearer handles.  Key
   management can follow existing enterprise or cloud KMS patterns.  The
   novelty is the placement of verification at the effectuation boundary
   and the mutual load-bearing relationship among artifacts, not a new
   public-key system.

Q12.  How does this relate to audit and compliance logging?

   *A.* Audit remains valuable but is not a substitute for pre-
   effectuation denial.  Sink-rooted evidence and Ledger-Anchored
   Validation Receipts can feed compliance logs with a high-integrity
   record that the operation effectuated (or was denied) under specific
   evidence and epochs.  The architecture prioritizes preventing
   unauthorized consequence; audit then records what the sink actually
   allowed or denied.

Q13.  Can multiple Finality Sinks be composed in a workflow?

   *A.* Yes. A pipeline may have sinks at tool dispatch, at memory
   commit, and at external egress.  Each sink governs its own boundary.
   Downstream steps can require sink-side evidence from upstream steps
   so that a later agent or tool cannot continue a workflow that was
   never finalized upstream.  Composition is by evidence chaining, not
   by collapsing all authority into one upstream decision.

Q14.  What about false denials and operational brittleness?

   *A.* Fail-closed systems can deny on missing evidence or clock/epoch
   skew.  Mitigations include careful epoch distribution, health checks
   on sink components, staged rollout by risk class, and explicit break-
   glass paths that are themselves sink-visible and heavily logged.
   Brittleness is reduced by making low-risk paths fast and co-located,
   not by silently skipping verification on high-risk paths.

Q15.  Why is this proposed as an Internet-Draft rather than only as
product architecture?

   *A.* Effectuation boundaries increasingly cross organizational and
   vendor lines (MCP servers, shared tool marketplaces, multi-cloud
   control planes, delegated agents).  Interoperable notions of
   Candidate Act, non-bearer finality handles, and sink verification
   improve safety when the component that generates the act is not the
   same as the component that effectuates it.  An Informational

Das                     Expires 28 February 2027               [Page 26]
Internet-Draft           DAS Execution Finality              August 2026

   discussion of the problem and architecture helps align implementers
   even before any protocol is standardized.

Q16.  Is a TEE or confidential VM mandatory?

   *A.* No.  TEEs and HSMs can strengthen Protected Enforcement Domains
   and sink-local state, but the architecture is defined by binding,
   cross-commitment, non-bearer handles, and boundary reconstruction—not
   by a specific hardware enclave.  Software-isolated deployments are
   possible where the threat model allows; hardware roots raise
   assurance against host compromise.

Q17.  How are replay and rollback of protected state prevented?

   *A.* Sink-local monotonic counters, spent-handle registries, and
   advancing policy/revocation epochs make reuse of old handles
   detectable.  Cross-committed receipts bind validation to a specific
   operation digest and epoch.  On denial, handles can be burned or
   poisoned.  Implementations MUST reject non-monotonic or already-
   consumed state rather than re-accepting historical approvals.

Q18.  What is explicitly out of scope for the strongest guarantees?

   *A.* Completely unmediated legacy paths that can effectuate without
   any sink, simultaneous compromise of all protected domains and sinks,
   and social/procedural bypasses that route work around technical
   controls.  The architecture reduces the technical escalation path
   from computation to consequence; it does not claim to eliminate every
   non- technical failure mode.  Operators remain responsible for
   closing alternate effectuation paths or accepting residual risk on
   those paths.

Acknowledgements

   This document is part of the broader Decoupled Authorisation System
   (DAS) Protocols body of work.

Appendix A.  Intellectual Property Disclosure — Related Applications

   The present document is technically related to subject matter
   disclosed in one or more of the following applications.  This
   statement is provided for architectural and transparency context.
   Any claim of priority is made only to the extent that the respective
   application is validly and expressly identified in the official
   filing record of a corresponding patent application.

Das                     Expires 28 February 2027               [Page 27]
Internet-Draft           DAS Execution Finality              August 2026

A.1.  Related Indian Provisional Applications

   1.   Indian Patent Application No. 202531123959, filed 9 December
        2025;

   2.   Indian Patent Application No. 202531123977, filed 9 December
        2025;

   3.   Indian Patent Application No. 202531125643, filed 12 December
        2025;

   4.   Indian Patent Application No. 202531129538, filed 20 December
        2025;

   5.   Indian Patent Application No. 202531130168, filed 22 December
        2025;

   6.   Indian Patent Application No. 202531130665, filed 23 December
        2025;

   7.   Indian Patent Application No. 202631000572, filed 3 January
        2026;

   8.   Indian Patent Application No. 202631001586, filed 7 January
        2026;

   9.   Indian Patent Application No. 202631002990, filed 12 January
        2026;

   10.  Indian Patent Application No. 202631004331, filed 16 January
        2026;

   11.  Indian Patent Application No. 202631005583, filed 20 January
        2026;

   12.  Indian Patent Application No. 202631005645, filed 20 January
        2026;

   13.  Indian Patent Application No. 202631006616, filed 22 January
        2026;

   14.  Indian Patent Application No. 202631007467, filed 26 January
        2026;

   15.  Indian Patent Application No. 202631009579, filed 30 January
        2026;

Das                     Expires 28 February 2027               [Page 28]
Internet-Draft           DAS Execution Finality              August 2026

   16.  Indian Patent Application No. 202631011216, filed 3 February
        2026;

   17.  Indian Patent Application No. 202631011630, filed 3 February
        2026;

   18.  Indian Patent Application No. 202631016797, filed 16 February
        2026;

   19.  Indian Patent Application No. 202631018571, filed 18 February
        2026;

   20.  Indian Patent Application No. 202631024957, filed 3 March 2026;

   21.  Indian Patent Application No. 202631030760, filed 14 March 2026;

   22.  Indian Patent Application No. 202631034260, filed 21 March 2026;

   23.  Indian Patent Application No. 202631035846, filed 24 March 2026;

   24.  Indian Patent Application No. 202631038227, filed 27 March 2026;

   25.  Indian Patent Application No. 202631041923, filed 1 April 2026;

   26.  Indian Patent Application No. 202631043195, filed 4 April 2026;

   27.  Indian Patent Application No. 202631043507, filed 6 April 2026;

   28.  Indian Patent Application No. 202631046689, filed 11 April 2026;

   29.  Indian Patent Application No. 202631046739, filed 12 April 2026;

   30.  Indian Patent Application No. 202631047382, filed 14 April 2026;

   31.  Indian Patent Application No. 202631049021, filed 17 April 2026;
        and

   32.  Indian Patent Application No. 202631051652, filed 23 April 2026.

A.2.  Related International (PCT) Applications

   1.   PCT/IB2026/053385, filed 7 April 2026;

   2.   PCT/IB2026/054453, filed 5 May 2026;

   3.   PCT/IB2026/055615, filed 4 June 2026 (Mothership Application);

   4.   PCT/IB2026/055760, filed 7 June 2026;

Das                     Expires 28 February 2027               [Page 29]
Internet-Draft           DAS Execution Finality              August 2026

   5.   PCT/IB2026/055870, filed 10 June 2026;

   6.   PCT/IB2026/056058, filed 13 June 2026;

   7.   PCT/IB2026/056353, filed 22 June 2026;

   8.   PCT/IB2026/056771, filed 1 July 2026;

   9.   PCT/IB2026/056809, filed 1 July 2026;

   10.  PCT/IB2026/056941, filed 6 July 2026; and

   11.  PCT/IB2026/057198, filed 12 July 2026.

A.3.  Relationship to the Mothership Application

   PCT/IB2026/055615 discloses a broader execution-finality
   architecture.  The present document develops a focused embodiment
   based on two-instance binding, cross-committed validation evidence,
   scoped non-bearer finality authority, and independent Finality Sink
   reconstruction of the actual pending operation at the effectuation
   boundary.

Author's Address

   Sangam Das
   Independent
   Balasore
   Odisha
   India
   Email: info@sangamdas.com

Das                     Expires 28 February 2027               [Page 30]