AI Safety and Accountability at the Effectuation Boundary: Protocol Requirements for Autonomous Actions
draft-das-accountable-autonomous-effectuation-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-accountable-autonomous-effectuation-01
Independent Submission S. Das
Internet-Draft Independent
Intended status: Informational 23 September 2026
Expires: 27 March 2027
AI Safety and Accountability at the Effectuation Boundary: Protocol
Requirements for Autonomous Actions
draft-das-accountable-autonomous-effectuation-01
Abstract
Artificial intelligence and autonomous systems are increasingly
moving from generating information to initiating actions that
directly affect data, services, networks, infrastructure, and
physical systems. At the opening of the General Debate of the 81st
Session of the United Nations General Assembly, UN Secretary-General
Antonio Guterres warned of "technology without accountability,"
describing the concern further as "capability without oversight" and
"decision-making without transparency," and called for cooperation on
AI safety risks, testing, evaluation, transparency, and common
safeguards.
This document examines that problem from governance intent to
consequence-edge verification protocols: the corresponding technical
question is how can accountability remain enforceable at the moment a
machine-generated decision becomes an externally consequential
action? It defines an effectuation-boundary problem in which a
proposed action may be correctly authenticated and authorized
upstream, yet the operation ultimately presented for execution may
differ because of substitution, redirection, replay, stale authority,
changed state, compromised intermediaries, or other causes.
An execution-finality architecture is presented as one possible
technical response. A proposed operation remains non-effective until
applicable authority and protected-state conditions are satisfied,
and the component controlling the external consequence verifies that
the operation actually presented for effectuation corresponds to
currently valid authority.
This document does not define AI governance policy, and it does not
imply endorsement of this architecture by the United Nations or any
other institution. It is intended to solicit IETF discussion about
whether effectuation-boundary accountability constitutes an
interoperability or protocol requirement, which existing mechanisms
can provide the required properties, and whether any additional
standardization is necessary.
Das Expires 27 March 2027 [Page 1]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
About This Document
This note is to be removed before publishing as an RFC.
Subtitle: From Governance Intent to Consequence-Edge Verification
Protocols.
This document is complementary to two other drafts by the same
author: [EXEC-FINALITY], which describes the broader execution-
finality protocol layer, and [EXEC-HANDLE], which specifies exact-act
binding, sink reconstruction, atomic consumption, and receipts in
more depth. This draft does not re-specify that architecture; it
asks whether the effectuation-boundary property is an
interoperability requirement, which existing IETF mechanisms already
provide it, and where remaining gaps should be addressed.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
Das Expires 27 March 2027 [Page 2]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
1.1. Motivation: From AI Power to Enforceable
Accountability . . . . . . . . . . . . . . . . . . . . . 5
1.2. International Governance Motivation . . . . . . . . . . . 5
1.3. Machine Speed Removes the Traditional Intervention
Window . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Governance Requirement Versus Technical Mechanism . . . . 6
1.5. Core Principle . . . . . . . . . . . . . . . . . . . . . 7
1.6. Context and Non-Endorsement . . . . . . . . . . . . . . . 7
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Authorization and Effectuation Are Not Necessarily the Same
Event . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Example: Communication Release . . . . . . . . . . . . . 8
2.3. Example: Persistent State . . . . . . . . . . . . . . . . 8
2.4. The Effectuation-Boundary Property . . . . . . . . . . . 8
3. Why Verification Is Required at the Last Effectuation
Boundary . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Dynamic Agentic Execution Changes the Authorization
Problem . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Early Authorization Can Become Semantically Stale . . . . 10
3.3. Why Not Verify Only at Every Intermediate Step? . . . . . 11
3.4. The Last Irreversible or Externally Consequential
Boundary . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. The Boundary Observes the Action After Agentic
Replanning . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Why the Boundary, Not the AI Model, Holds Final
Authority . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Why This Matters Specifically for Multi-Agent Systems . . 12
3.8. Architectural Consequence . . . . . . . . . . . . . . . . 13
4. Why This Is Not Merely an Application-Specific Problem . . . 13
4.1. The Missing Interoperability Semantics . . . . . . . . . 14
4.2. Cross-Boundary Authority Cannot Be Assumed from Local
Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. The Multi-Vendor Case . . . . . . . . . . . . . . . . . . 15
4.4. Agentic Replanning Makes Private Workflow Semantics
Insufficient . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Why Existing Authentication Alone Does Not Solve the
Interoperability Problem . . . . . . . . . . . . . . . . 16
4.6. Standardization Does Not Require Standardizing Business
Policy . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7. When This Remains Application-Specific . . . . . . . . . 17
4.8. The IETF Question . . . . . . . . . . . . . . . . . . . . 17
5. Mapping the Cross-Vendor Problem to Existing IETF Work . . . 18
5.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. AgentProto . . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Why No Single Working Group Solves the Whole Problem . . 23
5.6. Possible Standardization Path . . . . . . . . . . . . . . 24
Das Expires 27 March 2027 [Page 3]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
5.7. Questions for the Relevant IETF Communities . . . . . . . 24
6. Terminology and Functional Equivalence . . . . . . . . . . . 25
7. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Architectural Requirements . . . . . . . . . . . . . . . . . 27
9. Execution-Finality Model . . . . . . . . . . . . . . . . . . 28
10. Sink-Side Reconstruction and Actual-Action Verification . . . 29
10.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 30
10.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . 30
11. Relationship to Existing Internet Security Mechanisms . . . . 31
11.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.2. DPoP and Sender-Constrained Authorization . . . . . . . 31
11.3. Transaction Tokens . . . . . . . . . . . . . . . . . . . 31
11.4. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.5. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.6. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.7. Agent Communication Protocols . . . . . . . . . . . . . 32
12. Why This Is Relevant to the IETF . . . . . . . . . . . . . . 33
13. Potential Protocol Interaction Model . . . . . . . . . . . . 33
13.1. Action Descriptor . . . . . . . . . . . . . . . . . . . 34
13.2. Authority Decision . . . . . . . . . . . . . . . . . . . 34
13.3. Bounded Effectuation Authority . . . . . . . . . . . . . 34
13.4. Effectuation Verification . . . . . . . . . . . . . . . 35
14. Failure and Recovery Semantics . . . . . . . . . . . . . . . 35
14.1. Verification Failure . . . . . . . . . . . . . . . . . . 35
14.2. Timeout . . . . . . . . . . . . . . . . . . . . . . . . 35
14.3. Crash Before Effectuation . . . . . . . . . . . . . . . 35
14.4. Crash After Effectuation . . . . . . . . . . . . . . . . 35
14.5. Partial Effects . . . . . . . . . . . . . . . . . . . . 35
15. Latency Considerations . . . . . . . . . . . . . . . . . . . 36
16. Deployment and Legacy Compatibility . . . . . . . . . . . . . 36
17. Security Considerations . . . . . . . . . . . . . . . . . . . 36
17.1. Canonicalization, Semantic Equivalence, and Descriptor
Interpretation . . . . . . . . . . . . . . . . . . . . . 37
18. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
19. IETF Relevance and Possible Venues . . . . . . . . . . . . . 42
20. Questions for the IETF Community . . . . . . . . . . . . . . 43
21. Requested Community Feedback . . . . . . . . . . . . . . . . 45
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
23. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 45
24. Normative References . . . . . . . . . . . . . . . . . . . . 46
25. Informative References . . . . . . . . . . . . . . . . . . . 46
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction
Das Expires 27 March 2027 [Page 4]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 5]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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:
Das Expires 27 March 2027 [Page 6]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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. Problem Statement
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,
Das Expires 27 March 2027 [Page 7]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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:
Das Expires 27 March 2027 [Page 8]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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. 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.
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:
Das Expires 27 March 2027 [Page 9]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 10]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 11]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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
Das Expires 27 March 2027 [Page 12]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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. 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:
Das Expires 27 March 2027 [Page 13]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
User / Enterprise Authority
|
v
Authorization Service A
|
v
Agent B
|
v
Agent C
|
v
Tool D
|
v
Service E
|
v
Infrastructure / Effectuation
Boundary F
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.
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.
Das Expires 27 March 2027 [Page 14]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 15]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 16]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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?
Das Expires 27 March 2027 [Page 17]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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. 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.
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].
Das Expires 27 March 2027 [Page 18]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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:
Das Expires 27 March 2027 [Page 19]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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?
Das Expires 27 March 2027 [Page 20]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 21]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
*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.
Das Expires 27 March 2027 [Page 22]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 23]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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
Das Expires 27 March 2027 [Page 24]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
6. Terminology and Functional Equivalence
This document uses several terms to describe functional roles. These
terms do not require implementations to use the same names.
+=====================+=========================================+
| 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 | protected enforcement point, reference |
| Enforcement Domain | monitor, authority-validation component |
+---------------------+-----------------------------------------+
| Scoped Non-Bearer | narrowly bounded effectuation authority |
| Capability | |
+---------------------+-----------------------------------------+
| Finality Sink | effectuation gate, commit boundary, |
| | egress gate, actuator gate |
+---------------------+-----------------------------------------+
| Sink-Side | local operation derivation or actual- |
| Reconstruction | action measurement |
+---------------------+-----------------------------------------+
| Finality Receipt / | protected verification or enforcement |
| LAVR | evidence |
+---------------------+-----------------------------------------+
Table 1: Terms and Functional Interpretations
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.
Das Expires 27 March 2027 [Page 25]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
7. 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:
1. *Action Substitution.* An authorized operation is replaced by
another operation before effectuation.
2. *Destination Substitution.* The operation type remains the same
but its destination changes.
3. *Parameter Modification.* One or more consequential parameters
are altered after authorization.
4. *Replay.* Previously valid authority is reused to create another
consequence.
5. *Duplicate Effectuation.* A valid action is executed more than
once.
6. *Cross-Sink Use.* Authority intended for one effectuation
boundary is presented to another.
7. *Stale Authority.* Authority was valid when issued but is
revoked or superseded before effectuation.
8. *Policy-Generation Change.* The policy epoch or authorization
generation changes between approval and execution.
9. *Compromised Intermediate Component.* An application, runtime,
operating system, driver, proxy, network component,
orchestrator, or controller modifies the operation.
10. *Compromised Autonomous Agent.* An AI agent may possess valid
credentials while generating an unintended or unauthorized
specific action.
11. *TOCTOU.* The action checked at one location differs from the
action actually used at the effectuation point.
12. *Crash and Recovery.* A system verifies authority, performs an
effect, crashes before recording consumption, and later repeats
the effect.
13. *Rollback.* Protected state is restored to an earlier point at
which consumed authority appears valid again.
Das Expires 27 March 2027 [Page 26]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
The architecture therefore does not assume that the AI model,
application, operating system, or every intermediate component
remains trustworthy after upstream authorization.
8. 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
[RFC2119] [RFC8174] 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.
Das Expires 27 March 2027 [Page 27]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
*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.
9. Execution-Finality Model
The model separates four logical functions: COMPUTE, VALIDATE
AUTHORITY, VERIFY AT EFFECTUATION BOUNDARY, and EFFECTUATE. A
conceptual flow is:
Das Expires 27 March 2027 [Page 28]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
+-----------------------------+
| AI / Agent / Application |
+--------------+--------------+
|
| generates
v
+-----------------------------+
| Proposed Action |
| Status: NON-EFFECTIVE |
+--------------+--------------+
|
v
+-----------------------------+
| Protected Authority Check |
+--------------+--------------+
|
| valid bounded authority
v
+-----------------------------+
| Effectuation Boundary |
| |
| Determine Actual Operation |
| Verify Binding |
| Check Freshness |
| Check Current State |
+---------+-------------------+
|
+---+---+
| |
PASS FAIL
| |
v v
EFFECT NO EFFECT
The significant property is not the names of these components. The
property is that ExternalEffect depends on
SuccessfulBoundaryVerification, rather than ExternalEffect
automatically following UpstreamRequest.
10. Sink-Side Reconstruction and Actual-Action Verification
Das Expires 27 March 2027 [Page 29]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 30]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
11. Relationship to Existing Internet Security Mechanisms
This section is deliberately framed as a relationship analysis, not
as a claim that existing mechanisms are defective.
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.
Das Expires 27 March 2027 [Page 31]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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
Das Expires 27 March 2027 [Page 32]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
12. 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:
Vendor A Agent
|
v
Vendor B Authorization Service
|
v
Vendor C Workload
|
v
Vendor D Tool
|
v
Vendor E Infrastructure Boundary
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?
13. Potential Protocol Interaction Model
This document does not require a new wire format. A generic
realization may contain four logical objects.
Das Expires 27 March 2027 [Page 33]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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
})
Das Expires 27 March 2027 [Page 34]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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. Failure and Recovery Semantics
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.
Das Expires 27 March 2027 [Page 35]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
15. 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.
16. 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.
17. 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.
Das Expires 27 March 2027 [Page 36]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 37]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
*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.
Das Expires 27 March 2027 [Page 38]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
*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-
Das Expires 27 March 2027 [Page 39]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
Das Expires 27 March 2027 [Page 40]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
*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.*
Das Expires 27 March 2027 [Page 41]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
18. 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.
19. 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.
Das Expires 27 March 2027 [Page 42]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
20. 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?
Das Expires 27 March 2027 [Page 43]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
*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?
Das Expires 27 March 2027 [Page 44]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
*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?
21. Requested Community Feedback
This document specifically requests feedback on four points:
1. Whether the effectuation-boundary problem is sufficiently
distinct from ordinary authorization to justify explicit
treatment.
2. Whether existing IETF mechanisms already provide all required
properties when correctly composed.
3. If gaps remain, whether they are best addressed through profiles
of existing work or through additional interoperable objects or
protocol semantics.
4. 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.
22. IANA Considerations
This document has no IANA actions.
23. 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.
Das Expires 27 March 2027 [Page 45]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
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.
24. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
25. Informative References
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, January 2023,
<https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396, May 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, September 2023,
<https://www.rfc-editor.org/rfc/rfc9449>.
[OAUTH-TXN]
Tulshibagwale, A., "Transaction Tokens", Work in Progress,
draft-ietf-oauth-transaction-tokens, 2026.
[AGENTPROTO]
IETF, "Agent Communication Protocols", Proposed IETF
Working Group charter, Work in Progress, 2026.
[UNGA81] Guterres, A., "Address to the Opening of the General
Debate of the 81st Session of the General Assembly",
United Nations, 22 September 2026.
Das Expires 27 March 2027 [Page 46]
Internet-Draft AI Safety at the Effectuation Boundary September 2026
[EXEC-FINALITY]
Das, S., "The Missing Protocol Layer for the Agentic
Internet: Computation Is Not Authority", Work in Progress,
draft-das-execution-finality-protocol-layer, 2026.
[EXEC-HANDLE]
Das, S., "Possession Is Not Authority: Execution Handle,
Sink Verification, Atomic Consumption, and Finality
Receipt", Work in Progress, draft-das-execution-handle,
2026.
[TECH-DISCLOSURE]
Das, S., "The Missing Execution-Finality Layer", Zenodo
record 22082995, 2026.
Author's Address
Sangam Das
Independent
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 27 March 2027 [Page 47]