Independent

Balasore Odisha IN +91-9861363532 info@sangamdas.com

Security Individual Submission execution finality execution handle candidate act finality sink finality receipt non-bearer authority atomic consumption agentic AI Across agentic AI, payments, cloud control planes, industrial actuation, and cross-border processing, a machine can prepare a concrete operation long before that operation is allowed to become externally effective. Existing protocols already move identity, authorization data, attestation results, and signed statements. They do not, by themselves, define the small set of interoperable objects required at the effectuation boundary: a canonical Candidate Act Descriptor, a scoped non-bearer Execution Handle bound to that exact act and to a designated Finality Sink, a verify operation that reconstructs the pending effect, an atomic consume that prevents replay, and a Finality Receipt that records what was actually permitted. The residual failure is familiar and does not require token forgery. An access token, capability, session cookie, SPIFFE SVID, WIMSE credential, OAuth grant, attestation result, or signed mandate can remain cryptographically valid while being presented for a different tool call, a substituted beneficiary, a second sink, a replayed payment, a migrated region, or an alternate administrative path. Bearer possession then becomes mistaken for current, act-specific authority to effectuate. Existing mechanisms already address important adjacent problems. OAuth 2.0 and OAuth Rich Authorization Requests can express fine-grained authorization data . DPoP and certificate-bound tokens constrain sender possession . JWT and CWT carry signed claims . HTTP Message Signatures authenticate individual requests . WIMSE addresses workload identity in multi-system environments . RATS supplies Evidence and Attestation Results . SCITT supplies signed statements, transparency, and receipts . MCP and similar tool interfaces dispatch agent-selected functions. None of these objects is specified as a non-bearer, exact-act, sink-bound, single-use-or-bounded effectuation authority whose verification is serialized with protected commit. This document specifies those wire objects and the verify/consume/receipt exchange. A Candidate Act remains in a Non-Effective State until a Finality Sink reconstructs the security-relevant pending operation, verifies that a current Execution Handle authorizes that exact operation at that sink, consumes or reserves the handle according to its reuse policy, and optionally emits a Finality Receipt. The Execution Handle is not a session token and is not valid merely because the caller can present it. Prevention is claimed only when exact-act binding, sink binding, currentness, reuse policy, consequence-path coverage, and verification-to-commit serialization are load-bearing. If a deployment uses ordinary bearer tokens, advisory act identifiers, post-hoc logs, or a gateway that can be routed around, the result is mitigation or evidence rather than the same prevention guarantee. Encoding profiles are provided for JSON and COSE/CWT; the architecture requires the semantics, not one exclusive encoding. Three rejections are expected and are addressed in the body rather than dismissed here. First, a saga, 2PC, or workflow plus ordinary tokens already coordinates steps; that coordinator is complementary, and is enough only if each sink also reconstructs the live act and consumes act-bound authority. Second, atomic consume is not a process-wide lock: SINGLE_USE is per handle, COUNTED and ENVELOPE exist for high-QPS classes, and rails that already keep idempotency keys already pay this cost. Third, reconstruction is required only at the component that would first make the effect real, over fields that sink can observe — not at every mesh hop, and not as blind trust in a caller digest. Reviewers who hold any of those objections are asked to read those sections and to supply a counterexample if the residual gap is already closed. Criticism, prior art, and a recommendation to stop the work remain invited.

What This Version (-01) Contains This Internet-Draft is draft-das-execution-handle-01. It specifies the wire objects for execution finality at one Finality Sink: Candidate Act Descriptor, Execution Handle, verify, atomic consume, and Finality Receipt. Companion drafts and name the codes and the multi-sink join.

Contents of -01

• Problem, existing OAuth/DPoP/WIMSE/RATS/SCITT mechanisms, residual gap, and the handle objects.
• Formal model, hash function for the Act Digest (SHA-256 default), and bounded prevention argument.
• Pseudocode with VERIFY inside the atomic consume block and generations rechecked at commit.
• ENVELOPE identical-digest replay forbidden unless explicitly allowed.
• Anticipated criticisms (saga plus tokens, consume cost, reconstruction) and matching abstract hints.
• Industrial roadmap alignment with non-endorsement, community questions, and IETF venue mapping.
• Non-normative note on TLA+, Tamarin/ProVerif, and Alloy embeddings.

Changes from -00

• Document name and series info updated to -01.
• Abstract names the three expected rejections so reviewers do not stop at the first page.
• Verify/generation/revocation checks moved inside the atomic consume block.
• ENVELOPE default forbids identical replay.
• Hash-function and formal-verification-tool sections added.
• Family references aligned to current titles and to registries/composite -01.

Introduction

Vulnerability: A Valid Credential Can Authorize the Wrong Effect A system can authenticate a caller, verify a signature, confirm an attestation result, and accept a previously issued authorization object, yet still permit an effect that was never the authorized act. The object presented at the boundary may be authentic while the pending operation has been widened, substituted, replayed, relocated, or sent to a different sink.

Possession of a valid credential survives into the wrong effect t0 t1 t2 | | | | Authority issued for | arguments / sink / | protected | Candidate Act C17 | destination / replay | effect K | | become C18 | |--------------------------|--------------------------| | v EFFECT of C18 using authority issued for C17 If C18 is not the authorized act, a valid object at t0 MUST NOT silently authorize K at t2.

This failure does not necessarily require breaking TLS, forging a JWT, or compromising the issuer. The earlier authorization object can remain intact while the correspondence between that object and the live pending operation is lost.

Existing Mechanisms Already Address Important Parts OAuth access tokens authenticate delegated access to an API . Rich Authorization Requests can carry fine-grained authorization details such as actions, resources, and purpose . DPoP and certificate-bound access tokens reduce bearer theft by binding a token to a proof-of-possession key . JWT and CWT provide signed or encrypted claim sets . HTTP Message Signatures can authenticate a particular HTTP request . WIMSE identifies workloads across systems . RATS appraises execution environments . SCITT registers signed statements and issues receipts . Payment mandates, cloud IAM policies, and industrial permit-to-work systems already encode some form of prior approval. These mechanisms are not treated as deficient. If a deployment already binds current, exact-act, sink-specific, non-replayable authority to the actual consequence and refuses effect otherwise, it already satisfies the core property described here.

Why the Residual Gap Can Remain The residual gap appears when the object that crosses the effectuation boundary is still a permission to call an API, prove workload identity, or show that an environment was attested, rather than authority for this exact pending operation at this sink now. An OAuth token can be sender-constrained and still authorize any operation inside a broad scope. A RAR authorization-detail can describe an intended act and still be evaluated only at token issuance. A DPoP proof can show that the presenter holds a key without showing that the presented arguments are the authorized arguments. An HTTP message signature can cover the bytes on the wire without a sink-local consume record that makes a second identical request fail. A WIMSE identity can remain stable while the act changes. A RATS Attestation Result can remain valid while the model emits a different tool call. A SCITT receipt can prove that a statement was registered without making that statement a prerequisite of effectuation. Agent tool interfaces amplify the gap. A model can select payout.create, plc.write, or weights.release after a human or policy approved a different action. The dispatch path often treats a valid caller credential as sufficient to invoke the selected function.

What This Architecture Introduces The proposed contribution is a compact object set and exchange, not a new identity system and not a replacement for OAuth, WIMSE, RATS, or SCITT.

• Define a Candidate Act Descriptor (CAD) as the canonical, digestable description of the security-relevant pending operation.
• Define an Execution Handle (EH) as scoped, preferably non-bearer effectuation authority bound to that CAD digest, a Finality Sink, a reuse policy, and current generations.
• Define sink verification as reconstruction of the live pending operation and comparison with the handle, not as token presence checking.
• Define atomic consumption or reservation so that verify-then-effectuate-then-replay is not a successful protocol path.
• Define a Finality Receipt as evidence of what was verified and whether authority was consumed.
• Keep the Candidate Act non-effective until verification and the required consume step succeed.

Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Direct Question: What Threat Does This Architecture Solve? If authority H was issued for Candidate Act C17 at sink S17, what prevents H from making a different act C18 effective, or from making C17 effective a second time, or at sink S18? Authorized(H) = (C17, S17, g_now, reuse_policy) Observed(pending) = (C18, S18) NOT ExactCorrespondence(H, pending) OR NOT ConsumeSucceeds(H, pending) ==> NOT Effective(K, pending) The architecture does not decide whether C17 should have been authorized. It makes the issued authority unusable for a non-corresponding effect.

Motivating Scenario: Approved Payout, Substituted Beneficiary An enterprise agent is permitted to pay a vendor. A Protected Enforcement Domain evaluates the instruction and issues an Execution Handle bound to payer account A, amount 500.00 EUR, beneficiary IBAN-X, rail SEPA_INSTANT, and settlement sink core-post-eu-1. Before the post, a prompt-injected tool argument or a compromised worker replaces IBAN-X with IBAN-Y, or sends the same handle to a second PSP sink. The caller still possesses a valid handle and a valid workload credential.

Valid handle presented for a substituted settlement act PED issues EH(C17) | v +-------------+ +------------------+ | Agent / API |--->| Candidate C17 | | | | pay 500 to X | +-------------+ +--------+---------+ | argument substitution or second sink | v +-------------+ | pending C18 | | pay 500 to Y| +------+------+ | v [ Settlement Sink ] | reconstruct pending compare to EH(C17) / \ no yes | | REJECT consume + post

The same pattern appears in tool dispatch (approved search, live payout.create), OT actuation (approved setpoint, live coil write), and model-release (approved summary, live weight dump). The wire objects are shared; the consequence class is a profile input.

Problem Space

An Access Token Is Not an Execution Handle An access token typically answers "may this principal use this API under this scope?" An Execution Handle answers "may this exact pending operation become effective at this sink under current generations and reuse policy?"

Proof of Possession Is Not Exact-Act Binding Sender-constraining a token to a key prevents some theft cases. It does not bind the token to the digest of the live arguments, destination, rail, coil, or recipient.

A Request Signature Is Not Atomic Consumption Signing the request authenticates one presentation. Without sink-local monotonic state, the same signed request, or a second request under the same authority, can still complete more than once.

Attestation Is Not Effectuation Authority An Attestation Result can establish that a GPU, TEE, or confidential VM matches expected measurements. It does not authorize a particular subsequent tool call, payment, or actuation.

A Transparency Receipt Is Not a Permit to Effectuate SCITT can prove that a statement was signed and registered. Registration does not by itself make the statement a load-bearing precondition of the external effect.

Threat Model and Assurance Scope

Adversary Capabilities The adversary MAY control or influence the requester, AI agent, prompt, retrieved context, tool-router, application process, ordinary operating system, worker queue, service-mesh route, unprotected argument fields, log redaction, or an alternate administrative path outside the declared Finality Sink. The adversary MAY replay an Execution Handle, present it at another sink, substitute CAD fields after issuance, fragment one effect into several smaller acts, suppress consume records, crash between verify and commit, or attach a valid handle to a different Candidate Act that shares a session or workload identity.

Threat Severity and Applicability Severity is consequence-dependent. The issue deserves high attention for financial settlement, industrial actuation, RF transmit enablement, model-weight or secret release, cross-border disclosure, child-reachable rendering, cloud control-plane mutation, and other irreversible or high-impact effects. The same objects can be used for lower-risk operations, but a cacheable read of public data should not be forced through single-use consume semantics unless the deployment chooses that profile.

Baseline Handle Profile The requester, agent, ordinary network, and unprotected caches are untrusted. The handle issuer / Protected Enforcement Domain, the Finality Sink, cryptographic verification roots, and the consume-state store are trusted.

High-Assurance Handle Profile A higher-assurance profile MAY additionally distrust the host operating system, orchestrator, tool server, or application runtime. Handle verification, consume-state, and protected commit must then be anchored in a domain those components cannot rewrite or bypass, such as a TEE, HSM, DPU/SmartNIC, independent settlement core, or hardware-isolated sink.

Trusted Roots and Limits The base model assumes the issuer and sink are honest with respect to their declared roles, that consume-state is monotonic for the reuse policy in force, and that every path capable of producing the protected consequence crosses an equivalent sink. Full compromise of issuer and sink, or effectuation outside the declared consequence domain, is outside the base prevention claim.

Design Goals and Non-Goals The design goal is to make exact-act effectuation authority current, sink-bound, reconstructable, consumable, testable, and receivable at the consequence boundary. This document does not replace OAuth, create a new login protocol, replace WIMSE workload identity, replace RATS, replace SCITT, define which acts should be authorized, determine applicable law, or require every implementation to use a single token syntax. A profile MAY encode the Execution Handle as a CWT, a detached COSE signature over a CAD digest, a JWT, a protected local capability, or another representation. The architecture requires the semantics in .

Existing Mechanisms and the Proposed Delta

OAuth Access Tokens and RAR OAuth tokens and RAR authorization details can express who may do what class of operation on which resource . This document does not claim that fine-grained authorization data is new. The residual question is whether the object presented at effectuation is still bound to the live act, the live sink, and a consume record.

DPoP and Certificate-Bound Tokens Sender-constrained tokens reduce presentation by a thief who lacks the bound key . They do not by themselves digest the pending operation or consume authority at a designated sink.

HTTP Message Signatures RFC 9421 can cover selected request components . A profile MAY use HTTP Message Signatures to authenticate a verify request. Signature validity is not a substitute for CAD correspondence or atomic consume.

WIMSE, RATS, and SCITT WIMSE identifies the acting workload. RATS appraises the environment. SCITT can register policy, CAD hashes, or receipts. Each is an input or an evidence channel. None is specified here as the Execution Handle.

Comparison Summary Existing mechanism and residual effectuation question

Mechanism	Strong existing property	Residual question only where not already enforced
OAuth access token	Delegated API access	Does the token authorize this exact pending act at this sink once?
OAuth RAR	Fine-grained authorization data	Is that data re-bound to the live arguments at commit?
DPoP / cert-bound token	Sender constraint	Is the sender-constrained object also act- and sink-bound?
JWT / CWT	Signed claims container	Which claims are load-bearing for effectuation and consume?
HTTP Message Signatures	Request authentication	Is there sink-local consume state after a valid signature?
WIMSE	Workload identity	Does this workload's current act match the issued handle?
RATS	Environment appraisal	Is the Attestation Result being used as a substitute for act authority?
SCITT receipt	Registered signed statement	Is registration a permit to effectuate, or only evidence?

What Is New in This Document The proposed contribution is the composed wire invariant, not any single encoding. Valid credential for principal P != authority for pending act C at sink S For protected act C: EH binds H(C), S, generations, reuse AND sink reconstructs C_now AND Consume(H, C_now, S) succeeds immediately before or atomically with effectuation.

Terminology Candidate Act: A proposed consequence-bearing operation that has been prepared but has not yet been permitted to become externally effective. Candidate Act Descriptor (CAD): The canonical, security-relevant description of a Candidate Act used for digesting, issuance, and sink reconstruction. Act Digest: A cryptographic digest over the canonical CAD fields that the deployment treats as load-bearing. Execution Handle (EH): Scoped effectuation authority bound to an Act Digest, a Finality Sink, current generations, and a reuse policy. Possession alone is not sufficient. Protected Enforcement Domain (PED): The function that evaluates act-specific predicates and issues or refuses an Execution Handle. Finality Sink: The protected functional boundary where the Candidate Act would first become externally effective and where verify/consume occurs. Non-Effective State: A state in which the Candidate Act cannot yet produce the protected consequence. Consume: The sink-local state transition that records use of an Execution Handle according to its reuse policy, atomically with or immediately before protected commit. Finality Receipt: A signed or otherwise protected record that a named sink verified a named Act Digest, applied a consume outcome, and did or did not permit effectuation. Reuse Policy: The rule governing whether a handle is single-use, bounded-use, or envelope-use inside an explicit hot-path envelope.

Object Model Five objects are defined. Implementations MAY physically merge some of them, but the semantic roles MUST remain distinguishable. CAD --digest--> ActDigest | v PED | v EH --------+ | pending live operation | | | v v reconstructed CAD [ Finality Sink ] | | +-----------compare-----+ | consume state | v effect + Receipt

Candidate Act Descriptor A CAD contains the fields that, if changed, would change the authorization question. Profiles select required fields by consequence class. Fields that are not security-relevant for the profile MUST NOT be included in the Act Digest.

Core Fields CAD = { version, object_type: "candidate_act", candidate_act_id, act_type, consequence_class, created_at, expires_at, actor, ; workload / agent / principal reference operation, ; tool, function, instruction type arguments_digest, ; digest of canonical arguments destination, ; resource, payee, coil, recipient, URL class purpose, ; if purpose-sensitive jurisdiction_policy_id, ; if jurisdiction-sensitive finality_sink, policy_generation, freshness, parent_act_id, ; optional composition extensions } candidate_act_id identifies the instance. arguments_digest covers the canonical argument encoding, not a mutable presentation copy. finality_sink names the sink that is allowed to consume the eventual handle.

Canonicalization and Act Digest An implementation MUST define a deterministic canonicalization for digest input. JSON profiles SHOULD use JCS or an explicitly declared equivalent. CBOR profiles SHOULD use deterministic CBOR encoding . ActDigest = H( Canonical(CAD_load_bearing_fields) ) H is a collision-resistant hash identified in the digest object. The sink MUST recompute the digest from observed or reconstructed fields. It MUST NOT trust a caller-supplied digest as the sole correspondence check.

Hash Function for the Act Digest Hash in d(C) = Hash(Canon(CAD(C)|F)) is a collision-resistant cryptographic hash, not a checksum and not an encryption function. Its only jobs in this protocol are: (1) make two CADs with different load-bearing fields produce different digests except with negligible probability; (2) give the handle a fixed-size binding that can be compared in the atomic consume step. d(C) = Hash( Canon( fields_F(C) ) ) Collision resistance used by the bounded argument: if fields_F(C17) != fields_F(C18) then Pr[ d(C17) = d(C18) ] is negligible. Therefore: H issued for C17 and sink observes C18 => d(C18) != H.d => VERIFY fails with EF-023 Hash does NOT provide: confidentiality of arguments policy correctness sender authentication (that is sigma / key-binding) freshness by itself (that is g and t_exp) JSON profiles SHOULD identify the algorithm as SHA-256 unless the profile declares another collision-resistant function. The digest object MUST name the algorithm so two implementations do not silently hash with different functions. SHA-1 and non-cryptographic checksums (CRC, CityHash) MUST NOT be used for d(C). Collision-resistant unkeyed hashes such as BLAKE2b and BLAKE3 MAY be used if the profile names them. Canonicalization happens *before* the hash. Hashing a different JSON serialization of the same fields is a correspondence bug, not a hash-function bug. That is why JCS or deterministic CBOR is required. Privacy: if F has low entropy (small amount set, small beneficiary set), d(C) can be brute-forced offline. Profiles for those classes SHOULD include a per-act nonce in F, or SHOULD treat the digest as sensitive in receipts sent off-path. A hash does not hide a guessable act.

Illustrative JSON CAD { "version": "1.0", "object_type": "candidate_act", "candidate_act_id": "urn:example:act:7f3c", "act_type": "PAYMENT_POST", "consequence_class": "FINANCIAL", "created_at": "2026-09-16T16:01:00Z", "expires_at": "2026-09-16T16:11:00Z", "actor": { "workload_id": "spiffe://example/agent-pay" }, "operation": { "tool_id": "payout.create", "function_id": "create" }, "arguments_digest": { "algorithm": "SHA-256", "value": "base64url-digest-of-canonical-args" }, "destination": { "beneficiary_id": "iban:X", "rail": "SEPA_INSTANT" }, "finality_sink": { "sink_id": "core-post-eu-1", "sink_type": "SETTLEMENT" }, "policy_generation": "pg-441", "freshness": { "nonce": "n-19", "not_before": "2026-09-16T16:01:00Z" } }

Execution Handle An Execution Handle is issued only after PED validation of the CAD. It is authority to complete verification at a named sink, not a general API credential.

Required Semantic Fields EH = { version, object_type: "execution_handle", handle_id, issuer, issued_at, expires_at, act_digest, candidate_act_id, finality_sink_id, reuse_policy, ; SINGLE_USE | COUNTED | ENVELOPE max_uses, ; if COUNTED envelope, ; if ENVELOPE: bounded field ranges generations, ; policy, revocation, topology, context confirmation_method, ; how the sink proves correspondence not_bearer_alone, ; true in the strict profile key_binding, ; optional PoP key extensions }

Non-Bearer Rule In the strict profile, presenting EH is never sufficient. The sink MUST additionally establish at least:

1. correspondence between EH.act_digest and the reconstructed pending CAD;
2. correspondence between EH.finality_sink_id and the verifying sink;
3. currentness of required generations;
4. success of the reuse/consume rule;
5. any required key-binding or workload-binding proof.

A profile MAY add sender key-binding. Key-binding WITHOUT act digest and sink binding is DPoP-class mitigation, not an Execution Handle in the sense of this document.

Reuse Policy SINGLE_USE: first successful consume wins; later presentations fail with AUTHORITY_ALREADY_USED. COUNTED: consume increments a protected counter; fail when count would exceed max_uses. ENVELOPE: handle authorizes repeated acts only while each live CAD remains inside an explicit bounded envelope. Identical replay of the same act digest is FORBIDDEN unless the envelope textually sets allow_identical_replay. Envelope reuse MUST NOT be used to smuggle a changed destination, amount, coil, recipient, or consequence class. Those fields are outside the envelope by default unless the envelope textually includes them. Identical replay defaults to forbidden so that ENVELOPE cannot become an unbounded bearer replay window.

Sink Verification, Consume, and Receipt

Verify Verify is performed by the Finality Sink, not by the caller. The sink reconstructs the pending operation from sink-local observation where possible. VERIFY(pending, EH) = handle_integrity_valid(EH) AND handle_not_expired(EH) AND sink_id_matches(EH, this_sink) AND act_digest_matches(EH, reconstruct(pending)) AND generations_current(EH) AND workload_binding_ok_if_required(EH, pending) AND pop_ok_if_required(EH, pending) AND reuse_state_allows(EH) Failure codes in are illustrative pending registry action.

Atomic Consume For SINGLE_USE and COUNTED handles, consume MUST be serialized with protected commit so that the following history is not a successful protocol: Verify(EH, C) success | v Effect(K) | v Replay(EH, C) success <-- forbidden The required ordering is: atomic { assert VERIFY(pending, EH) // includes generations CONSUME(EH) COMMIT(pending) } VERIFY outside this block is only a hint. Generations, digest, sink, and pending correspondence MUST be re-evaluated inside the block. A revocation or generation change that lands after an out-of-block verify and before commit MUST fail (EF-041 or EF-062), not commit. If the platform cannot provide a single atomic section, it MUST provide crash recovery that cannot complete a second effect from the same SINGLE_USE handle, and it MUST re-run VERIFY immediately before consume. An implementation that verifies once outside the block and only rechecks consume-state inside it does not meet this document, because that path admits a revocation between verify and commit.

Finality Receipt A Finality Receipt records the sink's decision. It is evidence, not a new handle. A receipt MUST NOT be presented in place of an Execution Handle to authorize a further effect unless a profile explicitly defines receipt-to-handle derivation, which this document does not. Receipt = { object_type: "finality_receipt", receipt_id, sink_id, handle_id, candidate_act_id, act_digest, decision, ; EFFECTUATED | REJECTED ; PREPARED | ABORTED are composite-child ; decisions (prepare / abort reserve), ; not a second handle. See DAS-COMPOSITE. consume_outcome, ; CONSUMED | RESERVED | RELEASED ; | UNCHANGED | FAILED reason_code, ; if REJECTED generations_observed, issued_at } A profile MAY register receipts with SCITT . Transparency of the receipt does not replace sink verification of a later act.

State Machine

Handle lifecycle from Candidate Act to receipt +----------------+ | CANDIDATE ACT | | NON-EFFECTIVE | +-------+--------+ | v +-------------------------+ | PED validates predicates| | issues EH or refuses | +------------+------------+ | issued EH | v +-------------------------+ | PRESENT AT SINK | | reconstruct pending CAD | +------------+------------+ | v +-------------------------+ | VERIFY | +------+-------------+----+ | | fail pass | | v v RECEIPT CONSUME + COMMIT REJECTED | v RECEIPT EFFECTUATED

Formal Model Let C be the Candidate Act, CAD(C) its descriptor, H an Execution Handle, S the verifying sink, K the protected consequence, and Store the sink-local consume state. The identities below are the same rules as the later pseudocode, written so that a substitution or a verify/consume race can be named. Let Fields(C) be the load-bearing field set of profile pi. Let Canon be the profile canonicalization. d(C) = Hash( Canon( CAD(C) | Fields(C) ) ) H = ( id, d(C), S, g, rho, t_exp, sigma ) where g is the generation vector, rho in {SINGLE_USE, COUNTED, ENVELOPE}, sigma is the issuer authenticator, and t_exp is expiry. Possession(caller, H) is not a predicate of authority: Auth(H, C', S', g_now, Store, t) iff VerifySig(H.sigma) and t < H.t_exp and d(C') = H.d and S' = H.S and Current(H.g, g_now) and ConsumeOK(H, Store, C') Effect(K, C', S', t) iff Auth(H, C', S', g_now(t), Store, t) and Commit(S', C', t) and PathCovered(K, S') Prevention (bounded): not Auth(...) => not Effect(K, C', S', t) Race constraint (verify must be inside the atomic step): let t_v < t_c be verify time and consume time. if g_now(t_c) != g_now(t_v) or Revoked(H, t_c) then Consume at t_c MUST fail. i.e. Auth uses g_now(t_c), not g_now(t_v). ENVELOPE replay default: ReplayRuleOK(H, C', Store) iff InsideEnvelope(C', H.envelope) and ( d(C') notin UsedDigests(Store, H) or H.envelope.allow_identical_replay = true ) Issued(H, C, S) := PEDValidated(C) AND H.act_digest == Digest(CAD(C)) AND H.finality_sink_id == S.id AND HandleIntegrityValid(H) Corresponds(H, C_now, S_now) := Issued(H, C_iss, S_iss) AND Digest(CAD(C_now)) == H.act_digest AND S_now.id == H.finality_sink_id AND GenerationsCurrent(H) AND NotExpired(H) ConsumeOK(H, Store) := case H.reuse_policy of SINGLE_USE => Store[H.id] == UNUSED COUNTED => Store[H.id].count < H.max_uses ENVELOPE => InsideEnvelope(C_now, H.envelope) AND ReplayRuleOK(H, C_now, Store) Effective(K, C_now) ==> Corresponds(H, C_now, S_now) AND ConsumeOK(H, Store) AND ProtectedCommit(S_now, C_now) AND PathCovered(K, S_now) Strict prevention: NOT Corresponds(H, C_now, S_now) OR NOT ConsumeOK(H, Store) ==> NOT Effective(K, C_now)

Bounded Prevention Argument Assume: (1) every load-bearing field of C is in CAD and therefore in the Act Digest; (2) the sink reconstructs those fields from the pending effect rather than trusting the caller digest alone; (3) consume-state is monotonic and crash-safe for the reuse policy; (4) verification and commit are serialized against consume-state updates; and (5) every technically viable path to K crosses an equivalent sink. Suppose K becomes effective for C18 using H issued for C17, or a second K is produced from a SINGLE_USE H. Then either Digest(CAD(C18)) equals Digest(CAD(C17)) while the security-relevant fields differ, contradicting collision resistance and canonicalization, or consume-state allowed a second use, contradicting monotonic consume, or a path bypassed the sink, contradicting path coverage. The argument establishes only enforcement of the issued handle semantics; it does not prove that the PED decision was a good policy decision.

Formal Verification Tools (Non-Normative) This document is an Internet-Draft, not a machine-checked development. The identities in the formal model are written so they can be transcribed into existing tools. No tool is required to implement a sink. A checked model is useful when a reviewer disputes the verify/consume race or the ENVELOPE replay default. Suggested embeddings:

• TLA+ / PlusCal: encode Store, q in {UNUSED, USED, COUNTED(n), PREPARED}, and the atomic action VerifyConsumeCommit as one TLA+ action. Invariants: SINGLE_USE handle produces at most one EFFECTUATED; generations sampled inside the action equal g_now at commit; a revoked handle never commits.
• Tamarin or ProVerif: treat H.sigma as a signature, d(C) as a hash query, and Effect as an event. Correspondence lemma: Effect(C',S') occurs only if Issued(H,C,S) with d(C')=d(C) and S'=S.
• Alloy or Quint: small-scope check that two workers cannot both observe UNUSED and both commit.

TLA+ invariant (SINGLE_USE): []( Cardinality({ k : Effectuated(H, k) }) <= 1 ) Tamarin-style correspondence: Effect(C', S') ==> Ex H, C. Issued(H, C, S') & d(C') = d(C) & not Revoked(H) These lemmas are the same claims as the pseudocode in consume_and_commit. A counterexample in TLA+ would be a protocol bug; a counterexample only in a mis-written spec would not. Composite join is the part that most benefits from TLA+: the COMMIT-then-crash-then-TTL-abort path is exactly the split state EF-047. A model that allows that path under PreventionWellFormed is wrong.

Encoding Profiles This section is non-normative as to exclusive syntax. An interoperable profile MUST declare one encoding and one canonicalization.

JSON Profile CAD, EH, verify request/response, and receipts MAY be JSON objects. Digests use JCS over the declared load-bearing subset. HTTP deployments MAY carry EH in an Authorization header of the form: Authorization: EFHandle <base64url(EH)> EF-Act-Digest: sha-256=<base64url> The header names above are illustrative. A later revision or companion registry draft may request permanent field names.

COSE / CWT Profile An Execution Handle MAY be a CWT whose claims include act digest, sink identifier, reuse policy, generations, and expiry. The CWT MAY be sender-constrained by a confirmation claim, but confirmation does not replace act digest or sink identifier. A Finality Receipt MAY be a COSE_Sign1 object over the receipt fields, optionally registered in a SCITT Transparency Service .

Illustrative HTTP Binding The following exchange is illustrative for an HTTPS sink. MCP, industrial buses, and settlement cores can map the same verbs onto their native transports. POST /finality/verify-and-commit Content-Type: application/ef-pending+json Authorization: EFHandle ... { "pending": { ... observed operation fields ... }, "handle": { ... EH or handle reference ... }, "nonce": "n-88" } 201 Content-Type: application/ef-receipt+json { "object_type": "finality_receipt", "decision": "EFFECTUATED", "consume_outcome": "CONSUMED", "act_digest": "...", "handle_id": "...", "sink_id": "core-post-eu-1" } A sink MAY separate verify from commit only if consume-state prevents a second commit. Soft-verify without consume MUST NOT be treated as permission to effectuate.

Failure Codes The following codes are illustrative and are not IANA assignments. A companion registry draft should own the stable namespace. EF-002 NO_FINALITY_AUTHORITY EF-003 HANDLE_INTEGRITY_FAILURE EF-004 HANDLE_EXPIRED EF-005 AUTHORITY_ALREADY_USED EF-006 REPLAY_DETECTED EF-012 SCOPE_MISMATCH EF-020 DESTINATION_MISMATCH EF-023 ACT_DIGEST_MISMATCH EF-040 SINK_MISMATCH EF-041 GENERATION_STALE EF-042 REUSE_POLICY_VIOLATION EF-043 ENVELOPE_EXCEEDED EF-062 REVOCATION_ACTIVE EF-070 ESCALATION_REQUIRED EF-080 FAIL_CLOSED EF-081 CONSUME_STATE_UNAVAILABLE A strict prevention profile MUST fail closed when consume-state is unavailable (EF-081), rather than treating missing state as unused.

Illustrative Pseudocode The following pseudocode is non-normative. It separates CAD construction, digesting, issuance, reconstruction, verify, consume, commit, receipt, crash recovery, and envelope reuse.

Construct and Digest a Candidate Act function make_cad(pending): fields = security_relevant_fields(pending) cad = { version: "1.0", object_type: "candidate_act", candidate_act_id: new_id(), act_type: fields.act_type, consequence_class: fields.consequence_class, actor: fields.actor, operation: fields.operation, arguments_digest: digest(canonicalize(fields.arguments)), destination: fields.destination, finality_sink: fields.finality_sink, policy_generation: current_policy_generation(), freshness: { nonce: new_nonce(), not_before: now() }, created_at: now(), expires_at: now() + pending.ttl } cad.act_digest = digest(canonicalize(load_bearing(cad))) return cad

Issue an Execution Handle function issue_handle(cad, policy): if !verify_cad_integrity(cad): reject("EF-003") if !ped_predicates_satisfied(cad, policy): reject("EF-002") if cad.expires_at <= now(): reject("EF-004") eh = { object_type: "execution_handle", handle_id: new_id(), issuer: ped_id(), issued_at: now(), expires_at: min(cad.expires_at, policy.handle_ttl), act_digest: cad.act_digest, candidate_act_id: cad.candidate_act_id, finality_sink_id: cad.finality_sink.sink_id, reuse_policy: policy.reuse_policy_for(cad), generations: current_generation_vector(), not_bearer_alone: TRUE } return sign_or_mac(eh, ped_key())

Reconstruct the Pending Act at the Sink function reconstruct_pending(observed): # Prefer sink-local observation of the effect about to occur. # Do not accept caller CAD as authoritative if the sink can # see the live operation fields. live = { act_type: observed.act_type, operation: observed.operation, arguments: observed.arguments, destination: observed.destination, actor: observed.actor_if_known } cad_now = make_cad_from_live(live) return cad_now

Verify Handle Against Reconstructed Act function verify_handle(eh, cad_now, sink): if !verify_signed(eh, trusted_issuers()): return FAIL("EF-003") if eh.expires_at <= now(): return FAIL("EF-004") if eh.finality_sink_id != sink.id: return FAIL("EF-040") if eh.act_digest != cad_now.act_digest: return FAIL("EF-023") if !generations_current(eh.generations): return FAIL("EF-041") if eh.key_binding and !proof_of_possession(eh): return FAIL("EF-012") return PASS

Consume and Commit function reject(code): write_receipt(REJECTED, code) remain_non_effective() return REJECTED function consume_and_commit(eh, cad_now, sink, pending): begin_protected_finality_section() atomic { # VERIFY is inside the block so revocation / # generation change after a speculative check # cannot commit. result = verify_handle(eh, cad_now, sink) if result != PASS: return reject(result.code) if !generations_current(eh.generations): return reject("EF-041") if revoked(eh): return reject("EF-062") if eh.act_digest != cad_now.act_digest: return reject("EF-023") state = consume_store.get(eh.handle_id) if eh.reuse_policy == SINGLE_USE: if state != UNUSED: return reject("EF-005") consume_store.put(eh.handle_id, USED) else if eh.reuse_policy == COUNTED: if state.count >= eh.max_uses: return reject("EF-005") consume_store.put(eh.handle_id, state.count + 1) else if eh.reuse_policy == ENVELOPE: if !inside_envelope(cad_now, eh.envelope): return reject("EF-043") if replayed_identical_act(eh, cad_now) and not eh.envelope.allow_identical_replay: return reject("EF-006") record_envelope_use(eh, cad_now) assert exact_observed_effect_still_matches( pending, cad_now) commit_protected_effect(pending) } write_receipt(EFFECTUATED, CONSUMED) return EFFECT_COMMITTED

Crash-Safe Recovery function recover(handle_id, candidate_id): commit_state = protected_commit_state(candidate_id) consume_state = consume_store.get(handle_id) if commit_state == EFFECTIVE: return DO_NOT_REPLAY if commit_state == COMMITTING: outcome = resolve_atomic_commit(candidate_id) if outcome == EFFECT_COMMITTED: return DO_NOT_REPLAY return REVERIFY_AND_RESUME_OR_FAIL_CLOSED if consume_state == USED and commit_state != EFFECTIVE: # consume happened; effect uncertain return RESOLVE_FROM_SINK_LOG_OR_FAIL_CLOSED return REVERIFY_CURRENT

Forward a Handle Reference Across Hops function forward_to_next_workload(cad, eh, next): envelope = { candidate_act_id: cad.candidate_act_id, act_digest: cad.act_digest, handle_reference: reference_for(eh), sink_id: eh.finality_sink_id, generations: eh.generations } return authenticated_forward(next, envelope) # Downstream MUST NOT treat the forwarded reference as current # authority. Only the named Finality Sink consumes.

Emit a Finality Receipt function write_receipt(decision, consume_outcome, eh, cad_now, code): receipt = { object_type: "finality_receipt", receipt_id: new_id(), sink_id: this_sink.id, handle_id: eh.handle_id, candidate_act_id: cad_now.candidate_act_id, act_digest: cad_now.act_digest, decision: decision, consume_outcome: consume_outcome, reason_code: code, generations_observed: current_generation_vector(), issued_at: now() } signed = sign_or_mac(receipt, sink_key()) store_local(signed) optionally_register_scitt(signed) return signed

Composition with Existing Protocols

OAuth An access token MAY authenticate the caller to the PED or to the sink transport. It MUST NOT be treated as the Execution Handle unless it carries every required handle field and the sink applies verify/consume semantics. RAR authorization details MAY populate CAD fields at issuance time; the sink still reconstructs the live act.

WIMSE WIMSE credentials can populate CAD.actor and EH workload binding . Stable workload identity does not imply a stable act. The handle remains bound to ActDigest, not only to the workload identifier.

Workload identity can remain stable while the pending act changes WIMSE identity: workload://tenant/agent-pay | | remains stable v +----------+ | Workload | +----+-----+ | +---------+----------+ | | v v CAD C17 CAD C18 pay vendor X pay vendor Y Same identity, different ActDigest, different EH requirement.

RATS An Attestation Result MAY be a PED input that the environment is acceptable . It is not an Execution Handle. A profile MAY include an attestation-result digest among CAD freshness or trust fields when environment currentness is load-bearing for the act.

SCITT SCITT can register jurisdiction or purpose policy, CAD hashes, issuer public keys, or Finality Receipts . A SCITT receipt for policy registration does not authorize effectuation of C.

MCP and Tool Dispatch For tool interfaces, the Finality Sink is the component that would otherwise invoke the selected function. The CAD operation fields identify tool and function. The arguments_digest covers canonical tool arguments. Dispatch without verify/consume is an alternate path if that dispatch can produce the same external effect.

Consequence-Path Completeness Handle verification at one API is insufficient when another route can produce the same consequence. A prevention profile composes with consequence-path completeness.

Valid handle path beside an unmediated alternate path Normal path: C -> PED -> EH -> Sink verify/consume -> K Alternate path: C -> raw API key / admin console / replica worker ------> K If the alternate path can produce K without equivalent verify/consume, the deployment cannot claim prevention.

Attack Analysis

Argument or Destination Substitution Live arguments change after issuance. Reconstructed ActDigest diverges and verify fails with EF-023 or EF-020.

Handle Replay The same SINGLE_USE handle is presented again. Consume state returns EF-005 or EF-006.

Cross-Sink Presentation A handle issued for sink S17 is sent to S18. Sink binding fails with EF-040.

Stolen Handle Without Live Correspondence Theft of a handle object does not authorize an arbitrary act. The thief must also cause the sink to observe a pending operation matching the bound digest. If they can do that through an unmediated path, the failure is path coverage, not handle syntax.

Act Fragmentation An adversary splits one prohibited 10,000 payment into twenty 500 payments under an envelope. Envelope profiles MUST bind amount ceilings, destination sets, and aggregation rules if fragmentation is in the threat model.

Verify-Then-Effect-Then-Replay Without atomic consume, two workers can both observe UNUSED and both commit. Serialization or compare-and-swap on consume-state is required.

Crash Between Consume and Commit Recovery must not reopen a SINGLE_USE handle after consume, and must not leave an effect without a consume record if the platform later treats UNUSED as authorizable.

Receipt Presented as Authority A prior EFFECTUATED receipt is replayed as if it were a new handle. Sinks MUST reject receipts in the handle slot.

Deployment Patterns

Inline Sink The component that would emit the external effect implements verify/consume itself. This is the preferred prevention placement.

Organization Egress Sink When the external service will not implement handles, the deploying organization places the sink at its own egress and forwards only after consume. Residual risk is any other path that can reach the same external effect.

Hot-Path Envelope Repeated low-risk calls inside a fixed envelope MAY reuse one handle. The sink check remains mandatory. Crossing the envelope is a new Candidate Act.

Industrial Relevance and Public-Roadmap Alignment Public product roadmaps already move identity, tool connectivity, sovereign-cloud residency, confidential-compute attestation, and agent governance forward. This section records only that complementary relationship. It does not assert that any named company has a gap, has adopted this architecture, plans to adopt it, or should adopt it. Where a vendor system already reconstructs the live act, binds authority to that act and sink, consumes reuse state, and refuses effect otherwise, that deployment already satisfies the core property.

How This Section Must Be Read Named companies, products, foundations, and protocols appear only as documented public surfaces on which an Execution Handle could be composed. They are not accused of vulnerability, deficiency, non-conformance, incomplete security, or inadequate governance. They are not described as partners, customers, or implementers of this Internet-Draft. Roadmap language below is limited to what the cited public materials already state. Readers who work at those organizations are asked to correct any mis-statement of their public position. Public roadmap object Complementary handle question ------------------------- ----------------------------------------- MCP tool listing / call Is tools/call the live CAD, or only a name? Copilot / agent connector Does the connector credential authorize this exact pending invoke? Sovereign cloud / EU boundary Is the current effectuation context still the one the handle was issued under? GPU / Realm attestation Is the Attestation Result an input to PED issuance, or a substitute for the handle? PSP / rail API token Does the token authorize this beneficiary, amount, rail, and sink once? Egress / API gateway Can the same K occur on a path that never verifies or consumes a handle?

Agent Tool Connectivity: MCP and Copilot-Class Platforms Anthropic published the Model Context Protocol as an open interface for connecting models to tools and data . OpenAI, Google DeepMind, Microsoft, AWS, and others have publicly described MCP support in agent products. Microsoft documents MCP integration in Copilot Studio, including tool listing and connector-mediated enterprise controls . Anthropic later donated MCP to the Linux Foundation Agentic AI Foundation with public support from additional industry participants . Those roadmaps address connectivity, discovery, and (in some products) caller authentication and data-loss-prevention at the connector. They do not, in the cited materials, define a non-bearer Execution Handle bound to a reconstructed live argument digest, a designated dispatch sink, and atomic consume. The composition is therefore: MCP / Copilot / Agents SDK "which tools exist and how is the caller authenticated?" | v PED + Execution Handle "is THIS reconstructed tools/call the authorized act?" | v dispatch sink verify / consume | v external tool effect If an MCP server, Copilot connector, or agent runtime already performs that exact-act verify/consume step, this draft adds only vocabulary. If it does not, the draft is a candidate profile, not a claim that the product is unsafe.

Cloud Identity, IAM, and WIMSE-Shaped Workload Credentials Microsoft Entra, AWS IAM, and Google Cloud workload identity already issue principal and workload credentials at planetary scale. WIMSE is standardizing workload identity across multi-system environments with active industry participation . Those systems answer "which workload is acting?" An Execution Handle answers a later question: whether the current pending operation of that workload is the authorized operation at this sink. A stable Azure managed identity, AWS role, or SPIFFE ID can outlive the act it was thought to cover. Composition is additive: Cloud IAM / WIMSE / SPIFFE "who is the workload?" | v Execution Handle "what exact act may become effective, where, how many times?"

Sovereign Cloud and Data-Boundary Roadmaps Microsoft documents the EU Data Boundary and continuing-transfer cases . AWS documents the European Sovereign Cloud . Google Cloud documents partner-operated Sovereign Controls including residency, external key management, and local supervision . Those roadmaps supply residency, operator, and key-control dimensions. They are natural inputs to CAD fields and to jurisdiction-bound finality . They are not replaced by an Execution Handle. The handle only makes the current permitted context a load-bearing condition of the specific act that is about to commit.

Confidential Compute and Accelerator Attestation NVIDIA documents local and remote GPU and NVSwitch attestation . Arm documents the Confidential Compute Architecture and Realm attestation . Cloud providers similarly document confidential VMs and attested GPU attachments. Those roadmaps establish technical trust in hardware, firmware, and isolation state. An Attestation Result remains an input to PED issuance or to a CAD trust field. It does not become the Execution Handle. Treating a valid GPU attestation as permission to release weights, post a payment, or invoke an arbitrary MCP tool would collapse two layers this document keeps separate.

Agentic Payments and Rail APIs Payment service providers, card schemes, and banks already operate settlement sinks, mandates, strong-customer-authentication, and replay controls. Some platforms also publish MCP servers or agent-payment APIs so that a model can construct an instruction. A rail token or vendor mandate is complementary prior approval. The Execution Handle is the later object that must still match amount, currency, beneficiary, rail, and settlement sink at post time. A PSP that already consumes instruction-digest-bound, single-use authority at the core already implements the invariant under another name.

Edge, API Gateway, and Organization Egress Cloudflare and similar platforms publicly host remote MCP servers and organization egress controls. Cloud customer accounts already terminate TLS and apply IAM at API gateways. When a third-party SaaS will not implement handles, the deploying organization's egress is the realistic Finality Sink. That placement is an integration pattern, not a requirement that any gateway vendor change its product.

What This Document Does Not Claim About Industry Roadmaps

• It does not claim that MCP, Copilot Studio, ChatGPT Agents, Gemini, Bedrock, Entra, IAM, EU Data Boundary, European Sovereign Cloud, Sovereign Controls, NVIDIA attestation, or Arm CCA are incomplete, insecure, or non-compliant.
• It does not claim that any named company has reviewed, implemented, funded, or endorsed this Internet-Draft.
• It does not interpret a public preview, GA announcement, or foundation donation as a commitment to Execution Handles.
• It does not treat marketplace tool listing as effectuation authority.
• It does not treat confidential-compute attestation as legal or act-specific authorization.
• It does not require a vendor to place the sink inside their hosted model. An organization-side egress sink is a conforming placement.

Corrections and Criticism from Named Parties Are Requested Engineers, product counsel, and standards participants at the organizations named above — and at any organization omitted by mistake — are invited to correct this section. Useful corrections include:

• a public mechanism that already binds a reconstructed live tool call or payment instruction to single-use or counted consume state at the actual consequence;
• a mis-cited roadmap URL, date, or product name;
• a product that already fails closed when consume-state is unavailable;
• a reason that profiling existing OAuth, DPoP, WIMSE, or MCP authorization is sufficient and this object is unnecessary;
• a privacy, performance, or operational reason that sink reconstruction is infeasible in a named product class;
• a request to remove a company name because the alignment is overstated.

A demonstrated equivalent mechanism should shrink this draft. Silence from a named company MUST NOT be read as agreement, disagreement, or product intent.

Non-Endorsement, Non-Affiliation, and Non-Criticism Microsoft, OpenAI, Anthropic, Google, Amazon Web Services, NVIDIA, Arm, Cloudflare, Linux Foundation / AAIF, payment networks, and any other named organization are referenced only as public technical context. This document does not assert vulnerability, deficiency, non-conformance, affiliation, partnership, funding, endorsement, or a requirement that any named product adopt this architecture. Trademarks remain the property of their owners.

Performance and Availability CAD construction, policy evaluation, and handle issuance can occur on a cold path. The hot path is digest compare, generation compare, consume-state update, and commit. Synchronous PED round-trips on every effect are not required if a still-current handle exists and the sink revalidates currentness locally. Consume-state unavailability MUST fail closed for SINGLE_USE high-consequence acts. Read-only or low-assurance profiles MAY define an explicit degraded mode; they MUST NOT label that mode as equivalent to the strict profile. Consume-state does not have to be a single global database. A sink MAY partition by handle_id, by destination, or by tenant, provided that two workers that could commit the same handle share one linearizable row or compare-and-swap slot for that handle. Horizontal scaling of unrelated handles is therefore the same problem as any other single-row unique constraint. What this document forbids is scaling-by-ignoring: two replicas both posting because neither saw the other consume.

Anticipated Criticisms Three objections are expected from distributed-systems and platform reviewers. They are treated as design constraints, not as attacks on the reviewers. Where the objection is correct, the profile MUST shrink its claim.

Objection: A Saga or 2PC Plus Ordinary Tokens Is Enough Workflow engines, sagas, TCC, XA, and transactional outbox already order side effects. An OAuth or WIMSE token can sit on each step. That combination is often the right engineering answer for mitigation: the workflow retries, compensates, and leaves an audit trail. It is not the same property as an Execution Handle. A saga step that presents a still-valid access token after the beneficiary, amount, or tool arguments have changed will still run. A 2PC prepare that does not reconstruct the live child act will prepare the wrong act. Compensation that reuses the original token is not a new authorized reverse; it is another presentation of the same bearer object. Those cases are specified in . saga + access token orders steps and authenticates the caller handle at the sink binds THIS reconstructed act at THIS sink THIS many times both can exist saga is the coordinator handle is the child authority saga success log != every required child effectuated under a current exact-act handle If a deployment can show that each saga step already reconstructs the live act, binds a single-use or counted authority to that digest and sink, and fails closed on consume-store loss, that deployment already implements this draft under other names. The useful review is that demonstration, not the existence of sagas.

Objection: Atomic Consume Is a Serialization Tax Forcing a crash-safe monotonic consume before every post looks like a cross-replica lock on a hot rail. That criticism is correct if consume-state is designed as one global counter for all traffic. The intended hot path is: cold path (once per act): build CAD, evaluate policy, issue EH hot path (per attempt): reconstruct digest OR compare declared digest compare sink_id and generations CAS consume-row[handle_id] commit local effect SINGLE_USE is required only where a second effect of the same act is the failure mode (payment post, coil write, weight release). COUNTED and ENVELOPE exist so that high-QPS low-consequence calls are not forced through one-shot consume. A profile that puts SINGLE_USE on every MCP list_files call has mis-applied the registry, not discovered a protocol bug. Rails that already authorize-then-capture, or that already keep an idempotency key per instruction id, already pay this tax under another name. The draft asks that the key be bound to the reconstructed act digest and to the sink, not that a new consensus cluster be inserted in front of every gateway.

Objection: Sink Reconstruction Is Too Hard in a Mesh Independently rebuilding a canonical CAD from "what the sink is about to do" is difficult when the pending effect is scattered across headers, body fields, side channels, and defaulted microservice context. That difficulty is real. It is also the reason substitution works. This document does not require every mesh hop to become a Finality Sink. Reconstruction is required only at the component that would first make the external effect real. Intermediate proxies MAY forward the handle. They MUST NOT be treated as having consumed it. A profile MAY define a closed field set and a deterministic canonicalization for that sink class (amount, currency, beneficiary, rail; or tool name plus named arguments). It MUST list those fields. A sink that cannot reconstruct a field MUST treat the field as digest-covered only if it can observe it. Hidden context that can change the effect and is omitted from the digest is an incomplete CAD (), not a reason to trust the caller-supplied blob. Allowed: sink observes live post fields builds CAD_live compares digest(CAD_live) to EH.act_digest Allowed with documented residual: sink accepts caller CAD plus proof that CAD equals live fields it actually observes Forbidden in strict profile: sink trusts caller digest and never looks at the live effect If a sink class cannot observe enough of the live effect to build a meaningful digest, that sink class cannot claim exact-act prevention. It can still authenticate the caller. Those are different claims.

What Would Falsify or Fast-Track the Objection The fastest honest test is a small sink middleware — for example an MCP server wrapper or a payment-post adapter — that issues a handle for a reconstructed tool call or payout and refuses a mutated argument, a replay, or a prompt-injected destination. If that wrapper cannot be written without a global lock, the performance objection stands. If it can, the object is implementable. This document does not ship that code. An implementation that does is invited and would be more useful to a working group than a further architectural draft.

Required Classes of Test Vectors A concrete profile or implementation SHOULD test at least:

• matching CAD, matching sink, unused SINGLE_USE handle: effectuate and consume;
• second presentation of the same SINGLE_USE handle: EF-005;
• argument substitution after issuance: EF-023;
• destination substitution after issuance: EF-020;
• presentation at the wrong sink: EF-040;
• expired handle: EF-004;
• integrity-broken handle: EF-003;
• stale policy or revocation generation: EF-041;
• revocation lands after an early out-of-block verify and before commit: EF-062 and no effect;
• caller-supplied digest that does not match reconstructed fields: reject;
• COUNTED handle under max_uses: succeed; at max_uses: EF-005;
• ENVELOPE handle with in-envelope non-identical repeat: succeed;
• ENVELOPE identical-digest replay with default policy: EF-006;
• ENVELOPE identical-digest replay only if envelope.allow_identical_replay: succeed;
• ENVELOPE handle with out-of-envelope field: EF-043;
• two concurrent verify workers on one SINGLE_USE handle: only one commit;
• crash after consume and before commit: no second effect;
• receipt replayed as a handle: reject;
• valid WIMSE identity with mismatched act: reject;
• valid Attestation Result presented instead of handle: EF-002;
• SCITT receipt for policy only, no handle: EF-002;
• alternate raw-credential path produces same K: prevention profile fails;
• consume-store down under strict profile: EF-081 fail closed.

Questions to the IETF Community Criticism, corrections, counterexamples, operational experience, prior art, and evidence that existing standards already provide the full property are explicitly invited. Recommendations to narrow, merge, or stop the work are useful outcomes.

1. Is a distinct Execution Handle object useful, or should these semantics be profiled onto existing OAuth tokens, CWTs, or WIMSE credentials?
2. Which CAD fields are universal, and which must remain profile extensions?
3. Should canonicalization be JCS, deterministic CBOR, HTTP Message Signature component names, or profile-declared?
4. Is SINGLE_USE the default reuse policy for high-consequence classes?
5. How should envelope reuse be bounded so it cannot become a second bearer scope?
6. Must the sink reconstruct arguments from the live effect, or may it accept a caller CAD plus proof?
7. What consume-state store is realistic at payment, OT, and tool-dispatch latency?
8. Should Finality Receipts be SCITT statements, COSE_Sign1, or both?
9. How should handles travel across WIMSE multi-hop chains without becoming portable bearer authority?
10. Is an HTTP header binding worth standardizing, or only an abstract verify/consume API?
11. Which existing token confirmation methods (DPoP, TLS-bound, WIMSE) should be optional EH key-binding methods?
12. What privacy risk does an Act Digest create if arguments are low-entropy?
13. What counterexample shows that DPoP plus RAR plus HTTP signatures already close this gap?
14. Which venue is best for further discussion: OAuth, WIMSE, RATS, SCITT, HTTPAPI, DISPATCH, or SAAG?
15. Does a documented saga or 2PC plus DPoP/RAR already reconstruct the live act and consume single-use authority at the actual sink?
16. Can consume-state be a per-handle compare-and-swap row, or do reviewers still require a different reuse default for high-QPS sinks?
17. For which sink classes is live reconstruction infeasible, and should those classes be excluded from the strict profile rather than allowed to trust the caller CAD?

Potential IETF Discussion Venues This document does not claim that any named group should adopt the work. The mapping below is overlap review, not a presumed home.

OAuth Relevant if the handle is profiled as a constrained token type using RAR data at issuance. OAuth should not be asked to own actuation, RF, or composite join.

WIMSE Relevant to workload identity inside CAD.actor and multi-hop presentation. WIMSE identity is not exact-act authority.

RATS Relevant when an Attestation Result is a PED input. RATS should not own consume-state.

SCITT Relevant to logging Finality Receipts and policy hashes. A SCITT receipt is not a permit to effectuate.

HTTPAPI Relevant if an HTTP verify/consume binding or problem+json mapping is standardized later.

DISPATCH Natural first stop because the object spans token, HTTP, and non-HTTP sinks.

SAAG Useful for Security Area review of whether a new effectuation object is justified. SAAG does not adopt documents.

No Presumed Home Individual submission. Venue choice is an open community question.

Relationship to Other Execution-Finality Internet-Drafts This document supplies the common wire objects. Other drafts in the family state the architecture, name the codes, join multiple sinks, or bind a single predicate. They are complementary. None of them is this protocol. Architecture: DAS-PROTOCOL computation is not authority This document: CAD / handle / verify / consume / receipt Names: DAS-REG classes, sinks, EF codes, profiles Join: DAS-COMPOSITE N sinks, all-or-none Predicate drafts: DAS-STATE decision basis still current? DAS-REVOCATION withdrawn before commit? DAS-PATH can the effect avoid the sink? DAS-JURISDICTION current JEC still permitted? DAS-PURPOSE live purpose still authorized? Domain / agent drafts: DAS-AGENTIC, DAS-TOOL tool_use is not invoke() DAS-RATS attestation is input, not handle payment / OT / 6G / enterprise profiles apply these objects; they SHOULD NOT mint parallel wire formats Related documents include , , , , , , , , , , and .

Security Considerations A handle-prevention claim is only as strong as CAD completeness, sink reconstruction, consume-state integrity, and path coverage.

Incomplete CAD If a load-bearing field is omitted from the Act Digest, substitution of that field will not be detected. Profiles MUST list digest-covered fields.

Caller-Supplied Digest Accepting a caller digest without reconstruction lets the caller bind a handle to a different live operation. Sinks SHOULD reconstruct.

Bearer Degradation If a deployment treats handle possession as sufficient, the object becomes an access token under another name. The strict profile forbids that degradation.

Consume-Store Integrity An attacker who can reset consume-state can replay SINGLE_USE handles. The store is part of the trusted computing base for prevention claims.

Alternate Path Raw credentials, admin consoles, replicas, and debug ports can negate handle enforcement. Prevention requires equivalent mediation of every path to K.

Low-Entropy Arguments Digests of small argument sets can enable dictionary confirmation of sensitive destinations. Profiles SHOULD salt or include high-entropy instance identifiers in the digested CAD.

Handle Correlation Stable handle_id and candidate_act_id values can correlate activity across hops. Short-lived identifiers and sink-local verification reduce exposure.

Issuer Compromise A compromised PED can issue handles for unauthorized acts. This draft does not solve issuer honesty. Separation of PED and sink, attestation of PED, and dual control are deployment mitigations.

Technical Enforcement Is Not Policy Correctness Perfect handle enforcement of a bad PED policy still produces the bad effect. This document specifies correspondence and consume, not which acts ought to be allowed.

Privacy Considerations CADs and receipts can reveal tool choice, destination, amount class, jurisdiction, and workload identity. Implementations SHOULD hash raw arguments on untrusted paths, emit the minimum receipt fields needed for the relying party, and avoid logging full tool arguments when the digest suffices.

IANA Considerations This version requests no IANA actions. A companion registries draft is expected to request media types, error codes, consequence classes, sink types, and claim names if the community wants a shared namespace. Codes in are illustrative only.

Criticism, Corrections, and Review Invited This document is presented for adversarial review. Particularly useful feedback is a concrete protocol already requiring exact-act reconstruction, sink binding, and atomic consume before consequence. Such evidence should reduce the scope of this proposal. Equally useful is correction of . If a public Microsoft, OpenAI, Anthropic, Google, AWS, NVIDIA, Arm, Cloudflare, PSP, or foundation mechanism already implements the handle invariant, or if this draft mis-describes a published roadmap, the text should be amended or the industrial example removed. Named parties are not expected to respond; a response is a courtesy, not an obligation, and neither response nor silence is an endorsement.

Conclusion Identity, sender constraint, attestation, and signed statements solve indispensable parts of machine authorization. The narrow question addressed here is whether the object presented at the effectuation boundary still corresponds to the live pending operation, at the intended sink, under current generations, and under a consume rule that makes replay a protocol failure. POSSESSION != AUTHORITY TO EFFECTUATE Valid for C17 at S17 != Valid for C18, or at S18, or a second time For strict handle finality: Corresponds(H, C_now, S_now) AND ConsumeOK(H) OR Candidate remains non-effective.

Normative References Informative References IETF IETF IETF IETF IETF IETF IETF IETF IETF IETF IETF IETF IETF WIMSE Working Group Model Context Protocol Linux Foundation Microsoft Microsoft Microsoft Microsoft Amazon Web Services Google Cloud NVIDIA Arm