AI Safety and Accountability at the Effectuation Boundary: Protocol Requirements for Autonomous Actions

Introduction

Motivation: From AI Power to Enforceable Accountability Artificial intelligence systems are undergoing an important transition. Earlier AI deployments primarily produced information for humans to interpret. Increasingly, autonomous agents and AI-enabled workloads can directly invoke APIs, transmit information, release data, modify persistent state, dispatch tools, alter network configuration, communicate with other autonomous systems, control cloud infrastructure, transmit radio or satellite commands, and initiate cyber-physical actions. This changes the security and accountability problem. Where a human once stood between a machine recommendation and its consequence, an autonomous system may now move from computation to external action within milliseconds. The relevant question is therefore no longer only whether the AI system was authorized to operate. A second question arises: is the exact action about to become externally effective still the action that is currently authorized? This document calls the technical point at which a proposed operation acquires an externally meaningful consequence the effectuation boundary.

International Governance Motivation At the opening of the General Debate of the 81st Session of the United Nations General Assembly on 22 September 2026, Secretary-General Antonio Guterres described artificial intelligence as one of the major emerging tests of power. He stated that "the danger is not technology. The danger is technology without accountability," and further characterized the concern as "capability without oversight" and "decision-making without transparency." The Secretary-General called for governments with significant AI capabilities to cooperate on emerging safety risks, testing and evaluation, transparency, trust, and common safeguards, and warned against surrendering life-and-death decisions to machines. These statements define a governance challenge. They do not specify a network protocol, and they do not endorse the architecture described in this document. They nevertheless lead to a concrete engineering question: how can accountability remain technically enforceable when a machine-generated decision crosses from computation into consequence? The distinction matters because an AI system may be properly deployed, authenticated, and generally authorized while a particular action it generates may nevertheless be stale, substituted, redirected, replayed, outside its intended scope, or inconsistent with current authority. Execution finality is considered here as one possible technical architecture for addressing that narrower problem.

Machine Speed Removes the Traditional Intervention Window Many governance mechanisms historically relied, explicitly or implicitly, on time: a suspicious action could be reviewed, an operator could revoke access, a command could be cancelled, a transmission could be stopped, a configuration could be corrected, or an administrator could intervene before the next consequential step. Autonomous systems compress that intervention interval. A generated operation may pass through several layers without a human having practical opportunity to inspect the complete path: Human oversight therefore cannot always mean human-speed approval. A technically useful interpretation is that humans, organizations, operators, or other competent authorities define the permitted boundaries, while machine-speed infrastructure enforces those boundaries.

Governance Requirement Versus Technical Mechanism The governance layer may determine who is authorized, which resources may be used, which destinations are permitted, which actions are prohibited, when authority expires, what safety constraints apply, what consent or organizational approval is required, and under what circumstances authority must be revoked. This document does not standardize those decisions. Instead, it considers the technical mechanism needed to preserve such decisions until the point of actual consequence:

Governance: asks: what should be permitted?
Execution finality: asks: can the resulting technical system ensure that only the permitted action becomes externally effective?

Core Principle The architectural principle examined in this document is that computation does not itself confer authority to cause consequence. A machine may calculate, infer, generate, rank, recommend, plan, prepare, or request an operation; that computation alone need not provide the technical ability to make the operation externally effective. The resulting action can instead remain non-effective until required effectuation conditions are satisfied.

Context and Non-Endorsement This document references remarks by United Nations Secretary-General Antonio Guterres concerning artificial intelligence, accountability, oversight, transparency, and risks associated with increasingly autonomous systems. Those remarks are cited solely as public-policy motivation and contextual background for the technical problem examined here. No reference to the United Nations, the Secretary-General, or any related United Nations initiative should be understood as endorsement, validation, sponsorship, approval, or adoption of the execution-finality architecture, terminology, protocol concepts, implementation, intellectual property, or conclusions described in this document. The policy statements identify a broader governance concern; the technical architecture, analysis, terminology, and proposed protocol properties presented here are independently proposed by the author as one possible engineering approach for consideration and discussion by the IETF community. This document likewise does not suggest that the United Nations has determined that a new Internet protocol, IETF standard, or execution-finality mechanism is required.

Problem Statement

Authorization and Effectuation Are Not Necessarily the Same Event Consider an autonomous system that generates operation A. At time t1 the operation is authorized. At a later time t2 an operation is presented to a consequential boundary. The security assumption A_authorized == A_effectuated does not necessarily follow solely from the fact that authorization occurred at t1. Between the two points, the operation may be modified, substituted, redirected, replayed, duplicated, presented to another destination or another effectuation boundary, executed after revocation, executed against changed state, or affected by compromised software. The relevant problem is therefore: does the operation actually presented for effectuation still correspond to currently valid authority?

Example: Communication Release Assume the authorized action is: An intermediate compromise changes the pending operation to: The original authorization may remain cryptographically authentic. The question at the egress boundary is not merely whether some SEND operation was authorized -- it is whether this SEND operation, to this destination, under the current authority, is the operation that was authorized.

Example: Persistent State An autonomous service may receive authority to perform: but the operation eventually reaching the storage boundary may be: Again, caller identity may remain valid; the mismatch is in the consequential operation.

The Effectuation-Boundary Property The property considered in this document can be expressed as:

Why Verification Is Required at the Last Effectuation Boundary This section explains why verification at the last effectuation boundary is structurally important for agentic systems, rather than merely being one more place to put an authorization check.

Dynamic Agentic Execution Changes the Authorization Problem Traditional software is often designed around a comparatively predetermined execution path: an application receives an input, follows programmed logic, invokes known functions, and produces an expected class of output. Agentic systems can behave differently. An AI agent may begin with a high-level objective and then dynamically construct or revise a plan, select different tools, react to intermediate results, discover new resources, change the sequence of operations, choose a different destination, delegate work to another agent, retry through another service, or alter its next action as new context becomes available. The important security consequence is that the action contemplated when authority was initially granted may not be identical to the action eventually presented for execution: This does not necessarily mean the agent is malfunctioning -- dynamic replanning may be an intended feature of an agentic system. The security problem is therefore not simply whether the agent had legitimate authority when the workflow began; it is whether the specific action that emerged from the workflow remains within valid authority when that action is about to become consequential.

Early Authorization Can Become Semantically Stale Suppose an agent is initially authorized at Step 1 to perform a task. During subsequent execution the agent receives new information and revises its plan, and by Step 5 one or more consequential properties -- destination, resource, tool, operation, parameter, recipient, route, scope, execution context -- may have changed. The original authorization may still be cryptographically valid, the agent may still possess valid credentials, the communication channel may still be protected, and the agent identity may still be correct; nevertheless, the final operation may no longer correspond to the operation or scope originally authorized. The resulting problem can be represented as authority granted at Step 1, followed by the agent reasoning, observing, and replanning, followed by an action presented at Step 5, with the possibility that A(step1) != A(step5). This is why authorization only at workflow entry does not necessarily establish authorization of the final consequence.

Why Not Verify Only at Every Intermediate Step? Intermediate verification remains useful and may substantially reduce risk. This document does not discourage authorization at agent invocation, authorization before tool selection, authorization at service boundaries, workload identity, transaction-context propagation, policy checks, attestation, intermediate approval, or other defense-in-depth mechanisms. However, intermediate checks cannot by themselves establish the final effectuation property if the action may continue to change after those checks: for any check occurring at time t_n, a subsequent component or autonomous decision may produce A(t_n+1) != A(t_n). The last relevant verification therefore has a special property: no additional unverified transformation of the security-relevant action is permitted between that verification and the consequence it authorizes. For this reason, execution-finality verification is positioned at, or cryptographically coupled to, the last non-bypassable effectuation boundary.

The Last Irreversible or Externally Consequential Boundary The phrase "last irreversible boundary" should be understood functionally. Not every consequence is mathematically or physically impossible to reverse -- a later operation may attempt to delete transmitted information, restore a database, issue a compensating command, reverse a configuration, or recall an output. However, once an external consequence has occurred, restoration cannot necessarily recreate the state that existed before effectuation: a transmitted secret may already have been copied, a rendered output may already have been observed, a radio transmission may already have propagated, an API invocation may already have caused downstream actions, a physical actuator may already have changed the environment, and a persistent state transition may already have been consumed by another system. Accordingly, this document uses the term effectuation boundary to mean the last practical and non-bypassable technical point at which the proposed action can still be withheld before it produces the governed external consequence. This is the reason for placing final verification there.

The Boundary Observes the Action After Agentic Replanning The final effectuation component does not need to understand how the AI reasoned, reproduce the model's chain of reasoning, or decide whether the agent's plan was intelligent. Instead, it asks a much narrower question: what am I actually being asked to do now? The boundary determines or measures the security-relevant properties of the pending operation and compares them against the authority applicable to that effect. For example, the originally authorized action might be SEND object=dataset-X destination=service-A scope=analysis, while after several autonomous steps the actual operation presented at egress might be SEND object=dataset-X destination=service-B scope=external-transfer. The agent may have arrived at that result through legitimate autonomous reasoning, but that fact does not establish authority for the changed consequence. The final boundary therefore evaluates the authorized effect against the actual pending effect, rather than attempting to validate every reasoning step that produced it.

Why the Boundary, Not the AI Model, Holds Final Authority A central design objective is to avoid requiring the autonomous component to police itself. If the same agent that plans the action also has unrestricted authority to make the action real, then a failure, compromise, unexpected replanning decision, or misunderstood instruction inside that agent may directly produce the consequence. The execution-finality model instead separates reasoning and computation, which produce a proposed action, from authority to effectuate, which produces the external effect. The agent remains free to reason and re-plan within its computational environment; what it does not automatically obtain is the ability to make every resulting action consequential. This produces the invariant that an agent may change its plan, but authority does not automatically change with the plan -- a new action requires valid authority for that new action.

Why This Matters Specifically for Multi-Agent Systems The problem becomes more significant when multiple agents participate in one workflow, for example a human or enterprise delegating to Agent A, which delegates to Agent B, which invokes Tool C, which forwards to Service D, producing an external consequence. Each component may be correctly authenticated, and each delegation may be valid in isolation, but the cumulative workflow may produce an effect that was not explicitly represented when the original request began. For that reason, the final consequential component may need to answer independently: what exact effect am I about to produce, under whose authority, for which resource or destination, under which current state, and is that authority still valid for this effect? This is an interoperability question when different agents, authorization systems, tools, and effectuation components are operated by different vendors or administrative domains.

Architectural Consequence The execution-finality model therefore does not treat upstream authorization and final verification as interchangeable. Upstream authorization answers "may this workflow or actor proceed?" Effectuation-boundary verification answers "may this exact consequence occur now?" Both may be necessary. The latter is positioned at the last non-bypassable effectuation boundary because it is the final opportunity to detect divergence between initial intent, authorized operation, agentic evolution, and actual pending operation before external consequence occurs. Once the boundary is crossed, subsequent governance is generally remediation, compensation, attribution, or audit rather than prevention. The architectural objective can be summarized as: verify as early as useful, but verify the actual consequence as late as necessary -- immediately before effectuation. This is the reason the Finality Sink belongs at the last boundary.

Why This Is Not Merely an Application-Specific Problem A reasonable objection is that effectuation control could be treated as an application-design concern: each application could decide what operations require approval, how authority is represented, and how a final action is checked before execution. For a closed, single-vendor system operating entirely within one administrative trust domain, that may be sufficient, and this document does not argue that every local application requires a new Internet protocol. The standardization question arises when the authorization decision, autonomous reasoning, tool invocation, workload execution, and final effectuation occur across different implementations, vendors, administrative domains, or protocol layers. A representative deployment may resemble: In such an environment, no single application necessarily controls the complete path. The component making the initial authorization decision may not be the component that ultimately performs the consequential operation: the agent generating the operation may be supplied by one vendor, the tool may be operated by another, the authorization infrastructure may belong to a third organization, and the final network, storage, cloud, telecom, or actuator boundary may be controlled by yet another operator. The question therefore changes from "can one application internally decide whether its own action is allowed?" to "can independently implemented systems convey and verify a common understanding of what action was authorized and whether the action presented at the final boundary still corresponds to that authority?" That is an interoperability question.

The Missing Interoperability Semantics Without common semantics, each implementation may independently define concepts such as action identity, destination binding, resource binding, effectuation boundary, sink identity, freshness, authorization generation, replay state, single-use authority, state consumption, and verification evidence. Two systems may therefore agree that an authorization object is cryptographically valid while disagreeing about what that object authorizes. For example, an authorization service might record "resource-X may be released to service-A," which may be interpreted downstream by an agent as "resource-X may be processed by workflow-Y," while the final infrastructure component sees only SEND resource-X TO endpoint-Z. All three components may be functioning correctly according to their local implementations. The failure occurs because there is no shared representation connecting authorized intent, authorized action, and actual pending effect. This is precisely the class of problem for which protocol standardization can become relevant.

Cross-Boundary Authority Cannot Be Assumed from Local Policy Application-specific policy is useful when the application controls both the decision and the effect. That assumption weakens in distributed and agentic systems. Consider a chain in which Agent A delegates to Agent B, which calls Tool C, which requests Cloud Service D, which dispatches to Network, Storage, or Device E. Each transition may cross a trust or administrative boundary: an upstream component may know why the action was authorized, while the downstream component knows what physical or logical effect is actually about to occur. Neither component necessarily has enough information alone. The protocol problem is therefore the preservation and verification of the relationship between those two facts. A standardized mechanism could allow the downstream component to determine, in an interoperable way, which action or action class was authorized, which destination or resource was authorized, which boundary may accept the authority, whether the authority is still fresh, whether it has already been consumed, whether a relevant authorization generation has changed, and whether the actual operation presented locally corresponds to the authorized operation. Without common semantics, these properties remain bilateral implementation agreements.

The Multi-Vendor Case The need becomes clearer in heterogeneous deployments, for example an enterprise policy system from Vendor A, authorization infrastructure from Vendor B, an AI agent platform from Vendor C, an external tool from Vendor D, and a cloud, telecom, or storage boundary from Vendor E. Vendor E cannot safely be expected to understand Vendor C's private internal representation of agent intent. Vendor C cannot necessarily know Vendor E's local effectuation state. Vendor B cannot predict every later tool selection or autonomous re-planning decision. If these systems are expected to interoperate, they need either bilateral proprietary integrations between every relevant pair of implementations, or a shared representation and verification model. The second case is the potential IETF problem.

Agentic Replanning Makes Private Workflow Semantics Insufficient The issue is especially relevant to autonomous agents because the final operation may not be known when the original workflow begins. An agent may receive an objective, query a service, interpret the result, revise its plan, choose another tool, and only then generate the consequential action. An authorization system at the start of that sequence cannot necessarily encode every concrete property of the operation that will emerge at the end of it. Likewise, the component that finally acts cannot safely infer unlimited authority merely from the fact that the workflow was authorized at its outset. This creates a need to preserve authority across a changing execution chain while still allowing the final boundary to evaluate the action that actually emerged. That requirement becomes difficult to solve purely inside one application when different parts of the chain are operated by different parties.

Why Existing Authentication Alone Does Not Solve the Interoperability Problem Cross-domain systems already possess mechanisms for identifying callers and protecting messages, answering questions such as who a workload is, who issued a token, whether a message was modified, whether a credential is valid, and whether a sender is entitled to present it. The additional question considered here is different: does this credential or authority object correspond to this exact consequential operation, as observed by this final component, now? Answering that question across independently implemented systems requires agreement about more than identity. It may require interoperable semantics for action, resource, destination, scope, boundary, freshness, state, consumption, and evidence. This is where application-specific authorization can become an Internet interoperability problem.

Standardization Does Not Require Standardizing Business Policy A standardized effectuation mechanism would not need to specify whether a particular action is legally, commercially, ethically, or organizationally permitted; those decisions remain application or policy specific. For example, a protocol might standardize how to express action=SEND resource=object-123 destination=service.example boundary=egress-7 epoch=42 nonce=N123 without defining whether sending object-123 to that destination should be allowed. The distinction is between policy, which asks whether an action should be permitted, and protocol, which asks how different systems can represent, bind, carry, and verify the resulting authority. IETF protocols commonly standardize the latter while leaving the former to applications and operators.

When This Remains Application-Specific This document does not claim that execution-finality semantics require Internet standardization in every deployment. A local mechanism may be sufficient where one operator controls the complete execution path, all components share one implementation, authorization and effectuation occur inside one trusted system, no cross-vendor interpretation is required, and no authority context crosses administrative boundaries. In such systems, implementation-specific mechanisms may provide the required property. Standardization becomes more relevant when authority crosses administrative domains, autonomous agents invoke third-party tools, multiple vendors participate in one action chain, the final effectuation component did not make the original authorization decision, effectuation metadata must survive multiple protocol hops, independently developed systems must agree on action identity and binding, or a downstream verifier must understand authority issued upstream. This defines the proposed interoperability threshold.

The IETF Question The question for the IETF community is therefore not whether the IETF should standardize how every application decides whether an AI action is safe. It is: when independently implemented Internet components participate in an autonomous action chain, is there a need for common semantics that allow the component controlling the final consequence to verify that the exact action presented to it remains within currently valid upstream authority? If existing protocols already provide all of the required semantics, this document should identify how they are composed. If only an application profile is required, that may be the appropriate outcome. If important cross-vendor semantics remain unspecified, then additional standardization may be justified. The objective is therefore not to move application policy into the network; it is to determine whether authority-to-effect binding across independently implemented systems is an interoperability property that requires common protocol semantics. In one sentence: the application decides what should be allowed; standardization may be needed when multiple independent systems must agree on what was allowed and verify that the same action is the one actually about to become effective.

Mapping the Cross-Vendor Problem to Existing IETF Work The cross-vendor problem described in the previous section does not necessarily require invention of an entirely new protocol stack. Several existing and emerging IETF mechanisms already provide important parts of the required architecture, including fine-grained authorization, sender constraint, transaction-context propagation, workload identity, remote attestation, and agent-to-agent or agent-to-tool protocol context. The open question is whether those mechanisms, individually or in combination, provide sufficient interoperable semantics for the last effectuation boundary to determine that the action actually presented for effectuation corresponds to the action and authority currently permitted. This section therefore maps the effectuation-finality requirements to relevant IETF work without assuming that any one working group should own the complete problem.

OAuth The OAuth Working Group (Web Authorization Protocol) provides a natural starting point for representing and carrying authorization across administrative boundaries. Rich Authorization Requests (RFC 9396). RFC 9396 defines the authorization_details parameter for carrying structured, fine-grained authorization requirements rather than relying only on coarse scope strings. It allows authorization details associated with particular resource or access types to be expressed in structured JSON and assigned to an access token . An execution-finality profile could investigate whether such authorization details can represent security-relevant properties such as action, resource, destination, permitted scope, effect class, and effectuation boundary. The important question is not whether RAR already defines execution finality -- it does not. The question is whether RAR provides an appropriate existing extensibility mechanism for expressing the authorized side of an exact-action comparison. For example: The remaining issue is how a downstream effectuation component determines whether its locally observed pending operation matches those authorization details. DPoP (RFC 9449). DPoP provides sender-constrained OAuth tokens and protects against some forms of token theft and replay. A DPoP proof binds cryptographic proof to properties including the HTTP method, HTTP URI, proof identifier, and, when applicable, the access-token hash . This is highly relevant, but it addresses a different property. DPoP can help establish that a presenter possesses the key associated with an authorization. Effectuation-boundary verification may additionally require that the consequence a presenter is asking a resource to produce is the consequence that was authorized. RFC 9449 does not generally bind the DPoP proof to an arbitrary canonical representation of an application payload or final physical or logical effect. An IETF discussion could therefore ask whether certain applications need an additional profile or binding mechanism connecting sender-constrained authorization to an application-defined canonical action descriptor. This document does not propose modifying DPoP itself as a prerequisite. Transaction Tokens. Transaction Tokens are particularly relevant to multi-hop autonomous workflows because authorization and identity context may need to survive a chain of intermediary workloads. A representative path may be: Transaction context can help downstream services understand the origin and security context of the transaction. The execution-finality question is what the last consequential component should do with that context -- specifically, should the final component compare propagated transaction context against the operation it independently observes locally before allowing the consequence? If so, additional interoperable semantics may be needed for exact-action representation, destination or resource binding, effectuation-boundary identity, freshness, single-use or bounded authority, consumption state, and finality evidence. The purpose is not to duplicate Transaction Tokens, but to determine whether a final-effect verification profile can reuse them.

WIMSE The Workload Identity in Multi System Environments (WIMSE) Working Group is directly relevant to the multi-vendor case. Its charter explicitly addresses workloads distributed across trust boundaries, situations without a single centralized controller, propagation of context across multi-hop and asynchronous transactions, fine-grained least privilege, and cryptographic binding of tokens to workload identity and optionally to transactions. This overlaps strongly with the infrastructure through which autonomous actions may travel. Workload identity is necessary but not always sufficient. WIMSE can help answer which workload is making a request, which workload originated the transaction, what security context accompanied it, and to which workload that context is bound. The execution-finality question adds a further one: what exact consequential operation is the final workload or boundary about to perform? The current WIMSE architecture already discusses propagation and augmentation of security context from workload to workload and binding context to transactions, which makes WIMSE a potentially strong foundation. However, this document asks whether a further interoperable profile is needed when the downstream component must compare propagated authority context against the locally observed pending effect. Context preservation across agentic replanning. This becomes especially relevant when autonomous intermediaries change the execution path, for example when Enterprise Authority delegates to Agent B, which delegates to Agent C, which selects Tool D, which reaches Infrastructure E. The original security context may be propagated correctly; however, Agent C may legitimately choose a different tool or operation after receiving new information. The key issue is therefore not necessarily preserving an immutable historical plan -- indeed, requiring an immutable plan would conflict with the adaptive nature of many agentic systems. The stronger requirement is that any changed consequential action must still be evaluated against authority applicable to that changed action before effectuation. WIMSE may provide the workload identity and transaction-context plumbing; execution-finality semantics would address the final comparison between that propagated context and the actual pending consequence.

RATS Remote ATtestation procedureS (RATS) provides another important building block. RFC 9334 defines an architecture in which an Attester produces Evidence, a Verifier appraises that Evidence, and a Relying Party consumes Attestation Results when making application-specific decisions; Evidence may include measurements, configuration information, telemetry, or related claims . This is relevant because an effectuation-boundary verifier may itself need to be trusted. Attestation of the verification environment. A remote party may need evidence that the component performing effectuation verification is running an expected implementation or configuration. RATS can potentially provide evidence concerning the enforcement component, protected execution environment, firmware or software measurement, configuration, cryptographic identity, and relevant platform state. A policy or authorization service could use Attestation Results as one input when deciding whether to trust that component. Important limitation. Attestation should not be described as proving that a particular finality decision was correctly executed. RFC 9334 provides evidence and appraisal about an Attester's state; the Relying Party then uses the Attestation Result as part of its own decision process. Acceptable measured state does not automatically prove that a specific pending action was correctly authorized and effectuated. The two can complement one another: RATS can help establish confidence in the environment performing verification, while execution-finality semantics determine what that environment must verify before permitting the consequence. A possible composition is:

AgentProto The proposed Agent Communication Protocols (AgentProto) Working Group is particularly relevant because its charter is explicitly concerned with interoperable user-to-agent, agent-to-agent, and agent-to-tool dialogs across platforms, intermediaries, and trust boundaries. The current proposed charter includes propagation of protocol-level dialog context across multiple intermediaries and explicitly identifies coordination with OAuth, WIMSE, RATS, and related security work . As of September 2026, AgentProto remains in initial chartering, so this document does not describe it as an established WG deliverable. Dynamic agent interaction. AgentProto addresses an environment where Agent A, Agent B, and Tool C may involve multiple hops, changing context, different vendors, and multiple trust boundaries. That environment is directly relevant to execution finality because the concrete consequential operation may not exist when the dialog begins, for example when a user provides an objective, an agent obtains information, another agent contributes context, a tool is selected, and only then does the final consequential operation emerge. The security requirement therefore cannot always be represented as an immutable first-step action. Instead, the authority context must survive the workflow while allowing later actions to be checked when they become concrete. Separation of concerns. A useful separation could be layered as: AgentProto maintains the agentic dialog and context; OAuth and WIMSE provide identity and authority context; RATS provides evidence about trusted components; and effectuation verification determines the actual pending consequence and compares it with current authority before permitting or denying the effect. AgentProto need not define AI reasoning, planning semantics, or tool-specific business logic, which are explicitly outside its proposed scope. Likewise, an execution-finality mechanism need not define agent communication. The possible interoperability point is the security context that must survive until the consequential operation becomes concrete.

Why No Single Working Group Solves the Whole Problem The cross-vendor effectuation problem spans several distinct properties: OAuth addresses fine-grained delegated authorization; WIMSE addresses workload identity and multi-hop security context; RATS addresses evidence about execution and verification environments; AgentProto addresses agentic dialog and context propagation; the application or resource carries the semantic meaning of the requested operation; and the effectuation boundary determines the actual consequence about to occur. None of these layers should be unnecessarily duplicated. The architectural question is whether they can be composed so that the final effectuation component receives sufficient trustworthy information to determine: what authority exists; to which action or bounded action class it applies; whether that authority is still fresh; which boundary may consume it; what operation is actually pending locally; whether the authorized and actual operations match; whether the authority has already been consumed; and whether the decision can be evidenced if required. If existing IETF mechanisms can express all of these properties through an agreed profile, a new standalone protocol may not be required. If they cannot, the remaining gap can be identified precisely rather than creating a parallel authorization system.

Possible Standardization Path This document therefore does not begin from the assumption that a new execution-finality protocol must be created. A more conservative standards path is to identify the effectuation-boundary requirements, map each requirement to existing IETF mechanisms, identify properties already fully satisfied, identify interoperability gaps, and determine whether those gaps require implementation guidance, an application profile, extensions to existing work, a reusable security object, or a new protocol mechanism. This approach avoids duplicating OAuth, WIMSE, RATS, AgentProto, or other existing work, and provides a concrete basis for cross-WG discussion.

Questions for the Relevant IETF Communities The mapping above leads to specific questions. For OAuth. Can existing OAuth mechanisms, including RAR, sender-constrained authorization, and Transaction Tokens, express enough information for a downstream resource to verify that the actual consequential operation remains within the authorization originally granted? If not, what minimal additional application-profile semantics are required? For WIMSE. Can transaction-bound workload context carry the security-relevant authority information required across a multi-hop agentic workflow while allowing the final workload to validate the operation it is actually about to perform? For RATS. What attestation evidence or results would be appropriate for establishing trust in an effectuation-boundary verifier without incorrectly treating attestation as proof that each individual effectuation decision was correct? For AgentProto. Which authorization and security context should be preserved through an agentic dialog so that a downstream tool or effectuation component can make its own final authorization decision? Should the dialog protocol merely carry references to such context, leaving final-effect semantics to another security building block? Cross-WG question. Most importantly: can existing IETF mechanisms be composed into an interoperable model in which one vendor can authorize an action, multiple independent agents or workloads can process it, and a different vendor's final effectuation component can verify that the action actually presented remains within current authority before allowing the consequence? If the answer is yes, the useful standards output may be a composition or profile. If the answer is no, the remaining gap should be identified narrowly before proposing new protocol machinery.

Terminology and Functional Equivalence This document uses several terms to describe functional roles. These terms do not require implementations to use the same names. Terms and Functional Interpretations

Term	Functional interpretation
Candidate Act	proposed or pending operation
Non-Effective State	staged, uncommitted, or non-effectuated operation
Act Descriptor	canonical machine-verifiable description of the proposed operation
Protected Enforcement Domain	protected enforcement point, reference monitor, authority-validation component
Scoped Non-Bearer Capability	narrowly bounded effectuation authority
Finality Sink	effectuation gate, commit boundary, egress gate, actuator gate
Sink-Side Reconstruction	local operation derivation or actual-action measurement
Finality Receipt / LAVR	protected verification or enforcement evidence

The underlying architecture distinguishes an upstream machine-verifiable description of what is authorized from a sink-side description of what is actually presented for effectuation. The sink-side function exists to detect mismatch between those two states.

Threat Model The architecture assumes that an operation may be legitimately generated and authorized while one or more subsequent components cannot be fully trusted. The threat model includes the following:

Action Substitution. An authorized operation is replaced by another operation before effectuation.
Destination Substitution. The operation type remains the same but its destination changes.
Parameter Modification. One or more consequential parameters are altered after authorization.
Replay. Previously valid authority is reused to create another consequence.
Duplicate Effectuation. A valid action is executed more than once.
Cross-Sink Use. Authority intended for one effectuation boundary is presented to another.
Stale Authority. Authority was valid when issued but is revoked or superseded before effectuation.
Policy-Generation Change. The policy epoch or authorization generation changes between approval and execution.
Compromised Intermediate Component. An application, runtime, operating system, driver, proxy, network component, orchestrator, or controller modifies the operation.
Compromised Autonomous Agent. An AI agent may possess valid credentials while generating an unintended or unauthorized specific action.
TOCTOU. The action checked at one location differs from the action actually used at the effectuation point.
Crash and Recovery. A system verifies authority, performs an effect, crashes before recording consumption, and later repeats the effect.
Rollback. Protected state is restored to an earlier point at which consumed authority appears valid again.

The architecture therefore does not assume that the AI model, application, operating system, or every intermediate component remains trustworthy after upstream authorization.

Architectural Requirements The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. R1 -- Non-Effectuation Before Verification. A governed action MUST NOT become externally effective until the required effectuation-boundary verification succeeds. R2 -- Exact-Act Binding. Authority MUST be bound to the security-relevant attributes needed to distinguish the authorized operation from a substituted operation. R3 -- Boundary Binding. Authority MUST identify the intended effectuation boundary, sink, or permitted boundary class where such distinction is security-relevant. R4 -- Freshness. The architecture MUST provide a means to detect stale or replayed authority. R5 -- Current Protected State. Effectuation verification MUST account for protected state whose change would invalidate the operation. R6 -- Actual-Action Verification. The effectuation component MUST determine, measure, reconstruct, derive, or otherwise verify the security-relevant operation actually presented for effectuation. R7 -- Fail-Closed Handling. If information required for effectuation cannot be validated, the governed operation MUST NOT become externally effective. R8 -- Consumption and Atomicity. Where authority is single-use or bounded, the system MUST prevent verify → effectuate → crash → reuse same authority → effectuate again. Authority therefore needs to be consumed, reserved, invalidated, state-advanced, or otherwise made non-reusable before or atomically with effectuation. R9 -- Revocation. The effectuation component MUST have a mechanism for determining whether relevant authority has been revoked, expired, superseded, or invalidated. R10 -- Sink-Side Independence. The effectuation component MUST NOT depend solely on an upstream assertion of what operation is being performed when security-relevant attributes can be determined locally. R11 -- Unknown State. Where a required value cannot be established, UNKNOWN != AUTHORIZED. A missing value MUST NOT automatically be interpreted as a valid default. R12 -- Evidence. Deployments requiring accountability SHOULD generate protected evidence of successful or failed effectuation verification. R13 -- Least Effectuation Authority. Authorization SHOULD convey only the authority required for the specified action or bounded action class. R14 -- No Unguarded Equivalent Path. A system claiming this property MUST NOT expose another unguarded path capable of producing the same governed consequence.

Execution-Finality Model The model separates four logical functions: COMPUTE, VALIDATE AUTHORITY, VERIFY AT EFFECTUATION BOUNDARY, and EFFECTUATE. A conceptual flow is: The significant property is not the names of these components. The property is that ExternalEffect depends on SuccessfulBoundaryVerification, rather than ExternalEffect automatically following UpstreamRequest.

Sink-Side Reconstruction and Actual-Action Verification

Purpose The effectuation component should know what it is actually being asked to do. This document uses sink-side reconstruction as shorthand for determining the security-relevant properties of the pending local operation. It does not mean rerunning an AI model, and it does not require reproducing model reasoning. It means answering: what operation am I actually about to effectuate?

Examples A network egress boundary could derive: A storage boundary could derive: A tool-execution boundary could derive: An actuator boundary could derive:

Comparison Let D_A be the authorized descriptor and D_S the sink-derived descriptor. Effectuation proceeds only if Match(D_A, D_S, CurrentState) == TRUE. The matching function may use exact equality for some fields and constrained or range-based matching for others.

Relationship to Existing Internet Security Mechanisms This section is deliberately framed as a relationship analysis, not as a claim that existing mechanisms are defective.

OAuth OAuth provides delegated authorization. Its current charter explicitly includes new mechanisms and extensions for automated agents acting on behalf of users and across multiple administrative domains. RFC 9396 additionally provides Rich Authorization Requests, allowing fine-grained authorization details to be conveyed in OAuth messages . These mechanisms may provide important inputs to effectuation-boundary verification. The question raised by this document is narrower: does an interoperable OAuth deployment also need standardized semantics for determining that the operation actually presented at the final consequence boundary is still the operation described by the authorization? This document does not assume the answer must be a new OAuth mechanism -- it asks whether the property can be expressed using existing OAuth mechanisms, application profiles, transaction context, or additional protocol elements.

DPoP and Sender-Constrained Authorization RFC 9449 defines DPoP as an application-layer proof-of-possession mechanism for sender-constraining OAuth tokens . Sender constraint addresses an important question -- is the presenter authorized to use this token? Effectuation-boundary verification may additionally require: does this token authorize this exact locally observed consequence? The two properties may be complementary.

Transaction Tokens The OAuth Transaction Tokens work propagates user identity, workload identity, and authorization context through a call chain inside a trust domain, and the current draft explicitly discusses compromised workloads, parameter modification, and narrowly scoped transaction context . This makes Transaction Tokens highly relevant. An important question for this work is whether Transaction Token context can represent and preserve enough information to bind authorization to a final consequential operation, and whether the final resource or effectuation component needs additional semantics for reconstruction, exact-effect comparison, consumption, crash consistency, and finality evidence.

RATS RFC 9334 defines an architecture for generating, conveying, and evaluating evidence about whether another entity is in an intended operating state . RATS evidence may therefore provide useful information about platform state, workload state, trusted components, and measurement results. Execution finality asks a related but distinct question: even if this component is in an acceptable state, is this exact pending action authorized to become consequential now? A deployment could therefore use RATS evidence as an input to an effectuation decision rather than replacing either architecture.

WIMSE The WIMSE working group addresses workload identity and fine-grained least-privilege access across multiple service platforms. Its charter includes token solutions that may carry caller identity, transaction binding, attestation context, and other information. This document is relevant to WIMSE where an identified and authorized workload eventually initiates a consequential action after traversing multiple services. The open question is whether workload identity plus transaction context is sufficient, or whether some applications also require explicit authorized-action-to-actual-effect binding at the final resource boundary.

COSE COSE provides CBOR-based structures for signatures, MACs, encryption, keys, and related protected attributes; its working group focuses on cryptographic object formats and associated parameters. COSE may therefore be useful as an encoding or protection substrate for an execution-finality object. This document does not propose that COSE itself determine effectuation policy.

Agent Communication Protocols The proposed Agent Communication Protocols work is especially relevant. Its current proposed charter addresses user-to-agent, agent-to-agent, and agent-to-tool interactions, protocol context propagation, identity, authentication, authorization, security, and interoperability across agentic systems, and it explicitly distinguishes protocol mechanisms from AI reasoning and behavior . Effectuation-boundary verification may intersect with this work where agent dialog leads to an agent decision, which leads to a tool invocation, which leads to a real external effect. The relevant question is whether agent-protocol context should carry information sufficient for a downstream tool or resource to verify the consequential action, or whether effectuation finality belongs in a separate reusable security building block. As of September 2026, AgentProto is still in initial chartering rather than an established adopted WG program, so the relationship should be discussed rather than assumed.

Why This Is Relevant to the IETF This problem is relevant to the IETF only if it contains an interoperability dimension. A purely local implementation choice does not necessarily require protocol standardization. The potential interoperability problem appears when different administrative domains, vendors, workloads, agents, authorization systems, and effectuation components need to communicate what action was authorized, for which destination, at which boundary, under which freshness state, under which authorization generation, with which evidence, and under which consumption semantics. For example: If each component uses private semantics for action identity, destination binding, replay state, transaction context, sink identity, consumption, or finality evidence, then cross-vendor verification becomes difficult. The possible IETF problem is therefore not "how should an AI decide what to do?" It is: how can independently implemented Internet components interoperably convey and verify the authority needed for an autonomous action to become consequential?

Potential Protocol Interaction Model This document does not require a new wire format. A generic realization may contain four logical objects.

Action Descriptor Every field in this descriptor is subject to the canonicalization and semantic-equivalence requirements in ; a descriptor that is cryptographically valid but semantically ambiguous is not valid effectuation authority.

Authority Decision

Bounded Effectuation Authority

Effectuation Verification The exact representation is intentionally left open for IETF discussion.

Failure and Recovery Semantics

Verification Failure If required verification fails, there is no effect. Implementations may suppress, quarantine, discard, defer, request fresh authority, or return an error.

Timeout Failure to obtain required verification information must not automatically become authorization.

Crash Before Effectuation A crash before final effect should leave the operation non-effective where technically possible.

Crash After Effectuation Recovery must distinguish "effect never happened" from "effect happened but accounting state did not complete." Otherwise duplicate effectuation may occur.

Partial Effects Compound actions may require separate finality boundaries for individual irreversible sub-actions.

Latency Considerations Execution-finality verification does not require every policy computation to occur in the latency-critical path. A deployment may separate a control path from a hot effectuation path. Expensive work may occur earlier, including policy evaluation, attestation, authority issuance, trust establishment, revocation refresh, and credential validation. The final effectuation path may perform only bounded operations such as descriptor matching, nonce verification, sink binding, signature or MAC verification, generation checking, and protected-state transition. The requirement is not to recompute all governance policy at the final boundary. The requirement is that the final boundary must possess enough trustworthy information to determine whether the pending consequence is currently authorized.

Deployment and Legacy Compatibility Execution finality is intended to coexist with existing protocols. A deployment may continue to use TLS, HTTP, OAuth, RAR, DPoP, Transaction Tokens, workload identity, RATS evidence, JWT, CWT, COSE, and application-specific policy systems; these mechanisms may supply inputs to the decision. The architectural change is that selected consequential operations become dependent on successful final verification. Legacy systems may remain upstream provided they cannot bypass the governed effectuation path.

Security Considerations Implementations need to consider at least: action substitution; destination substitution; parameter modification; replay; cross-sink presentation; stale authorization; generation mismatch; revocation; compromised workloads; confused deputy; TOCTOU; rollback; duplicate effectuation; alternate bypass paths; compromised verification state; and canonicalization disagreement. Particular attention is required for canonicalization. Two components that semantically interpret an action differently could compute the same protocol flow while believing different consequences are authorized. Therefore, any standardized descriptor format would need unambiguous canonicalization and comparison semantics.

Canonicalization, Semantic Equivalence, and Descriptor Interpretation Execution-finality security depends not only on cryptographic integrity but also on semantic agreement between the component that authorizes an action and the component that verifies the action at the effectuation boundary. Two implementations MUST NOT be allowed to interpret the same ActionDescriptor as authorizing materially different consequences. The relevant invariant is therefore not merely Hash(Descriptor_A) == Hash(Descriptor_B), but Meaning(Descriptor_A) == Meaning(Descriptor_B) for all security-relevant fields. A descriptor that is cryptographically authentic but semantically ambiguous MUST NOT be treated as valid effectuation authority. 1. Canonical Representation. Any field included in a signature, MAC, digest, capability binding, or protected authorization object MUST have a deterministic canonical representation. Implementations MUST agree on field names, field types, field ordering where ordering is significant, byte encoding, string encoding, normalization rules, integer representation, timestamp representation, URI representation, identifier representation, treatment of optional and duplicate and unknown fields, representation of arrays and sets, and canonical representation of nested objects. Implementations MUST NOT independently invent normalization rules for security-relevant fields. Where JSON is used, a deterministic canonicalization mechanism such as the JSON Canonicalization Scheme (JCS) may be appropriate; where CBOR is used, deterministic encoding rules SHOULD be used where the encoded form participates in cryptographic binding. The specific encoding is not mandated by this architecture, but one interoperable encoding profile MUST define one deterministic interpretation. 2. Unknown, Missing, Empty, and Null Are Different States. A particularly dangerous source of cross-implementation disagreement is treating missing, null, empty, unknown, and default as equivalent. They MUST NOT be assumed equivalent where the field affects effectuation authority: destination = "" is not necessarily equivalent to an absent destination, and neither is necessarily equivalent to destination = UNKNOWN. For required security-relevant attributes, UNKNOWN MUST NOT be converted into EMPTY, DEFAULT, or AUTHORIZED: UNKNOWN != EMPTY, UNKNOWN != DEFAULT, UNKNOWN != AUTHORIZED. If a required value cannot be determined, the effectuation component MUST fail closed unless the applicable profile explicitly defines another safe interpretation. This rule is especially important for destination, resource, scope, action class, boundary identity, sink identity, policy generation, authorization state, provenance, freshness, and protected-state references. 3. Type Confusion MUST Be Prevented. Implementations MUST NOT treat values as equivalent merely because they render similarly: "42" must not automatically equal 42, true must not equal "true", and null must not be interpreted as false, unless the relevant profile explicitly defines such equivalence. Security-sensitive descriptors SHOULD use a schema that assigns one unambiguous type to every field. 4. Duplicate Fields. Duplicate object members can create severe parsing inconsistencies -- different parsers may accept the first, accept the last, reject the structure, or preserve both. An execution-finality profile MUST define one behavior; the safest rule is that a descriptor containing duplicate security-relevant member names MUST be rejected. 5. Unicode and String Normalization. Textual identifiers can have multiple byte representations while appearing visually identical, which matters especially for internationalized domain names, user identifiers, resource names, filesystem paths, tool names, tenant identifiers, and jurisdiction identifiers. An implementation MUST NOT perform undocumented Unicode normalization after authorization but before comparison; where a normalized representation is used, the normalization method MUST be specified by the profile and applied consistently before cryptographic binding. 6. URI and Endpoint Canonicalization. URLs and network endpoints are particularly dangerous because multiple textual forms may refer to the same resource, while superficially similar forms may refer to different resources -- https://example.com/a and https://example.com/a/ may have different application semantics, and example.com and example.com:443 may or may not be treated equivalently. Profiles using URIs or endpoints MUST define exactly which URI components participate in the authorization comparison and how they are normalized; implementations MUST NOT rely on visual similarity. 7. Numeric Values and Units. Numeric ambiguity is especially dangerous for autonomous infrastructure: the value 42 has no interoperable meaning unless both parties agree whether it represents bytes, milliseconds, degrees, percent, volts, or some other unit. Where a numeric value affects the consequence, the descriptor SHOULD bind the value together with its unit or defined semantic type, for example {"parameter":42,"unit":"percent"} rather than {"parameter":42}. Floating-point values SHOULD be avoided in security-critical equality comparisons unless their representation and comparison semantics are explicitly defined. 8. Set Versus Sequence Semantics. A descriptor must specify whether a collection is ordered or unordered -- ["read","write"] must not be assumed equivalent to ["write","read"] unless the profile defines the field as a set. Canonicalization must therefore preserve semantic collection type, not merely serialized form. 9. Default Values. Implicit defaults are dangerous across implementation boundaries: if Vendor A interprets an absent scope as read-only while Vendor B interprets the same absence as unrestricted, a valid signature could authorize different consequences in the two systems. For security-relevant fields, defaults MUST either be explicitly encoded or be defined identically by the applicable interoperability profile; security-sensitive defaults SHOULD generally be explicit. 10. Versioning. ActionDescriptor semantics will evolve, so a descriptor SHOULD identify the semantic profile or version under which it is interpreted, for example descriptor_profile = "ef-action-v1". A verifier MUST NOT silently interpret a descriptor under a newer or different semantic model; if the verifier does not understand the declared profile or version, the result SHOULD be UNSUPPORTED, and, for a required finality check, NO EFFECT. 11. Unknown Extension Fields. Extensibility must not create downgrade or interpretation attacks. A verifier encountering an unknown field must know whether that field is optional or critical; a useful model permits extension fields while allowing security-critical extensions to be marked as requiring recognition, and if an unknown field is marked critical, verification MUST fail. This prevents an authorizing system's essential field from being silently ignored by the verifier and producing an unintended effect. 12. Semantic Comparison Must Occur After Canonical Interpretation. The Finality Sink SHOULD NOT simply compare serialized byte strings when the locally observed action originates from a different representation. Instead, both the authorized object and the sink-observed operation should be mapped into the same defined canonical semantic representation before equality or constrained matching is performed: D_A = Canonicalize(AuthorizedAction), D_S = Canonicalize(SinkObservedAction), Match(D_A, D_S). The canonicalization function MUST itself be part of the security specification. 13. Matching Does Not Always Mean Byte Equality. Some operations require bounded authorization rather than exact byte-for-byte equality -- an authorized temperature range of 20 to 25 could permit a requested temperature of 23, and an authorized destination class of *.internal.example may permit a specific internal service. The profile MUST therefore distinguish exact equality from range constraint, set membership, prefix constraint, resource class, and bounded quantity, with explicit and deterministic comparison semantics; a verifier MUST NOT invent broader interpretation than the authorizing component expressed. 14. Canonicalization Is Part of the Trusted Computing Base. Canonicalization MUST NOT be treated as cosmetic serialization logic; in this architecture it is part of the security boundary. An attacker who can cause the authorizer's meaning of a value to differ from the verifier's meaning of the same value may bypass exact-act binding even without stealing a key, forging a signature, compromising TLS, breaking an HSM, or compromising the AI model. This class of vulnerability is therefore equivalent to an authorization failure, and the canonicalization and semantic-interpretation code SHOULD be kept small, deterministic, testable, and suitable for independent conformance testing. 15. Cross-Language Conformance. Interoperability testing SHOULD include implementations written in different programming languages; for every normative descriptor test vector, interpretations across languages such as Python, Go, Rust, Java, and JavaScript should agree for every security-relevant semantic field. Testing only one serializer and parser implementation is insufficient because many canonicalization vulnerabilities emerge from differences between runtime libraries. 16. Negative Test Vectors. A standard should include adversarial vectors in addition to valid examples, covering cases such as duplicate keys, unknown fields, unknown critical fields, null versus absent, empty versus absent, Unicode equivalents and confusables, URI normalization differences, numeric type differences, overflow, negative and out-of-range values, unexpected arrays, field and nested-object reordering, alternate encodings, stale versions, unsupported profiles, malformed timestamps, timezone differences, duplicate identifiers, case differences, trailing separators, and percent encoding. Each vector should specify one expected interoperable result -- ACCEPT, DENY, INVALID, or UNSUPPORTED -- and conforming implementations should not be permitted to disagree about a security-relevant interpretation. 17. Canonicalization Failure Is a Finality Failure. The effectuation boundary MUST NOT attempt best-effort interpretation when canonicalization fails. If the descriptor cannot be parsed, cannot be canonicalized, cannot be interpreted, is semantically ambiguous, contains an unsupported critical field, or produces a canonicalization disagreement, the result is NO EFFECT. This preserves the execution-finality invariant. 18. Security Invariant. The descriptor security property can therefore be expressed as VerifyCrypto(D) == TRUE is necessary but not sufficient. Effectuation additionally requires: Security rationale. A signature establishes integrity over a representation. It does not by itself establish that all participating implementations assign the same meaning to that representation. For execution-finality systems, semantic interoperability is therefore part of authorization security itself. The protocol must ensure not merely that two parties agree on the bytes that were signed, but that they agree on the consequence those bytes authorize. The security objective is not merely canonical bytes. It is canonical consequence.

Privacy Considerations An effectuation descriptor can itself contain sensitive information. Potentially sensitive fields include destination, resource, user identity, workload identity, operation class, purpose, jurisdiction, timing, and authorization context. Implementations should minimize disclosed fields, using techniques such as hashes, opaque references, selective disclosure, local derivation, encrypted claims, and protected evidence references. Execution-finality mechanisms must not create an unnecessary cross-domain surveillance record merely in the name of accountability.

IETF Relevance and Possible Venues The architecture crosses several existing areas of work. No single group should be assumed to own the complete problem.

OAuth: Relevant to delegated authority, automated-agent authorization, RAR, DPoP, and transaction context. OAuth's current charter explicitly includes complex delegation for automated agents.
WIMSE: Relevant to workload identity, multi-hop execution, transaction binding, least privilege, and workload context.
RATS: Relevant to protected evidence, attestation, measured state, and verifier results.
COSE: Potentially relevant to compact signed effectuation objects and cryptographically protected attributes.
AgentProto: Potentially relevant to agent-to-agent and agent-to-tool context, autonomous action workflows, and cross-vendor agent interoperability.
DISPATCH: Potentially relevant as the venue for deciding whether the problem belongs in an existing WG, needs a cross-WG design effort, requires a new focused venue, or should remain application-specific. The current DISPATCH charter explicitly exists to evaluate new work across ART, SEC and non-transport WIT, identify overlap with existing protocols, and find an appropriate home rather than doing the protocol work itself.

Questions for the IETF Community This section is deliberately positioned as one of the most visible parts of this document. The posture of this draft is: here is the governance-driven technical problem, here are the properties believed to matter -- which existing IETF mechanisms already satisfy them, which do not, and where, if anywhere, should the remaining work live? This gives reviewers something concrete to answer instead of forcing them to accept or reject the entire execution-finality architecture. Q1. Is the problem real? Does the IETF community agree that there is a useful distinction between "this caller is authorized" and "this exact consequential operation, as locally presented at the final boundary, is currently authorized"? If not, which existing specification already provides the equivalent property? Q2. Can existing OAuth mechanisms express the required semantics? Can RFC 9396 authorization details, DPoP, Transaction Tokens, token exchange, or related OAuth mechanisms fully express exact-act binding, sink or boundary binding, local actual-action comparison, current protected state, single-use or bounded consumption, and crash-consistent effectuation? If they can, should an application profile specify how? Q3. Is transaction context enough? Transaction Tokens carry authorization context through a call chain. Should a final resource be required to compare that context against the operation it is actually about to perform? If so, is this already implied by normal application authorization semantics, or would interoperable behavior benefit from specification? Q4. What should "exact action" mean across implementations? How should independently developed systems agree on the identity of an action? Should standardization define action class, destination, resource, effect class, parameter set, and canonical representation, or should those semantics remain entirely application-specific? Q5. Where should reconstruction occur? Should an effectuation component derive the consequential operation from the incoming request, local pending state, a protected descriptor, a device or controller representation, an application transaction object, or some combination? Q6. Should actual-action measurement be standardized? Is "what was authorized" versus "what is actually about to happen" a general protocol abstraction worthy of standardization, or is it inherently application-specific? Q7. How should authorization be consumed? For operations where replay creates another consequence, should specifications define single-use authority, reservations, epochs, compare-and-commit, monotonic state, or idempotency semantics? Q8. How should crash consistency be represented? How should an interoperable protocol distinguish "authorized but not effectuated" from "effectuated but acknowledgement lost" from "authority already consumed"? Q9. How does this relate to RATS? Should an effectuation component use RATS Evidence or Attestation Results to establish its own trusted state, upstream protected state, the integrity of an action descriptor, or the integrity of the measurement path? What should remain outside RATS? Q10. How does this relate to AgentProto? Should an agentic dialog carry sufficient context for downstream tools to determine who requested the action, on whose behalf, under which authority, for which intended effect, and whether that authority remains valid? Or should AgentProto only propagate dialog context while another security mechanism controls final effectuation? Q11. Is a new protocol needed at all? Could the required property be achieved using a profile composed entirely from OAuth, RAR, DPoP, Transaction Tokens, WIMSE, RATS, COSE, and existing application protocols? If so, documenting that composition may be preferable to inventing another protocol. Q12. Where is the correct standards boundary? Possible alternatives include: (A) application-specific implementation guidance; (B) an OAuth profile; (C) a WIMSE profile; (D) an AgentProto security building block; (E) a RATS integration profile; (F) a general effectuation-boundary architecture; or (G) a new protocol object or exchange. Which level produces genuine interoperability value? Q13. Is fail-closed behavior always appropriate? For which classes of consequence should unresolved authority result in no effect, and where might availability requirements justify different semantics? Q14. How should multi-agent delegation be treated? If a human delegates to Agent A, which delegates to Agent B, which invokes Tool C, which reaches Infrastructure D, which component carries the authority chain, and which component ultimately verifies the exact effect? Q15. What evidence is actually useful? Should successful and denied effectuation produce standardized receipts? If so, who consumes them, what information is necessary, how is privacy preserved, and how are receipts protected from becoming surveillance metadata?

Requested Community Feedback This document specifically requests feedback on four points:

Whether the effectuation-boundary problem is sufficiently distinct from ordinary authorization to justify explicit treatment.
Whether existing IETF mechanisms already provide all required properties when correctly composed.
If gaps remain, whether they are best addressed through profiles of existing work or through additional interoperable objects or protocol semantics.
Which IETF venue, if any, is appropriate for further work.

The author does not assume that execution finality must become a new standalone protocol. A useful outcome of community review would also be a determination that existing IETF mechanisms already provide the required properties and that the missing work is merely deployment guidance or application profiling.

IANA Considerations This document has no IANA actions.

Conclusion Autonomous and AI-enabled systems increasingly compress the distance between computation and consequence. The broader governance concern has been stated clearly by the UN Secretary-General as the danger of technological capability operating without adequate accountability, oversight, and transparency. The protocol question is narrower. An authenticated and authorized system may still present an action at a consequential boundary that differs from the action originally authorized, or that is no longer valid under current state. Execution finality treats this as an explicit architectural property: the action actually presented for effectuation is verified against currently valid authority before the consequence is permitted. The central invariant is that computation is not authority. This document does not presume that a new protocol is required. It asks the IETF community to determine whether the property is already covered by existing or emerging work, whether profiles or compositions are sufficient, and, if not, what additional interoperable mechanisms would be appropriate.