Possession Is Not Authority: Execution Handle, Sink Verification, Atomic Consumption, and Finality Receipt

1.1. 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.¶

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.¶

1.2. Existing Mechanisms Already Address Important Parts

OAuth access tokens authenticate delegated access to an API [RFC6749]. Rich Authorization Requests can carry fine-grained authorization details such as actions, resources, and purpose [RFC9396]. DPoP and certificate-bound access tokens reduce bearer theft by binding a token to a proof-of-possession key [RFC9449] [RFC8705]. JWT and CWT provide signed or encrypted claim sets [RFC7519] [RFC8392]. HTTP Message Signatures can authenticate a particular HTTP request [RFC9421].¶

WIMSE identifies workloads across systems [WIMSE-ARCH]. RATS appraises execution environments [RFC9334]. SCITT registers signed statements and issues receipts [RFC9943]. 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.¶

1.3. 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.¶

1.4. 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.¶

5.1. 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?"¶

5.2. 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.¶

5.3. 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.¶

5.4. 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.¶

5.5. 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.¶

6.1. 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.¶

6.2. 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.¶

6.3. 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.¶

6.4. 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.¶

6.5. 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.¶

8.1. OAuth Access Tokens and RAR

OAuth tokens and RAR authorization details can express who may do what class of operation on which resource [RFC6749] [RFC9396]. 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.¶

8.2. DPoP and Certificate-Bound Tokens

Sender-constrained tokens reduce presentation by a thief who lacks the bound key [RFC9449] [RFC8705]. They do not by themselves digest the pending operation or consume authority at a designated sink.¶

8.3. HTTP Message Signatures

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

8.4. 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.¶

8.5. Comparison Summary

8.6. 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.

11.1. 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.¶

11.2. Canonicalization and Act Digest

An implementation MUST define a deterministic canonicalization for digest input. JSON profiles SHOULD use JCS [RFC8785] or an explicitly declared equivalent. CBOR profiles SHOULD use deterministic CBOR encoding [RFC8949].¶

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.¶

11.3. 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"
  }
}

12.1. 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
}

12.2. 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.¶

12.3. 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 AND sink-local
    replay rules for identical acts still hold.

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.¶

13.1. 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 Section 18 are illustrative pending registry action.¶

13.2. 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)
    CONSUME(EH)
    COMMIT(pending)
}

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.¶

13.3. 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
    consume_outcome,     ; CONSUMED | RESERVED | UNCHANGED | FAILED
    reason_code,         ; if REJECTED
    generations_observed,
    issued_at
}

A profile MAY register receipts with SCITT [RFC9943]. Transparency of the receipt does not replace sink verification of a later act.¶

15.1. 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.¶

16.1. JSON Profile

CAD, EH, verify request/response, and receipts MAY be JSON objects. Digests use JCS [RFC8785] 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.¶

16.2. COSE / CWT Profile

An Execution Handle MAY be a CWT [RFC8392] 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 [RFC9943].¶

19.1. 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

19.2. 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())

19.3. 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

19.4. 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

19.5. Consume and Commit

function consume_and_commit(eh, cad_now, sink, pending):
    begin_protected_finality_section()

    result = verify_handle(eh, cad_now, sink)
    if result != PASS:
        write_receipt(REJECTED, result.code)
        remain_non_effective()
        return REJECTED

    atomic {
        state = consume_store.get(eh.handle_id)

        if eh.reuse_policy == SINGLE_USE:
            if state != UNUSED:
                abort("EF-005")
            consume_store.put(eh.handle_id, USED)

        else if eh.reuse_policy == COUNTED:
            if state.count >= eh.max_uses:
                abort("EF-005")
            consume_store.put(eh.handle_id, state.count + 1)

        else if eh.reuse_policy == ENVELOPE:
            if !inside_envelope(cad_now, eh.envelope):
                abort("EF-043")
            if replayed_identical_act(eh, cad_now) and
               policy.forbids_identical_replay:
                abort("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

19.6. 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

19.7. 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.

19.8. 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

20.1. 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.¶

20.2. WIMSE

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

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.

20.3. RATS

An Attestation Result MAY be a PED input that the environment is acceptable [RFC9334]. 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.¶

20.4. SCITT

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

20.5. 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.¶

22.1. Argument or Destination Substitution

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

22.2. Handle Replay

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

22.3. Cross-Sink Presentation

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

22.4. 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.¶

22.5. 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.¶

22.6. 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.¶

22.7. 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.¶

22.8. 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.¶

23.1. Inline Sink

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

23.2. 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.¶

23.3. 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.¶

24.1. 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?

24.2. 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 [MCP-SPEC]. 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 [MS-MCP-GA] [MS-MCP-LEARN]. Anthropic later donated MCP to the Linux Foundation Agentic AI Foundation with public support from additional industry participants [AAIF-MCP].¶

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.¶

24.3. 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 [WIMSE-ARCH].¶

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?"

24.4. Sovereign Cloud and Data-Boundary Roadmaps

Microsoft documents the EU Data Boundary and continuing-transfer cases [MS-EUDB] [MS-EUDB-TRANSFERS]. AWS documents the European Sovereign Cloud [AWS-ESC]. Google Cloud documents partner-operated Sovereign Controls including residency, external key management, and local supervision [GOOGLE-SOV].¶

Those roadmaps supply residency, operator, and key-control dimensions. They are natural inputs to CAD fields and to jurisdiction-bound finality [DAS-JURISDICTION]. 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.¶

24.5. Confidential Compute and Accelerator Attestation

NVIDIA documents local and remote GPU and NVSwitch attestation [NVIDIA-ATTEST]. Arm documents the Confidential Compute Architecture and Realm attestation [ARM-CCA]. 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.¶

24.6. 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.¶

24.7. 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.¶

24.8. 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.¶

24.9. 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.¶

24.10. 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.¶

26.1. 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 [DAS-COMPOSITE].¶

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.¶

26.2. 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.¶

26.3. 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 (Section 31.1), 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.¶

26.4. 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.¶

29.1. 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.¶

29.2. WIMSE

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

29.3. RATS

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

29.4. SCITT

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

29.5. HTTPAPI

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

29.6. DISPATCH

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

29.7. SAAG

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

29.8. No Presumed Home

Individual submission. Venue choice is an open community question.¶

31.1. 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.¶

31.2. Caller-Supplied Digest

Accepting a caller digest without reconstruction lets the caller bind a handle to a different live operation. Sinks SHOULD reconstruct.¶

31.3. 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.¶

31.4. 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.¶

31.5. Alternate Path

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

31.6. 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.¶

31.7. Handle Correlation

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

31.8. 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.¶

31.9. 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.¶