Independent Researcher

Balasore Odisha IN info@sangamdas.com

Security AI agents execution finality authorization critical infrastructure robotics payments effectuation boundary 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.

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.

Problem Sequence The problem can be summarized as: 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? ]]>

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. Functional Equivalence

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.

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.

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.

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.

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.

High-Attention Threat Scenarios

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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:

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.

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.

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

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.

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.

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.

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

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. Relationship to IETF Groups

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.

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.
5. Constrained-device profile: map the invariant to CoAP/ACE or device-local enforcement when an irreversible act occurs outside an HTTP service.

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.

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. Complementary Controls and Residual Boundary Question

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?

Execution-Finality Architecture The proposed architecture separates the ability to compute an act from the authority required to make that act effective.

Canonical Candidate Act A deployment defines a deterministic representation of the execution-relevant fields. One abstract form is: 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.

Act-Bound Execution Authority A representative execution handle can be modeled as: 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.

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:

Check-and-Effect Semantics 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.

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.

Domain Profiles

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.

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.

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.

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.

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

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. 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? ]]>

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

Adversarial Test Matrix Minimum Negative Tests

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.

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.

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.

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.

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.

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?

IANA Considerations This document has no IANA actions.

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.
• Execution-Finality Architecture for Machine-Generated Acts.
• tool_use Is Not invoke(): Runnable Agentic Tool-Call Reference Implementation.

Normative and Informative References