| Internet-Draft | Agentic Effectuation Boundary | September 2026 |
| Das | Expires 23 March 2027 | [Page] |
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.¶
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 23 March 2027.¶
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.¶
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.¶
The problem can be summarized as:¶
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?
¶
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 here | Equivalent or related industry terms | Underlying function |
|---|---|---|
| Candidate Act | transaction intent, command, job, API mutation, control action | The exact operation proposed before it is allowed to become effective. |
| Non-Effective State | staged state, prepared state, uncommitted state, pending command | The operation exists but has not yet produced its governed consequence. |
| Execution Handle | bounded capability, transaction authorization artifact, one-shot permit | Cryptographic or protected authority bound to an exact act and constraints. |
| Finality Sink | policy enforcement point, reference monitor, command gate, actuation gate, safety interlock, commit gate | The component or boundary whose successful action first makes the governed consequence effective. |
| Policy Epoch | generation number, fencing epoch, configuration version | A version marker used to reject authority created under stale policy or delegation state. |
| Act Binding | transaction binding, parameter binding, request-object binding | Cryptographic association between authority and the exact canonical operation. |
| Atomic Consume | check-and-commit, compare-and-swap, transactional consume, idempotency commit | Prevents the same authority from becoming the basis for multiple governed effects. |
| Path Completeness | complete mediation, anti-bypass, chokepoint enforcement | Ensures alternate paths cannot produce the same consequence without the required gate. |
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.¶
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.¶
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.¶
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.¶
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.
¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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?"
¶
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.¶
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.¶
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.¶
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.
¶
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.¶
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.¶
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
¶
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.¶
The candidate act is explicitly non-effective before final verification.¶
The final sink reconstructs or obtains the exact act that will become effective.¶
Authority is compared against that exact act, not merely against caller identity or broad scope.¶
Selected mutable state is revalidated at the effectuation boundary.¶
Authority reuse and crash/retry behavior are defined relative to the actual consequence.¶
Missing required provenance is UNKNOWN and fails closed rather than silently widening authority.¶
All materially equivalent effectuation paths are within the stated enforcement coverage.¶
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 venue | Relevant existing work | Potential relationship to this draft |
|---|---|---|
| OAuth | delegated authorization, RAR, DPoP, token exchange, Transaction Tokens | Primary integration point for authorization inputs and multi-hop authorization context. A profile could bind OAuth authorization to an exact execution commitment without redefining OAuth. |
| WIMSE | workload identity and least-privilege access across multi-service environments | Relevant when an agentic act crosses several workloads and the final sink must distinguish workload identity from authority for the final consequence. |
| RATS | remote attestation evidence, attestation results, appraisal, epoch-related state | Attestation can supply trustworthy state predicates to the finality sink. This draft keeps attestation evidence separate from act authorization. |
| COSE | CBOR signing, MAC, encryption, keys, and registered COSE attributes | Relevant if an execution handle or finality receipt needs a compact integrity-protected CBOR representation or new registered attributes. |
| ACE / CoRE | authorization and constrained application protocols for resource-constrained environments | Potential profile venue for constrained controllers, robots, gateways, or industrial devices where the effectuation sink is not a conventional web service. |
| DISPATCH / security dispatch process | routing new cross-cutting work and identifying overlap with existing WGs | Suitable first venue if no current WG owns the cross-domain effectuation-boundary invariant. |
| SAAG | cross-cutting Security Area discussion | Useful for threat-model review and architectural criticism. SAAG is a discussion forum rather than a document-adopting WG. |
The work can be decomposed rather than forcing one working group to standardize every layer:¶
Architecture / threat model: define the effectuation boundary, attacker model, and invariants.¶
Authorization profile: define how existing OAuth authorization details or transaction context bind to an exact act when OAuth is used.¶
Attestation binding: define how RATS results or epoch evidence become execution predicates without turning attestation into authorization.¶
Compact object format: reuse COSE/CBOR only if a portable execution-handle or receipt representation is needed.¶
Constrained-device profile: map the invariant to CoAP/ACE or device-local enforcement when an irreversible act occurs outside an HTTP service.¶
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.¶
The mechanisms below are complementary. This section describes the remaining boundary condition rather than a defect in those protocols.¶
| Mechanism | Primary property | Residual question at effectuation |
|---|---|---|
| OAuth authorization | Delegated access to a protected resource. | Does current authority bind the exact final act and current execution-critical state? |
| RAR | Structured authorization details. | Are the committed parameters exactly those details, and are later-changing prerequisites still satisfied? |
| DPoP | Sender-constrained token presentation. | Does the legitimate sender possess authority for this exact consequential act? |
| Transaction Tokens | Propagation of identity and authorization context through a call chain. | Is propagated context sufficient for a commit-time decision at the final consequence boundary? |
| RATS / EAT | Evidence and claims about entity/platform state. | Is this exact act authorized, current, single-use, and path-complete? |
| HTTP If-Match | Conditional method execution against a matching target representation. | What about non-resource dependencies, multiple resources, delegation epochs, physical actuation, or consequences outside one HTTP origin? |
The proposed architecture separates the ability to compute an act from the authority required to make that act effective.¶
+---------------------+
| 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
¶
A deployment defines a deterministic representation of the execution-relevant fields. One abstract form is:¶
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.¶
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.¶
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:¶
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.
¶
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.¶
A system claiming an execution-finality property for a governed class of acts should make the following properties externally reviewable:¶
EF-1 Exact-Act Binding: authority is bound to a deterministic representation of the execution-relevant act.¶
EF-2 Commit-Time Revalidation: state designated as execution-critical is checked at or immediately before the effectuation boundary.¶
EF-3 Anti-Replay: the same authority cannot silently create multiple governed effects unless multiplicity is explicitly authorized.¶
EF-4 Epoch/Fencing: revocation, policy change, delegation change, or schema revision can invalidate previously issued authority when the deployment requires it.¶
EF-5 Fail-Closed Unknowns: required but unavailable lineage or state is represented as UNKNOWN rather than inferred to mean unrestricted authority.¶
EF-6 Path Completeness: all paths capable of producing the governed consequence are included in the enforcement model or explicitly identified as exceptions.¶
EF-7 Sink-Local Verification: the effectuation component does not rely solely on an upstream statement that validation occurred.¶
EF-8 Recoverable Commit Semantics: crash, timeout, retry, and split-brain behavior cannot silently turn one authorized act into multiple effects.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
Anthropic describes current Claude models as capable of planning, using tools such as browsers and terminals, and running autonomously. See Introducing 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 and 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.¶
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?
¶
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 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.¶
| Test | Mutation or failure | Expected result |
|---|---|---|
| T1 | Change one execution-relevant argument after authorization. | Reject. |
| T2 | Replay an already consumed handle. | Reject without duplicate effect. |
| T3 | Advance policy or delegation epoch after handle issuance. | Reject or require reauthorization. |
| T4 | Strip required lineage metadata. | UNKNOWN; remain non-effective. |
| T5 | Use a valid handle at a different sink. | Reject. |
| T6 | Retry after ambiguous network timeout and committed effect. | No duplicate effect. |
| T7 | Change a committed dependency after the final upstream read. | Reject if that dependency is declared execution-critical. |
| T8 | Invoke an alternate effectuation path that omits finality verification. | Path considered non-conformant or outside governed coverage. |
| T9 | Change tool or mapping revision with identical high-level request text. | Reject or re-evaluate. |
| T10 | Present valid attestation evidence with an act outside authority. | Reject the act while preserving attestation result. |
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.¶
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.¶
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.¶
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.¶
Which existing token or capability formats are most suitable for carrying exact-act commitments without creating a new token family?¶
Which state belongs in a portable protocol object and which state should remain sink-local?¶
How should cross-service dependency commitments be represented without turning every action into a distributed transaction?¶
What minimal evidence allows a relying party or auditor to distinguish a deployment with atomic consume semantics from one that merely claims them?¶
How should effectuation-path coverage be described when a device has multiple legacy, emergency, local, or hardware control paths?¶
Can Transaction Tokens, RATS evidence, OAuth authorization details, or COSE objects be profiled to express this boundary without duplicating existing standards?¶
This document has no IANA actions.¶
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.¶