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