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

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

1.2. 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. [UNGA81]¶

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

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

AI / Agent
    |
    v
Application
    |
    v
Runtime
    |
    v
Operating System
    |
    v
Proxy / Driver / Gateway
    |
    v
Network / Controller / Device
    |
    v
External Consequence

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

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

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

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

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

2.2. Example: Communication Release

Assume the authorized action is:¶

SEND:
    object      = confidential-report
    destination = approved-service-A

An intermediate compromise changes the pending operation to:¶

SEND:
    object      = confidential-report
    destination = service-B

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

2.3. Example: Persistent State

An autonomous service may receive authority to perform:¶

WRITE:
    resource  = object-X
    namespace = tenant-A

but the operation eventually reaching the storage boundary may be:¶

WRITE:
    resource  = object-X
    namespace = tenant-B

Again, caller identity may remain valid; the mismatch is in the consequential operation.¶

2.4. The Effectuation-Boundary Property

The property considered in this document can be expressed as:¶

ExternalEffect(A)
    ONLY IF
AuthorizedDescriptor(A) matches ActualPresentedOperation(A)
AND CurrentAuthority == VALID
AND Freshness == VALID
AND ProtectedState == VALID
AND EffectuationBoundary == AUTHORIZED

Otherwise: NO EFFECT

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

Initial User / System Objective
            |
            v
        Step 1 -- Initial Plan
            |
            v
        Step 2 -- Tool Result
            |
            v
        Step 3 -- New Context
            |
            v
        Step 4 -- Re-planning
            |
            v
        Step 5 -- Different Action, Target,
                 Parameter, Route, or Tool
            |
            v
   External Consequence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1. 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 [RFC9396].¶

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

Authorization Infrastructure
        |
        | structured authorization_details
        v
Agent / Workload
        |
        v
Downstream Resource

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 [RFC9449].¶

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

User / Enterprise
       |
       v
Agent A
       |
       v
Agent B
       |
       v
Tool C
       |
       v
Service D
       |
       v
Effectuation Boundary

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

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

5.3. 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 [RFC9334]. 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:¶

RATS
  |
  | establishes evidence about verifier state
  v
Trusted Effectuation Component
  |
  | compares actual action with authority
  v
Effect / No Effect

5.4. 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 [AGENTPROTO]. 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.¶

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

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

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

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

10.2. Examples

A network egress boundary could derive:¶

action          = TRANSMIT
destination     = endpoint-A
payload_digest  = H(payload)
route_class     = external

A storage boundary could derive:¶

action          = WRITE
resource        = object-X
namespace       = tenant-A
content_digest  = H(content)

A tool-execution boundary could derive:¶

action          = INVOKE
tool            = service-X
operation       = operation-Y
target_resource = object-Z

An actuator boundary could derive:¶

action          = ACTUATE
device          = controller-X
command         = OPEN
parameter       = 42

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

11.1. 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 [RFC9396]. 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.¶

11.2. DPoP and Sender-Constrained Authorization

RFC 9449 defines DPoP as an application-layer proof-of-possession mechanism for sender-constraining OAuth tokens [RFC9449]. 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.¶

11.3. 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 [OAUTH-TXN]. 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.¶

11.4. RATS

RFC 9334 defines an architecture for generating, conveying, and evaluating evidence about whether another entity is in an intended operating state [RFC9334]. 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.¶

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

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

11.7. 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 [AGENTPROTO]. 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.¶

13.1. Action Descriptor

ActionDescriptor = {
    action_id,
    action_class,
    source,
    destination,
    resource,
    effect_class,
    scope,
    boundary_id,
    sink_id,
    nonce,
    policy_epoch,
    freshness,
    evidence_refs
}

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

13.2. Authority Decision

Decision = Validate(
    ActionDescriptor,
    AuthorityContext,
    CurrentState,
    RevocationState,
    PolicyGeneration
)

13.3. Bounded Effectuation Authority

EffectuationAuthority = Protect({
    descriptor_digest,
    scope,
    sink_id,
    boundary_id,
    nonce,
    policy_epoch,
    expiry,
    state_ref,
    evidence_ref
})

13.4. Effectuation Verification

Actual = DetermineActualPendingOperation()
if !VerifyAuthority():
    DENY
if !Match(Authorized, Actual):
    DENY
if !Fresh():
    DENY
if !CurrentStateValid():
    DENY
if !CorrectBoundary():
    DENY
ConsumeOrReserveAuthority()
EFFECTUATE

The exact representation is intentionally left open for IETF discussion.¶

14.1. Verification Failure

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

14.2. Timeout

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

14.3. Crash Before Effectuation

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

14.4. Crash After Effectuation

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

14.5. Partial Effects

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

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

Parse(D) == VALID
AND Canonicalize(D) == VALID
AND Semantics(D) == UNDERSTOOD
AND AuthorizedMeaning(D_A) matches ObservedMeaning(D_S)
AND CurrentState == VALID

Only then: EFFECT
Otherwise: NO EFFECT

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