Network Working Group S. Das Internet-Draft Independent Researcher Intended status: Informational 19 September 2026 Expires: 23 March 2027 When AI Agents Hold the Keys: Threat Model and Execution-Finality Requirements for Autonomous High-Consequence Systems draft-das-agentic-effectuation-boundary-00 Abstract AI agents are increasingly being delegated authority to invoke APIs, move money, modify enterprise state, operate infrastructure, and trigger physical actions. Existing mechanisms for authentication, authorization, proof-of-possession, attestation, request preconditions, and authorization-context propagation are necessary building blocks, but they do not by themselves establish a universal invariant that the exact consequential act approved earlier is the exact act permitted to become effective now. This document defines a threat model for autonomous high-consequence agents and identifies an effectuation-boundary gap: a request can be correctly authenticated, correctly authorized, correctly attested, and still be unsafe to execute because parameters, policy state, external prerequisites, delegation state, lineage, or the execution path changed after the earlier decision. The document describes an execution-finality architecture in which a proposed act remains non- effective until a protected enforcement point verifies exact-act binding, freshness, current policy state, anti-replay state, required provenance, and path completeness immediately before effectuation, with authority consumed in coordination with the consequential commit. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Das Expires 23 March 2027 [Page 1] Internet-Draft Agentic Effectuation Boundary September 2026 This Internet-Draft will expire on 23 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Sequence . . . . . . . . . . . . . . . . . . . . 4 1.2. Industry-Standard Terminology and Functional Equivalence . . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Assets . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Security Boundary . . . . . . . . . . . . . . . . . . . . 7 4. High-Attention Threat Scenarios . . . . . . . . . . . . . . . 7 4.1. Scenario 1: The Perfectly Authenticated Fraudulent Transfer . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Scenario 2: The Correct Breaker Command at the Wrong State . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Scenario 3: The Robot Executes Yesterday's Safe Plan . . 8 4.4. Scenario 4: Narrow Delegation Becomes Broad Effect . . . 9 4.5. Scenario 5: A Retry Becomes a Double Consequence . . . . 9 4.6. Scenario 6: The Emergency Path Becomes the Attack Path . 9 4.7. Scenario 7: Attested Platform, Unauthorized Consequence . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Scenario 8: Missing Lineage Is Treated as No Restriction . . . . . . . . . . . . . . . . . . . . . . 10 4.9. Scenario 9: Split-Brain Commit . . . . . . . . . . . . . 10 4.10. Scenario 10: Tool Schema Drift Changes the Meaning of the Same Call . . . . . . . . . . . . . . . . . . . . . . . 10 5. Why OAuth Plus Sender-Constrained Authorization Does Not Alone Solve Irreversible Effectuation . . . . . . . . . . . . . 11 5.1. Holder-of-Key Is Not Exact-Act Finality . . . . . . . . . 11 5.2. RAR Can Describe the Act; Description Is Not the Commit Invariant . . . . . . . . . . . . . . . . . . . . . . . . 12 Das Expires 23 March 2027 [Page 2] Internet-Draft Agentic Effectuation Boundary September 2026 5.3. Token Replay Protection Is Not Effect Replay Protection . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Authorization-Time State Is Not Necessarily Effectuation-Time State . . . . . . . . . . . . . . . . . 12 5.5. OAuth-Sufficient Deployments . . . . . . . . . . . . . . 13 6. Why This Internet-Draft Is Different . . . . . . . . . . . . 13 6.1. Proposed Interoperability Surface . . . . . . . . . . . . 14 6.2. Protocol-Level Distinguishing Invariants . . . . . . . . 14 7. IETF Working-Group Relevance and Possible Dispatch . . . . . 15 7.1. Likely Standards Decomposition . . . . . . . . . . . . . 16 7.2. Question for Dispatch . . . . . . . . . . . . . . . . . . 17 8. Why Existing Controls Do Not Fully Close the Effectuation Boundary . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Execution-Finality Architecture . . . . . . . . . . . . . . . 18 9.1. Canonical Candidate Act . . . . . . . . . . . . . . . . . 19 9.2. Act-Bound Execution Authority . . . . . . . . . . . . . . 20 9.3. Effectuation Predicate . . . . . . . . . . . . . . . . . 20 9.4. Check-and-Effect Semantics . . . . . . . . . . . . . . . 21 10. Required Security Properties . . . . . . . . . . . . . . . . 22 11. Domain Profiles . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Corporate Treasury and Autonomous Payments . . . . . . . 22 11.2. Power and Industrial Control . . . . . . . . . . . . . . 23 11.3. Robotic Logistics . . . . . . . . . . . . . . . . . . . 23 12. Industrial Relevance and Deployment Context . . . . . . . . . 23 12.1. OpenAI: Long-Running Agents and Tool Execution . . . . . 23 12.2. Anthropic: Autonomous Tool Use . . . . . . . . . . . . . 24 12.3. Microsoft: Autonomous Enterprise Agents . . . . . . . . 24 12.4. Google Cloud: Managed Agent Runtimes and Agent-to-Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . 24 12.5. AWS: AgentCore and Enterprise Tool Connectivity . . . . 25 12.6. NVIDIA: Robotics and Physical Actuation . . . . . . . . 25 12.7. Apple: On-Device Models, Tool Calling, and App Actions . . . . . . . . . . . . . . . . . . . . . . . . 25 12.8. Cross-Vendor Interoperability Significance . . . . . . . 26 12.9. Why a Standards-Level Treatment Matters . . . . . . . . 26 13. Adversarial Test Matrix . . . . . . . . . . . . . . . . . . . 27 14. Relationship to Current IETF Work . . . . . . . . . . . . . . 28 15. Operational Considerations . . . . . . . . . . . . . . . . . 28 16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 17. Security Considerations . . . . . . . . . . . . . . . . . . . 29 18. Open Questions for the IETF Community . . . . . . . . . . . . 29 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 20. Additional Public Technical Resources . . . . . . . . . . . . 30 21. Normative and Informative References . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 Das Expires 23 March 2027 [Page 3] Internet-Draft Agentic Effectuation Boundary September 2026 1. Introduction The security model of software is changing as AI systems move from generating content to initiating consequential operations. An agent may prepare a payment, change a cloud route, dispatch a warehouse robot, alter an industrial setpoint, or invoke another privileged agent without a human reviewing every individual operation. The core vulnerability considered here is not simply that an AI model might be wrong. The vulnerability is that a machine-generated act can cross from computation into an externally meaningful consequence even when the authorization evidence was created for a different act, a different state, an earlier policy epoch, an earlier dependency state, or a different execution path. Existing industry mechanisms address important parts of this problem. OAuth authorization constrains access to protected resources; Rich Authorization Requests can carry structured authorization details; DPoP sender-constrains tokens; Transaction Tokens propagate identity and authorization context through service chains; RATS and EAT provide evidence and claims about platform state; HTTP conditional requests can prevent operations against a changed target representation. Those controls remain useful and are not replaced by this document. The architectural delta is narrower: the component that is able to make the consequential operation effective independently verifies that the exact act being committed is still authorized under the current relevant state, and couples successful verification with single-use consumption or equivalent anti-reuse state. 1.1. Problem Sequence The problem can be summarized as: Das Expires 23 March 2027 [Page 4] Internet-Draft Agentic Effectuation Boundary September 2026 autonomous computation | v proposed consequential act | v authentication / authorization / attestation | | time passes; state changes; delegation changes; | parameters may be substituted; retries may occur; | another path may bypass the earlier check v EFFECTUATION BOUNDARY | +----> payment settles +----> breaker changes state +----> robot moves +----> data leaves trust boundary +----> privileged API mutates state Security question: Is the exact act crossing this boundary authorized NOW, under the state and constraints that matter to the consequence? 1.2. Industry-Standard Terminology and Functional Equivalence The terminology in this document is intended to describe functions, not require a particular product name or implementation. The same architecture may appear under different terminology in financial, industrial, telecom, cloud, safety, distributed-systems, or hardware- security environments. +===============+=========================+=========================+ | Term used | Equivalent or related | Underlying function | | here | industry terms | | +===============+=========================+=========================+ | Candidate Act | transaction intent, | The exact operation | | | command, job, API | proposed before it is | | | mutation, control | allowed to become | | | action | effective. | +---------------+-------------------------+-------------------------+ | Non-Effective | staged state, prepared | The operation exists | | State | state, uncommitted | but has not yet | | | state, pending command | produced its governed | | | | consequence. | +---------------+-------------------------+-------------------------+ | Execution | bounded capability, | Cryptographic or | | Handle | transaction | protected authority | Das Expires 23 March 2027 [Page 5] Internet-Draft Agentic Effectuation Boundary September 2026 | | authorization | bound to an exact act | | | artifact, one-shot | and constraints. | | | permit | | +---------------+-------------------------+-------------------------+ | Finality Sink | policy enforcement | The component or | | | point, reference | boundary whose | | | monitor, command gate, | successful action first | | | actuation gate, safety | makes the governed | | | interlock, commit gate | consequence effective. | +---------------+-------------------------+-------------------------+ | Policy Epoch | generation number, | A version marker used | | | fencing epoch, | to reject authority | | | configuration version | created under stale | | | | policy or delegation | | | | state. | +---------------+-------------------------+-------------------------+ | Act Binding | transaction binding, | Cryptographic | | | parameter binding, | association between | | | request-object binding | authority and the exact | | | | canonical operation. | +---------------+-------------------------+-------------------------+ | Atomic | check-and-commit, | Prevents the same | | Consume | compare-and-swap, | authority from becoming | | | transactional consume, | the basis for multiple | | | idempotency commit | governed effects. | +---------------+-------------------------+-------------------------+ | Path | complete mediation, | Ensures alternate paths | | Completeness | anti-bypass, | cannot produce the same | | | chokepoint enforcement | consequence without the | | | | required gate. | +---------------+-------------------------+-------------------------+ Table 1: Functional Equivalence 2. Scope This document focuses on machine-generated acts with potentially irreversible, high-cost, safety-relevant, or externally binding effects. Examples include financial settlement, critical infrastructure control, robotic actuation, privileged enterprise changes, protected data release, and autonomous inter-agent delegation. This document does not standardize bank settlement protocols, grid protection algorithms, robot motion planning, model alignment, or domain-specific safety certification. It defines a cross-domain security boundary and the properties expected at that boundary. Das Expires 23 March 2027 [Page 6] Internet-Draft Agentic Effectuation Boundary September 2026 3. Threat Model The threat model assumes that one or more upstream components can be buggy, compromised, stale, adversarially influenced, or operating on incomplete information. The model does not require the AI model itself to be malicious. Relevant adversaries and failure sources include prompt injection, malicious tool output, compromised service workloads, stolen credentials, stale authorization context, policy revocation races, parameter substitution, replay, retry storms, split-brain services, schema drift, compromised plugins, malicious insiders, incomplete provenance, and alternate execution paths. 3.1. Assets * financial balances and settlement authority; * industrial and grid control state; * robotic motion and safety envelopes; * privileged enterprise resources; * confidential data and network egress; * delegation state and policy configuration; * auditability of machine-generated consequences. 3.2. Security Boundary The protected boundary is the point at which a candidate operation first becomes externally meaningful. A high-assurance deployment treats code that proposes the act as less trusted than the component that verifies and releases the effect. 4. High-Attention Threat Scenarios 4.1. Scenario 1: The Perfectly Authenticated Fraudulent Transfer A treasury agent is authorized to initiate vendor payments. It holds valid OAuth credentials and a proof-of-possession key. An attacker influences the model through an invoice attachment and causes the beneficiary account to be substituted after a legitimate approval workflow has completed. Das Expires 23 March 2027 [Page 7] Internet-Draft Agentic Effectuation Boundary September 2026 Authentication can still succeed. Sender-constrained access can still succeed. The agent can still be the legitimate software presenting the token. The missing property is whether settlement authority is cryptographically bound to the exact beneficiary, amount, currency, invoice basis, policy epoch, and single-use transaction instance that the sink is about to commit. approved: pay(vendor=A, account=X, amount=100000) attacker-controlled substitution | v executed: pay(vendor=A, account=Y, amount=100000) If the sink validates only "agent may pay vendors", the authorization is valid while the act is wrong. 4.2. Scenario 2: The Correct Breaker Command at the Wrong State A grid-management agent computes a breaker operation using telemetry observed at time T1. Before the command reaches the actuator, topology, load, protection status, or operator override state changes at T2. The command remains syntactically valid and the controller identity remains authorized. The safety question is therefore not only who issued the command, but whether the exact command remains admissible under the current control epoch and the current prerequisites that the deployment chooses to make execution-critical. 4.3. Scenario 3: The Robot Executes Yesterday's Safe Plan A warehouse agent generates a route and grasp sequence while an aisle is clear. A worker, another robot, or a pallet subsequently changes the local environment. A stale prepared command is later delivered by a retrying service. Model correctness at planning time is insufficient. A protected actuation gate can require freshness, a current safety epoch, command digest equality, single-use authority, and any domain-specific interlock result required by the robot controller. Das Expires 23 March 2027 [Page 8] Internet-Draft Agentic Effectuation Boundary September 2026 4.4. Scenario 4: Narrow Delegation Becomes Broad Effect Agent A delegates a task to Agent B, which invokes Agent C. Each hop propagates valid identity and authorization context, but the final command includes parameters not present when the original delegation was evaluated. This can occur through tool schema expansion, default arguments, data enrichment, or a compromised intermediate service. A final sink that verifies only the caller or scope may accept a semantically broader act. Exact-act binding makes the final parameter set an object of verification rather than an assumption about well-behaved intermediaries. 4.5. Scenario 5: A Retry Becomes a Double Consequence The agent submits a payment or actuation request. The network times out after the underlying effect occurs but before the agent receives confirmation. The agent retries. Generic request authentication does not necessarily distinguish a legitimate retry from a second authorized effect. The execution authority therefore needs an idempotency or single- consumption semantic coordinated with the effect boundary. For physical systems where rollback is impossible, the protected state transition must prevent command re-release even if higher layers repeat the request. 4.6. Scenario 6: The Emergency Path Becomes the Attack Path The primary API passes through a final enforcement gate, but a legacy interface, local maintenance command, direct message bus, or privileged recovery path can produce the same consequence without that gate. An attacker routes the operation through the uncontrolled path. This is a complete-mediation problem. Execution-finality is not established if a governed consequence has an alternate effectuation path that is outside the required enforcement set. 4.7. Scenario 7: Attested Platform, Unauthorized Consequence A workload presents fresh attestation evidence showing approved software and expected platform state. The workload then asks to perform an operation that is outside the intended transaction or uses stale delegation state. Das Expires 23 March 2027 [Page 9] Internet-Draft Agentic Effectuation Boundary September 2026 Attestation answers an important question about the entity and its state. It does not by itself establish that a specific consequential act is authorized for effectuation. The architecture can use RATS/ EAT evidence as an input while still requiring act-specific authorization at the sink. 4.8. Scenario 8: Missing Lineage Is Treated as No Restriction A downstream service receives an act without required provenance or delegation lineage. If missing lineage is interpreted as an empty restriction set, stripping metadata can increase authority. A safer semantic is to distinguish EMPTY from UNKNOWN. EMPTY means the verified lineage is intentionally empty. UNKNOWN means the required lineage cannot be established. For consequences whose policy requires lineage, UNKNOWN remains non-effective. 4.9. Scenario 9: Split-Brain Commit One subsystem records that an operation failed while another subsystem has already committed the consequence. A compensating retry or secondary controller then creates an inconsistent or duplicated state. Deployments should define which state transition is authoritative, how idempotency survives crashes, and whether the authority consumption record and the consequential commit can be made atomic or recoverably coupled. 4.10. Scenario 10: Tool Schema Drift Changes the Meaning of the Same Call An agent was approved to invoke a tool when version 7 of the schema mapped a field to a read-only operation. Version 8 changes a default, expands a wildcard, or maps the same high-level request to a state-changing operation. Authority can therefore be bound not only to textual arguments but also to the tool or mapping revision whose semantics were evaluated. Digest or version mismatch causes re-evaluation rather than dynamic assumptions of equivalence. Das Expires 23 March 2027 [Page 10] Internet-Draft Agentic Effectuation Boundary September 2026 5. Why OAuth Plus Sender-Constrained Authorization Does Not Alone Solve Irreversible Effectuation OAuth is directly relevant to this problem, and this document does not claim that OAuth authorization is weak or inappropriate. OAuth answers delegation and protected-resource access questions. Rich Authorization Requests can express fine-grained transaction details. DPoP and mutual-TLS certificate-bound access tokens can make an access token sender-constrained, sometimes informally described as "non-bearer", so possession of a copied token alone is insufficient. The remaining problem appears when a valid authorized request is able to trigger an irreversible or externally binding effect. Sender constraint proves that the presenter possesses the required key. It does not, by itself, prove that the irreversible effect about to occur is still the exact effect whose semantics were evaluated, that all execution-critical dependencies remain current, or that the authority and effect will be consumed as one recoverable state transition. 5.1. Holder-of-Key Is Not Exact-Act Finality A DPoP proof binds an OAuth presentation to a key and to selected HTTP request properties. A certificate-bound token similarly binds token use to the holder of the corresponding private key. These are strong defenses against stolen-token use. However, the legitimate key holder can still be a buggy, compromised, stale, or adversarially influenced agent. The relevant distinction is: sender-constrained authorization asks: "Is this token being presented by the legitimate key holder, for an allowed protected-resource request?" execution-finality additionally asks: "Is this exact consequential act, with these final semantics, permitted to become effective NOW, under the current execution-critical state, and can this authority create no unintended second effect?" Das Expires 23 March 2027 [Page 11] Internet-Draft Agentic Effectuation Boundary September 2026 5.2. RAR Can Describe the Act; Description Is Not the Commit Invariant RFC 9396 can carry highly specific authorization details, including payment amount and creditor information. If an authorization profile includes every execution-relevant field, and the resource server verifies those exact fields at the final commit boundary, then simple parameter substitution can already be prevented. This document explicitly relies on that capability where available. The residual case is state or semantics not fully represented by the authorization object: a beneficiary alias resolves differently, a tool or mapping revision changes, a delegation or policy epoch advances, an external prerequisite changes, a physical safety state changes, or an alternate path performs the same consequence without traversing the resource server check. Therefore, the delta is not "OAuth cannot describe a payment". The delta is that authorization description alone does not define a cross-domain commit-time invariant covering current dependencies, irreversible effect, anti-replay state, and path completeness. 5.3. Token Replay Protection Is Not Effect Replay Protection DPoP proof freshness, token sender constraint, and token replay defenses operate on protocol credentials and requests. A different failure occurs when the first request commits the external effect but the response is lost. A legitimate client may then construct a new valid proof and retry the authorized request. For an irreversible effect, the system needs an application or sink invariant such as a transaction identifier, idempotency key, one-shot capability, protected replay store, or equivalent state that is coordinated with the actual commit. Preventing reuse of a stolen credential and preventing duplication of an already committed consequence are related but distinct properties. 5.4. Authorization-Time State Is Not Necessarily Effectuation-Time State An authorization server can make a correct decision at time T1. The resource server can receive a valid sender-constrained token at T2. Between T1 and the irreversible effect at T3, an external prerequisite, policy generation, delegation, device state, mapping, or safety condition can change. Das Expires 23 March 2027 [Page 12] Internet-Draft Agentic Effectuation Boundary September 2026 T1 AS authorizes a specific operation | | valid RAR / token / sender constraint v T2 RS accepts a request from the legitimate key holder | | relevant external or local state changes v T3 irreversible effect becomes real | +--> settlement +--> actuator release +--> protected data egress +--> destructive enterprise mutation The property introduced here is a defined check at T3, not merely another credential evaluated at T1 or T2. 5.5. OAuth-Sufficient Deployments There is an important limiting case. If an OAuth deployment already binds every execution-relevant field, verifies those bindings at the component that performs the final effect, revalidates every required changing prerequisite, prevents alternate bypass paths, and couples idempotent or single-use authorization state to the actual commit, then that deployment already implements most of the execution- finality invariant described here. In that case, this document does not require replacing OAuth. Its value is to make those properties explicit, portable, testable, and applicable to systems whose final consequence is not merely an HTTP resource response, including message-driven services, hardware control, robotics, industrial actuation, and autonomous settlement. 6. Why This Internet-Draft Is Different This document is not a new general authorization framework. It does not define who a principal is, how a user delegates access, how consent is collected, or how a model decides what action to propose. It starts after those mechanisms have produced an apparently authorized candidate act. The document attempts to standardize the security properties of the final transition from an authorized proposal to an effective consequence. That makes the unit of analysis the effectuation boundary rather than the login session, access token, model output, API call, or attested workload. Das Expires 23 March 2027 [Page 13] Internet-Draft Agentic Effectuation Boundary September 2026 EXISTING LAYERS THIS DOCUMENT identity ---------------------+ authentication ----------------+----+ OAuth delegation --------------+ | RAR / scopes ------------------+ | sender constraint -------------+ | inputs workload identity -------------+ | attestation -------------------+ | safety / policy state ---------+----+ | v +------------------+ | EFFECTUATION GATE| | exact act? | | current state? | | current epoch? | | required lineage?| | unused authority?| | governed path? | +--------+---------+ | v IRREVERSIBLE CONSEQUENCE 6.1. Proposed Interoperability Surface The candidate interoperability surface is deliberately small: an exact-act commitment, an authority identifier or nonce, a sink identifier, freshness, relevant epoch or dependency commitments, constraints, and a verifiable result or receipt where required. Existing OAuth, COSE, RATS, or workload-identity artifacts can carry or supply these values if the responsible working groups determine that profiling existing mechanisms is preferable to defining new protocol objects. 6.2. Protocol-Level Distinguishing Invariants 1. The candidate act is explicitly non-effective before final verification. 2. The final sink reconstructs or obtains the exact act that will become effective. 3. Authority is compared against that exact act, not merely against caller identity or broad scope. Das Expires 23 March 2027 [Page 14] Internet-Draft Agentic Effectuation Boundary September 2026 4. Selected mutable state is revalidated at the effectuation boundary. 5. Authority reuse and crash/retry behavior are defined relative to the actual consequence. 6. Missing required provenance is UNKNOWN and fails closed rather than silently widening authority. 7. All materially equivalent effectuation paths are within the stated enforcement coverage. 7. IETF Working-Group Relevance and Possible Dispatch The problem is cross-area because an autonomous act can begin as an OAuth-authorized API operation, traverse several workloads, consume attestation evidence, cross a CBOR/COSE boundary, and terminate at a database, payment rail, gateway, or physical controller. The document therefore separates the common invariant from any single encoding or transport. +==========+======================+===============================+ | Group or | Relevant existing | Potential relationship to | | venue | work | this draft | +==========+======================+===============================+ | OAuth | delegated | Primary integration point for | | | authorization, RAR, | authorization inputs and | | | DPoP, token | multi-hop authorization | | | exchange, | context. A profile could | | | Transaction Tokens | bind OAuth authorization to | | | | an exact execution commitment | | | | without redefining OAuth. | +----------+----------------------+-------------------------------+ | WIMSE | workload identity | Relevant when an agentic act | | | and least-privilege | crosses several workloads and | | | access across multi- | the final sink must | | | service environments | distinguish workload identity | | | | from authority for the final | | | | consequence. | +----------+----------------------+-------------------------------+ | RATS | remote attestation | Attestation can supply | | | evidence, | trustworthy state predicates | | | attestation results, | to the finality sink. This | | | appraisal, epoch- | draft keeps attestation | | | related state | evidence separate from act | | | | authorization. | +----------+----------------------+-------------------------------+ | COSE | CBOR signing, MAC, | Relevant if an execution | Das Expires 23 March 2027 [Page 15] Internet-Draft Agentic Effectuation Boundary September 2026 | | encryption, keys, | handle or finality receipt | | | and registered COSE | needs a compact integrity- | | | attributes | protected CBOR representation | | | | or new registered attributes. | +----------+----------------------+-------------------------------+ | ACE / | authorization and | Potential profile venue for | | CoRE | constrained | constrained controllers, | | | application | robots, gateways, or | | | protocols for | industrial devices where the | | | resource-constrained | effectuation sink is not a | | | environments | conventional web service. | +----------+----------------------+-------------------------------+ | DISPATCH | routing new cross- | Suitable first venue if no | | / | cutting work and | current WG owns the cross- | | security | identifying overlap | domain effectuation-boundary | | dispatch | with existing WGs | invariant. | | process | | | +----------+----------------------+-------------------------------+ | SAAG | cross-cutting | Useful for threat-model | | | Security Area | review and architectural | | | discussion | criticism. SAAG is a | | | | discussion forum rather than | | | | a document-adopting WG. | +----------+----------------------+-------------------------------+ Table 2: Relationship to IETF Groups 7.1. Likely Standards Decomposition The work can be decomposed rather than forcing one working group to standardize every layer: 1. *Architecture / threat model:* define the effectuation boundary, attacker model, and invariants. 2. *Authorization profile:* define how existing OAuth authorization details or transaction context bind to an exact act when OAuth is used. 3. *Attestation binding:* define how RATS results or epoch evidence become execution predicates without turning attestation into authorization. 4. *Compact object format:* reuse COSE/CBOR only if a portable execution-handle or receipt representation is needed. Das Expires 23 March 2027 [Page 16] Internet-Draft Agentic Effectuation Boundary September 2026 5. *Constrained-device profile:* map the invariant to CoAP/ACE or device-local enforcement when an irreversible act occurs outside an HTTP service. 7.2. Question for Dispatch The central dispatch question is therefore not whether the IETF should invent another authorization protocol. It is whether existing IETF mechanisms, when combined, already define an interoperable and testable invariant for the final irreversible effect, and if not, which existing working group or new narrowly scoped effort should own that invariant. 8. Why Existing Controls Do Not Fully Close the Effectuation Boundary The mechanisms below are complementary. This section describes the remaining boundary condition rather than a defect in those protocols. Das Expires 23 March 2027 [Page 17] Internet-Draft Agentic Effectuation Boundary September 2026 +===============+====================+============================+ | Mechanism | Primary property | Residual question at | | | | effectuation | +===============+====================+============================+ | OAuth | Delegated access | Does current authority | | authorization | to a protected | bind the exact final act | | | resource. | and current execution- | | | | critical state? | +---------------+--------------------+----------------------------+ | RAR | Structured | Are the committed | | | authorization | parameters exactly those | | | details. | details, and are later- | | | | changing prerequisites | | | | still satisfied? | +---------------+--------------------+----------------------------+ | DPoP | Sender-constrained | Does the legitimate sender | | | token | possess authority for this | | | presentation. | exact consequential act? | +---------------+--------------------+----------------------------+ | Transaction | Propagation of | Is propagated context | | Tokens | identity and | sufficient for a commit- | | | authorization | time decision at the final | | | context through a | consequence boundary? | | | call chain. | | +---------------+--------------------+----------------------------+ | RATS / EAT | Evidence and | Is this exact act | | | claims about | authorized, current, | | | entity/platform | single-use, and path- | | | state. | complete? | +---------------+--------------------+----------------------------+ | HTTP If-Match | Conditional method | What about non-resource | | | execution against | dependencies, multiple | | | a matching target | resources, delegation | | | representation. | epochs, physical | | | | actuation, or consequences | | | | outside one HTTP origin? | +---------------+--------------------+----------------------------+ Table 3: Complementary Controls and Residual Boundary Question 9. Execution-Finality Architecture The proposed architecture separates the ability to compute an act from the authority required to make that act effective. Das Expires 23 March 2027 [Page 18] Internet-Draft Agentic Effectuation Boundary September 2026 +---------------------+ | Model / Agent / App | +----------+----------+ | | proposes exact Candidate Act v +---------------------+ | Non-Effective State | +----------+----------+ | | protected validation v +-----------------------------+ | Authorization / Policy / | | Attestation / Safety Inputs | +--------------+--------------+ | | issue act-bound authority v +-------------------------+ | Execution Handle | | digest + nonce + epoch | | constraints + expiry | +------------+------------+ | v +-------------------------+ | FINALITY SINK | | - reconstruct act | | - compare digest | | - verify freshness | | - verify current epoch | | - verify required state | | - verify lineage | | - consume once | +------------+------------+ | success only v EFFECTUATION 9.1. Canonical Candidate Act A deployment defines a deterministic representation of the execution- relevant fields. One abstract form is: Das Expires 23 March 2027 [Page 19] Internet-Draft Agentic Effectuation Boundary September 2026 A = Canon( operation, target, arguments, principal, delegated_by, purpose, budget, destination, tool_or_schema_revision, policy_epoch, dependency_commitments, sink_id ) act_digest = H(A) Canonicalization is application-specific and must avoid ambiguous encodings. Fields that can change the consequence need to be represented either directly or by an unambiguous commitment. 9.2. Act-Bound Execution Authority A representative execution handle can be modeled as: EH = Protect( act_digest, authority_id, nonce, issued_at, expires_at, policy_epoch, constraint_set, sink_id ) Protect() can be implemented with an integrity-protected token, protected local object, hardware-bound capability, or another construction that provides the deployment's required authenticity and anti-forgery properties. 9.3. Effectuation Predicate Let S_now be the protected state visible to the finality sink. A candidate act A becomes eligible for effectuation only if the required predicates are true: Das Expires 23 March 2027 [Page 20] Internet-Draft Agentic Effectuation Boundary September 2026 Permit(A, EH, S_now) = ValidProtection(EH) AND H(Canon(A)) == EH.act_digest AND Fresh(EH) AND NotConsumed(EH.nonce) AND EH.policy_epoch == S_now.policy_epoch AND PolicyAllows(A, S_now) AND RequiredDependenciesCurrent(A, S_now) AND RequiredLineage(A) != UNKNOWN AND SinkMatches(EH.sink_id) AND PathIsGoverned(A) Effectuate(A) only if Permit(...) == TRUE. 9.4. Check-and-Effect Semantics function effectuate(candidate_act, execution_handle): act = canonicalize(candidate_act) begin protected_transition: assert verify_handle(execution_handle) assert hash(act) == execution_handle.act_digest assert current_time <= execution_handle.expires_at assert replay_store.is_unused(execution_handle.nonce) assert policy_epoch() == execution_handle.policy_epoch assert current_policy_allows(act) assert required_dependencies_are_current(act) assert required_lineage(act) != UNKNOWN assert sink_id() == execution_handle.sink_id reserve_or_mark_inflight(execution_handle.nonce) result = commit_governed_effect(act) if result == COMMITTED: replay_store.mark_consumed(execution_handle.nonce) protected_commit() return SUCCESS protected_abort_or_recover() return FAILURE Exact crash semantics depend on the underlying consequence. For a database or payment rail, transactional or idempotent commit primitives may exist. For irreversible physical actuation, the protected state machine should ensure that a crash cannot cause the same authority to release the command a second time. Das Expires 23 March 2027 [Page 21] Internet-Draft Agentic Effectuation Boundary September 2026 10. Required Security Properties A system claiming an execution-finality property for a governed class of acts should make the following properties externally reviewable: 1. *EF-1 Exact-Act Binding:* authority is bound to a deterministic representation of the execution-relevant act. 2. *EF-2 Commit-Time Revalidation:* state designated as execution- critical is checked at or immediately before the effectuation boundary. 3. *EF-3 Anti-Replay:* the same authority cannot silently create multiple governed effects unless multiplicity is explicitly authorized. 4. *EF-4 Epoch/Fencing:* revocation, policy change, delegation change, or schema revision can invalidate previously issued authority when the deployment requires it. 5. *EF-5 Fail-Closed Unknowns:* required but unavailable lineage or state is represented as UNKNOWN rather than inferred to mean unrestricted authority. 6. *EF-6 Path Completeness:* all paths capable of producing the governed consequence are included in the enforcement model or explicitly identified as exceptions. 7. *EF-7 Sink-Local Verification:* the effectuation component does not rely solely on an upstream statement that validation occurred. 8. *EF-8 Recoverable Commit Semantics:* crash, timeout, retry, and split-brain behavior cannot silently turn one authorized act into multiple effects. 11. Domain Profiles 11.1. Corporate Treasury and Autonomous Payments A financial profile can bind beneficiary identifier, destination account, amount, currency, fee bound, invoice or business basis, source account, approval class, settlement rail, policy epoch, transaction nonce, and any risk or human-approval evidence required by the deployment. Das Expires 23 March 2027 [Page 22] Internet-Draft Agentic Effectuation Boundary September 2026 11.2. Power and Industrial Control A control profile can bind device or zone, command type, setpoint, allowed range, control epoch, topology or configuration commitment, maintenance state, operator override state, and required domain- specific safety interlock result. Execution-finality is not a substitute for protection relays or safety engineering; it is a gate that can make selected safety and authorization predicates technically necessary for command release. 11.3. Robotic Logistics A robotics profile can bind robot identity, command sequence, workspace or zone, payload class, maximum speed or force envelope, route revision, local safety epoch, freshness window, and the actuation sink expected to consume the authority. 12. Industrial Relevance and Deployment Context The effectuation-boundary problem is relevant to current industry architectures because major AI and cloud platforms are already exposing models to tools, APIs, enterprise workflows, code execution, operating-system actions, and physical robotics stacks. The examples in this section are illustrative integration contexts only. They do not assert that any named vendor has a security defect, lacks a particular control, or endorses this document. The common architectural trend is that model output is increasingly able to cause external state transitions. As that authority grows, the security question shifts from whether a model may call a tool in principle to whether the exact consequential act crossing the final boundary is still permitted under current state. 12.1. OpenAI: Long-Running Agents and Tool Execution OpenAI publicly describes its Agents API as infrastructure for building and running cloud agents that can manage context, use tools, coordinate subagents, work with files, run code, and persist intermediate state. See Introducing the Agents API (https://openai.com/index/introducing-the-agents-api/). In such an architecture, execution-finality is potentially relevant below the agent harness: the model or harness may legitimately decide to invoke a tool, while a downstream finality sink can still verify the exact operation, current policy epoch, destination, replay state, and any execution-critical dependency before an irreversible external effect is released. Das Expires 23 March 2027 [Page 23] Internet-Draft Agentic Effectuation Boundary September 2026 12.2. Anthropic: Autonomous Tool Use Anthropic describes current Claude models as capable of planning, using tools such as browsers and terminals, and running autonomously. See Introducing Claude Sonnet 5 (https://www.anthropic.com/news/ claude-sonnet-5). Tool-use systems create a natural separation between model reasoning and external effect. This document focuses on that separation: a tool call can be syntactically valid and originate from an authorized agent while the eventual side effect still requires exact-act binding, freshness, current-state validation, and anti-replay semantics. 12.3. Microsoft: Autonomous Enterprise Agents Microsoft documents autonomous capabilities in Copilot Studio in which agents can react to events, make decisions, and execute tasks without waiting for an interactive user prompt. See Design autonomous agent capabilities (https://learn.microsoft.com/en-us/ microsoft-copilot-studio/guidance/autonomous-agents). Enterprise workflows frequently terminate in systems of record, ticketing systems, identity infrastructure, financial systems, or other stateful services. The proposed finality boundary can be placed immediately before the mutation that carries the legally, financially, or operationally meaningful consequence, independently of which orchestration product generated the request. 12.4. Google Cloud: Managed Agent Runtimes and Agent-to-Agent Systems Google Cloud documents Vertex AI Agent Engine as supporting deployment and operation of agents, including code execution, memory, and Agent-to-Agent protocol support. See Vertex AI release notes (https://docs.cloud.google.com/vertex-ai/docs/release-notes). Multi-agent and multi-service systems make authority propagation especially important because the component that generated an intent may be several hops away from the component that performs the final effect. The execution-finality model therefore treats propagated identity, authorization context, and attestation as inputs, while reserving the last act-specific decision for the effectuation boundary. Das Expires 23 March 2027 [Page 24] Internet-Draft Agentic Effectuation Boundary September 2026 12.5. AWS: AgentCore and Enterprise Tool Connectivity AWS describes Amazon Bedrock AgentCore as a platform for building, deploying, and operating agents that take actions across tools and enterprise data with identity, access control, policy management, tool connectivity, session state, evaluation, and observability. See Amazon Bedrock AgentCore overview (https://docs.aws.amazon.com/ bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html). Those controls are complementary to this document. An execution- finality profile can sit at a payment adapter, deployment API, data- release gateway, or other consequence-producing resource and require a final exact-act and current-state check even when upstream runtime, identity, and policy controls all succeeded. 12.6. NVIDIA: Robotics and Physical Actuation NVIDIA Isaac is an AI robotics development platform for autonomous mobile robots, robot arms, manipulators, and humanoids, with supporting motion-planning, perception, simulation, and deployment components. See NVIDIA Isaac (https://developer.nvidia.com/isaac). Robotics makes the effectuation distinction concrete. A planner can generate a valid trajectory while the physical environment changes before actuation. The relevant sink may therefore be the command gate immediately before a motor controller, PLC, or robot control interface, where freshness, safety epoch, robot identity, command digest, and single-use release authority can be checked. 12.7. Apple: On-Device Models, Tool Calling, and App Actions Apple documents its Foundation Models framework as supporting structured output and tool calling, while App Intents exposes app actions to system experiences including Siri and Apple Intelligence. See Foundation Models (https://developer.apple.com/documentation/ foundationmodels) and Apple Intelligence (https://developer.apple.com/apple-intelligence/). On-device agentic systems are relevant because the final consequence may occur locally rather than at a cloud resource server. A device- side finality sink can mediate file changes, communication, payment initiation, privacy-sensitive data release, peripheral control, or another local action without requiring the model itself to be the trusted enforcement component. Das Expires 23 March 2027 [Page 25] Internet-Draft Agentic Effectuation Boundary September 2026 12.8. Cross-Vendor Interoperability Significance The industrial value of a standards-layer invariant becomes greater when the proposing agent, authorization server, workload runtime, tool provider, and effectuation system are operated by different vendors. For example, a model from one provider may run in a cloud agent platform from another vendor, invoke a third-party enterprise tool, and ultimately request an action from a bank, industrial controller, robot, telecom network, or local device. Model Provider | v Agent Runtime | v Identity / OAuth / Workload Authorization | v Tool or Service Chain | v Third-Party Consequence Boundary | +--> money moves +--> data leaves +--> infrastructure changes +--> robot actuates Interoperability question: What machine-verifiable object and sink behavior allow the last component to verify the exact authorized consequence without trusting every upstream implementation choice? 12.9. Why a Standards-Level Treatment Matters A single-vendor deployment can implement these properties as an internal engineering choice. In a cross-vendor system, however, relying parties need an interoperable way to determine what was authorized, what exact act is being committed, which mutable state was required to remain current, whether the authority has already been consumed, and which component is responsible for the final check. This is the reason the topic is potentially relevant to the IETF: the proposed work is not intended to prescribe how OpenAI, Anthropic, Microsoft, Google, AWS, NVIDIA, Apple, or any other vendor should Das Expires 23 March 2027 [Page 26] Internet-Draft Agentic Effectuation Boundary September 2026 build an agent. It asks whether interoperable protocol artifacts and verification semantics are needed when independently operated systems exchange authority for actions whose consequences cannot safely be inferred from identity or bearer possession alone. 13. Adversarial Test Matrix +======+================================+========================+ | Test | Mutation or failure | Expected result | +======+================================+========================+ | T1 | Change one execution-relevant | Reject. | | | argument after authorization. | | +------+--------------------------------+------------------------+ | T2 | Replay an already consumed | Reject without | | | handle. | duplicate effect. | +------+--------------------------------+------------------------+ | T3 | Advance policy or delegation | Reject or require | | | epoch after handle issuance. | reauthorization. | +------+--------------------------------+------------------------+ | T4 | Strip required lineage | UNKNOWN; remain non- | | | metadata. | effective. | +------+--------------------------------+------------------------+ | T5 | Use a valid handle at a | Reject. | | | different sink. | | +------+--------------------------------+------------------------+ | T6 | Retry after ambiguous network | No duplicate effect. | | | timeout and committed effect. | | +------+--------------------------------+------------------------+ | T7 | Change a committed dependency | Reject if that | | | after the final upstream read. | dependency is declared | | | | execution-critical. | +------+--------------------------------+------------------------+ | T8 | Invoke an alternate | Path considered non- | | | effectuation path that omits | conformant or outside | | | finality verification. | governed coverage. | +------+--------------------------------+------------------------+ | T9 | Change tool or mapping | Reject or re-evaluate. | | | revision with identical high- | | | | level request text. | | +------+--------------------------------+------------------------+ | T10 | Present valid attestation | Reject the act while | | | evidence with an act outside | preserving attestation | | | authority. | result. | +------+--------------------------------+------------------------+ Table 4: Minimum Negative Tests Das Expires 23 March 2027 [Page 27] Internet-Draft Agentic Effectuation Boundary September 2026 14. Relationship to Current IETF Work OAuth deployments can provide delegated authorization, structured authorization detail, token sender constraint, and authorization context. Execution-finality can consume those artifacts rather than duplicate them. The distinguishing requirement is that the final effectuation component verifies the exact consequential act and any execution-critical current state. RATS and EAT can provide evidence about the platform, workload, or security state involved in issuing or consuming execution authority. Such evidence can become an input predicate without conflating attestation with transaction authorization. HTTP conditional requests provide a useful model for preventing a state-changing method from operating on a target representation that no longer matches an expected entity tag. High-consequence agentic systems may additionally depend on non-HTTP state, multiple resources, policy generations, physical state, delegated authority, or cross-service prerequisites. 15. Operational Considerations Not every agent action needs a high-assurance finality gate. A deployment can define consequence classes and require stronger enforcement only for high-value, irreversible, safety-relevant, or externally binding operations. This allows fast local verification on the hot path while slower logging, transparency, or anchoring mechanisms operate off the critical path. Implementers should explicitly document what the sink protects, which fields are part of the act digest, which states are revalidated, the lifetime of authority, crash recovery behavior, and known bypass paths. An assertion of "atomic authorization" without a documented failure model is not independently testable. 16. Privacy Considerations Execution handles should avoid carrying unnecessary personal or commercially sensitive information. Where feasible, the handle can carry commitments or opaque references while the sink retrieves the minimum state required for verification. Audit receipts should be designed to prove relevant facts without automatically becoming detailed activity-surveillance logs. Das Expires 23 March 2027 [Page 28] Internet-Draft Agentic Effectuation Boundary September 2026 17. Security Considerations The finality sink becomes a high-value target. Its key material, anti-replay state, policy epoch, canonicalization code, and commit adapter require protection commensurate with the consequence being governed. A sink that can be bypassed, rolled back, or induced to canonicalize two different acts identically does not provide the claimed property. Denial of service is a deliberate tradeoff of fail-closed enforcement. Deployments should distinguish states that truly require fresh verification from states that can be safely cached, and should define emergency procedures without creating an unaudited permanent bypass. Exact-act binding is only as strong as the chosen canonical form. Indirect effects, server-side defaults, wildcard expansion, schema upgrades, currency conversions, routing substitutions, or device-side transformations may need to be incorporated by digest, version, or explicit constraint. 18. Open Questions for the IETF Community 1. Which existing token or capability formats are most suitable for carrying exact-act commitments without creating a new token family? 2. Which state belongs in a portable protocol object and which state should remain sink-local? 3. How should cross-service dependency commitments be represented without turning every action into a distributed transaction? 4. What minimal evidence allows a relying party or auditor to distinguish a deployment with atomic consume semantics from one that merely claims them? 5. How should effectuation-path coverage be described when a device has multiple legacy, emergency, local, or hardware control paths? 6. Can Transaction Tokens, RATS evidence, OAuth authorization details, or COSE objects be profiled to express this boundary without duplicating existing standards? 19. IANA Considerations This document has no IANA actions. Das Expires 23 March 2027 [Page 29] Internet-Draft Agentic Effectuation Boundary September 2026 20. Additional Public Technical Resources The following non-normative resources provide broader architectural background and runnable reference material. Their inclusion does not make them part of the protocol requirements of this document. * The Internet Solved Communication. It Never Solved Authority. (https://zenodo.org/records/22082995) * Execution-Finality Architecture for Machine-Generated Acts. (https://github.com/sangmdas/Execution-Finality-Architechture-for- AI-Machines-) * tool_use Is Not invoke(): Runnable Agentic Tool-Call Reference Implementation. (https://github.com/sangmdas/tool_use-Is-Not- invoke-Binding-Execution-Finality-to-Agentic-Tool-Call-Interfaces- and-MCP) 21. Normative and Informative References [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, February 2020, . [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", RFC 9110, June 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, September 2023, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", RFC 9700, January 2025, . Das Expires 23 March 2027 [Page 30] Internet-Draft Agentic Effectuation Boundary September 2026 [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, April 2025, . [TXN-TOKENS] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, . Author's Address Sangam Das Independent Researcher Balasore Odisha India Email: info@sangamdas.com Das Expires 23 March 2027 [Page 31]