Network Working Group S. Das Internet-Draft Independent Inventor Intended status: Informational 26 August 2026 Expires: 27 February 2027 Execution-Finality for Agentic AI Tool Dispatch draft-das-agentic-execution-finality-00 Abstract Agentic AI systems can translate model outputs directly into tool calls, API requests, browser actions, shell commands, memory writes, messages, delegated acts, and other externally effective operations. Conventional authentication or tool access can establish that an agent may reach a tool without establishing that a particular generated act is authorized to take effect. This document defines an Agent Candidate Act and Tool-Dispatch Finality Sink model. A proposed agent action is held in a Non- Effective State while a Protected Enforcement Domain validates act- specific predicates such as agent identity, instruction provenance, tool and function identity, argument scope, purpose, destination, policy and revocation state, and intended sink. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer finality authority. The dispatch sink independently verifies that authority immediately before the tool or external action executes. The design is fail-closed and includes replay resistance, single-use authority, sink binding, policy-epoch checking, revocation, and alternate-path closure. The core principle is: tool selection is not tool-execution authority, and computation is not authority. This revision also defines a concrete JSON-based interoperability profile for Agent Candidate Acts, protected validation evidence, scoped finality authority, and Tool-Dispatch Sink verification, enabling protocol and API implementers to evaluate a specific interface rather than only an architectural concept. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Das Expires 27 February 2027 [Page 1] Internet-Draft Agentic Execution Finality August 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 February 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 2. Core Execution-Finality Protocol . . . . . . . . . . . . . . 4 2.1. Core Architectural Principle . . . . . . . . . . . . . . 4 2.2. scoped non-bearer finality authority is released; . . . . 4 2.3. an applicable Finality Sink independently verifies that authority; and . . . . . . . . . . . . . . . . . . . . . 4 2.4. the finality authority and associated protected state are consumed, invalidated, advanced, or otherwise made unsuitable for unauthorized replay. . . . . . . . . . . 4 2.5. Scoped Non-Bearer Finality Authority . . . . . . . . . . 9 2.6. Second Boundary — Independent Finality Sink Verification . . . . . . . . . . . . . . . . . . . . . . 9 2.7. Successful Effectuation . . . . . . . . . . . . . . . . . 10 2.8. Sink-side finality evidence recorded . . . . . . . . . . 11 2.9. Why This Is Different From Ordinary App Permissions . . . 11 2.10. Agentic-AI Enforcement Example . . . . . . . . . . . . . 12 2.11. Protocol Invariant . . . . . . . . . . . . . . . . . . . 13 3. Agent Candidate Act and Dispatch Sink Interface . . . . . . . 14 3.1. Embodiment A — Agentic AI and Autonomous Tool Use . . . . 14 3.1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . 14 Das Expires 27 February 2027 [Page 2] Internet-Draft Agentic Execution Finality August 2026 3.1.2. Agent Candidate Act . . . . . . . . . . . . . . . . . 15 3.1.3. Agentic PED Validation . . . . . . . . . . . . . . . 16 3.1.4. Tool-Dispatch Finality Sink . . . . . . . . . . . . . 16 4. JSON API and Schema for Agent Candidate Acts . . . . . . . . 17 4.1. JSON Encoding Conventions . . . . . . . . . . . . . . . . 18 4.2. AgentCandidateAct Object . . . . . . . . . . . . . . . . 18 4.3. ProtectedValidationEvidence Object . . . . . . . . . . . 25 4.4. AgentFinalityAuthority Object . . . . . . . . . . . . . . 26 4.5. DispatchSinkVerify Request and Response . . . . . . . . . 27 4.6. Denial Response and Error Model . . . . . . . . . . . . . 29 4.7. Complete Agent Transaction Example . . . . . . . . . . . 30 5. Protocol Operation, Verification, and Failure Handling . . . 32 5.1. Requirements Language . . . . . . . . . . . . . . . . . . 32 5.2. End-to-End Protocol Workflow . . . . . . . . . . . . . . 32 5.3. Candidate Act Construction . . . . . . . . . . . . . . . 33 5.3.1. Candidate Act Digest . . . . . . . . . . . . . . . . 34 5.4. PED Processing . . . . . . . . . . . . . . . . . . . . . 35 5.5. Protected Validation Evidence . . . . . . . . . . . . . . 36 5.6. Scoped Finality Authority . . . . . . . . . . . . . . . . 37 5.7. Finality Sink Verification Algorithm . . . . . . . . . . 38 5.8. Authority Consumption and Replay Prevention . . . . . . . 39 5.9. Revocation . . . . . . . . . . . . . . . . . . . . . . . 40 5.10. Policy Epoch Changes . . . . . . . . . . . . . . . . . . 41 5.11. Hot-Path and Cold-Path Processing . . . . . . . . . . . . 41 5.11.1. Hot Path . . . . . . . . . . . . . . . . . . . . . . 41 5.11.2. Cold Path . . . . . . . . . . . . . . . . . . . . . 42 5.12. Hot-to-Cold Escalation . . . . . . . . . . . . . . . . . 42 5.13. Cold-to-Hot Authority Refresh . . . . . . . . . . . . . . 43 5.14. Latency Model . . . . . . . . . . . . . . . . . . . . . . 44 5.15. Failure and Denial Codes . . . . . . . . . . . . . . . . 45 5.16. Denial Behavior . . . . . . . . . . . . . . . . . . . . . 45 5.17. No Fail-Open on Timeout . . . . . . . . . . . . . . . . . 46 5.18. Alternate-Path Closure . . . . . . . . . . . . . . . . . 47 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 6.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 49 6.2. Candidate Act Substitution . . . . . . . . . . . . . . . 49 6.3. Sink Substitution and Cross-Sink Laundering . . . . . . . 50 6.4. Stale Policy and Revocation . . . . . . . . . . . . . . . 50 6.5. Prompt Injection and Instruction Laundering . . . . . . . 51 6.6. Agentic Cascade and Delegation Attacks . . . . . . . . . 51 6.7. Protected-State Integrity . . . . . . . . . . . . . . . . 52 6.8. Failure of the PED . . . . . . . . . . . . . . . . . . . 52 6.9. Failure of the Finality Sink . . . . . . . . . . . . . . 52 7. Agentic-AI Threat Model . . . . . . . . . . . . . . . . . . . 53 8. Interoperability and Deployment Model . . . . . . . . . . . . 53 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 10. Intellectual Property Considerations . . . . . . . . . . . . 54 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 Das Expires 27 February 2027 [Page 3] Internet-Draft Agentic Execution Finality August 2026 11.1. Normative References . . . . . . . . . . . . . . . . . . 55 11.2. Informative References . . . . . . . . . . . . . . . . . 55 11.3. Technical-Lineage References . . . . . . . . . . . . . . 56 12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction This document defines a focused execution-finality model for agentic systems in which an AI model or autonomous agent may prepare a tool call, API request, browser action, shell command, message, memory write, delegated act, or other external operation, but that generated operation does not become effective until an act-specific authorization chain is verified at the dispatch boundary. The document deliberately excludes precise-location policy, telecommunications control, GPU buses, satellite control, financial settlement, and child-safety rendering except where a generic example is necessary to explain the protocol. The standards surface addressed here is the Agent Candidate Act, protected validation, scoped non-bearer finality authority, and the Tool-Dispatch Finality Sink. 2. Core Execution-Finality Protocol 2.1. Core Architectural Principle The execution-finality architecture separates computation, generation, routing, and upstream authorization from the authority required for an operation to become externally effective. The principal invariant is: A Candidate Act MUST NOT become consequence-bearing merely because it has been generated, computed, selected, routed, scheduled, delegated, authenticated, or permitted by an upstream application or AI system. A Candidate Act MUST remain in a Non-Effective State until: 1. a Protected Enforcement Domain validates the applicable act-specific predicates; 2. protected validation evidence is generated or committed; 2.2. scoped non-bearer finality authority is released; 2.3. an applicable Finality Sink independently verifies that authority; and 2.4. the finality authority and associated protected state are consumed, invalidated, advanced, or otherwise made unsuitable for unauthorized replay. Das Expires 27 February 2027 [Page 4] Internet-Draft Agentic Execution Finality August 2026 This is a two-boundary architecture rather than a single authorization gate. The first boundary determines whether scoped finality authority may be created. The second determines whether the consequence may actually occur. 2.1 Terminology Candidate Act A Candidate Act is an operation that has been generated, selected, requested, staged, scheduled, routed, or otherwise prepared but has not yet been permitted to become consequence-bearing. Examples include: • an AI-agent tool call; • a function or API invocation; • a network transmission; • an exact-location export; • an AI-generated command; • a memory write; • a database commit; • a payment instruction; • a telecom control operation; • an RF transmission; • a satellite command; • an actuator signal; or • another externally effective operation. A Candidate Act MAY already be fully computed before finality authorization occurs. Computation alone MUST NOT cause effectuation. Non-Effective State A Non-Effective State is a state in which the Candidate Act may exist, be evaluated, staged, queued, hashed, transformed, or prepared, but the protected consequence cannot yet become externally effective. An implementation MUST preserve the Non-Effective State whenever a required element of the execution-finality chain is: • absent; • invalid; • stale; • expired; • revoked; • replayed; • already consumed; • act-mismatched; • scope-mismatched; • policy-mismatched; • jurisdiction-mismatched; • protected-state-mismatched; or • Finality-Sink-mismatched. The source architecture expressly requires failure at a load-bearing point to leave the Candidate Act non-effective rather than merely producing a warning or audit record. Protected Enforcement Domain A Protected Enforcement Domain (PED) is a protected validation environment that evaluates whether a Candidate Act is eligible to receive scoped finality authority. Depending on the implementation, the PED MAY be implemented using: • a trusted execution environment; • secure enclave; • HSM; • protected operating-system service; • protected network function; • secure controller; • confidential-computing environment; • hardware-assisted enforcement logic; or Das Expires 27 February 2027 [Page 5] Internet-Draft Agentic Execution Finality August 2026 • an equivalent protected validation environment. The defining function is not a particular hardware product. The PED performs protected validation before finality authority is released. Protected Validation Evidence Protected Validation Evidence is evidence committed by the PED establishing the validation state associated with a Candidate Act. The evidence MAY take the form of a Ledger-Anchored Validation Receipt (LAVR) or an equivalent protected commitment. For this architecture, a LAVR is not required to use blockchain. It may instead use hashes, protected signatures, HSM or enclave signatures, MACs, sealed state, monotonic counters, timestamps, Merkle commitments, append-only protected records, secure audit registers, or equivalent protected mechanisms. External ledger or blockchain anchoring MAY be performed later on a cold path. The important requirement is: protected validation evidence MUST exist before, or atomically with, release of scoped finality authority. Scoped Non-Bearer Finality Authority A Scoped Non-Bearer Finality Authority is an act-specific enablement artifact or protected authorization state that permits a particular Candidate Act to cross a particular effectuation boundary only under its validated scope. It is non-bearer because possession alone MUST NOT be sufficient to cause effectuation. The Finality Sink MUST verify the relevant bindings before accepting it. The authority SHOULD be bound to applicable state including: • Candidate Act identity or digest; • protected validation evidence; • protected state; • nonce or freshness state; • policy epoch; • revocation epoch; • permitted scope; • permitted consequence class; • destination or resource where applicable; • jurisdiction where applicable; and • intended Finality Sink identity. An authority issued for one act, sink, scope, destination, precision level, policy state, or protected-state transition MUST NOT be reusable as authority for another consequence. Your specification expressly distinguishes this from conventional bearer credentials, RBAC decisions, risk scores, or upstream policy decisions. Finality Sink A Finality Sink is the functional boundary at which a Candidate Act would become externally, operationally, financially, physically, network-effectively, or sovereignty-effectively consequential. The Finality Sink is defined by its role, not by its product name or physical implementation. It MAY be implemented in hardware, firmware, software, virtualized logic, a protected operating-system service, cloud infrastructure, or a distributed enforcement arrangement. The determining question is: Does this component control the boundary at which the Candidate Act becomes effective? If yes, that component or arrangement can perform the Finality Sink role. A gateway, firewall, policy engine, or security module is not a Finality Sink merely because it performs security checks. It must control the consequence such that the consequence is technically non-completable without successful finality verification. 3. Candidate Act Descriptor A conforming implementation SHOULD create or derive a machine-verifiable descriptor for the Candidate Act before effectuation. The precise serialization format is implementation-specific in this version of the document. A conceptual descriptor may contain: Candidate-Act-ID Act-Type Act-Digest Initiating-Principal Application-ID Agent-ID Tool-or-Function-ID Purpose Resource-or-Data-Class Permitted-Scope Permitted-Consequence- Class Das Expires 27 February 2027 [Page 6] Internet-Draft Agentic Execution Finality August 2026 Destination-ID Destination-Jurisdiction Data-Precision Data-Residency-State Policy-Epoch Authority-Epoch Revocation-Epoch Nonce Freshness-State Protected-State-Reference Validation-Evidence-Reference Finality-Sink-ID Effectuation-Boundary-ID Not every field is required for every domain. For example: • Data-Precision is particularly relevant to location or sensitive-data release. • Destination-Jurisdiction is relevant to cross-border data export. • Tool-or-Function-ID is important for agentic AI. • Permitted-Consequence-Class may distinguish a model response from a financial transfer or physical actuation. • Finality-Sink-ID identifies the boundary authorized to consume the authority. The underlying disclosure already contemplates binding the Candidate Act to protected state, validation evidence, nonce, freshness, policy and revocation epochs, jurisdiction state, permitted effect, and Finality Sink identity. 4. First Boundary — PED Validation The first execution-finality boundary is PED validation. Upon receiving or resolving a Candidate Act, the PED MUST keep that act non-effective while validation is performed. The PED SHOULD evaluate all predicates required by the applicable consequence class. Such predicates MAY include: authority purpose application identity agent identity tool/function scope instruction provenance destination jurisdiction data residency data precision policy epoch revocation state freshness nonce state protected state ALF or approved logic state Runtime Behavioral Descriptor permitted consequence class Finality Sink identity The PED MUST distinguish between validation success and effectuation. PED approval alone MUST NOT make the Candidate Act effective. This distinction is essential. The architecture requires: PED validation success Das Expires 27 February 2027 [Page 7] Internet-Draft Agentic Execution Finality August 2026 != external consequence Instead: PED validation success | v Protected evidence commitment | v Scoped finality authority Only after the evidence commitment is made MAY the execution-finality chain advance. 4.1 PED Validation Success If validation succeeds, the PED MUST: 1. establish or confirm the applicable protected-state transition; 2. generate or commit protected validation evidence; 3. bind that evidence to the applicable Candidate Act; 4. bind the permitted scope and applicable Finality Sink; 5. release scoped non-bearer finality authority only after, or atomically with, the evidence commitment. The Candidate Act remains non-effective at this stage. The PED has authorized issuance of finality authority. It has not yet caused effectuation. 4.2 PED Validation Failure If validation fails, the PED MUST NOT release usable finality authority. The implementation SHOULD create protected denial state or denial evidence sufficient to prevent unauthorized retry, replay, rollback, substitution, or stale reuse where those risks apply. The implementation MAY: • consume or lock a nonce; • advance protected monotonic state; • generate a denial receipt; • generate a denial LAVR; • update a revocation or exposure state; • quarantine the Candidate Act; or • require renewed authorization. The Candidate Act MUST remain non-effective. Your disclosure specifically contemplates denial evidence, nonce consumption or locking, protected-state advancement, and continued non-effectuation following failed validation. 5. Protected Evidence Before Authority A defining property of this architecture is evidence-gated progression. The system MUST NOT treat a simple Boolean result such as: ALLOW = TRUE as sufficient execution-finality authority. Instead, the protected validation result is committed into protected evidence before the act can proceed. Conceptually: Candidate Act | v PED Validation | +---- FAIL ----> Denial Evidence | | Das Expires 27 February 2027 [Page 8] Internet-Draft Agentic Execution Finality August 2026 | v | Remain Non-Effective | `---- PASS | v Protected Evidence | v Scoped Finality Authority This makes the validation state part of the consequence-control mechanism rather than merely part of an audit trail. A LAVR therefore represents a pre-effectuation protected commitment, not a post-event blockchain receipt. 2.5. Scoped Non-Bearer Finality Authority Following successful protected evidence commitment, the PED MAY release an Execution Handle, capability fragment, protected enablement state, or equivalent scoped non-bearer finality authority. Regardless of representation, the authority MUST be sufficiently constrained so that possession alone cannot authorize arbitrary effectuation. A conforming authority SHOULD be: Act-bound It applies only to the intended Candidate Act or Candidate Act Fragment. Evidence-bound It is associated with the protected validation evidence that caused its issuance. State-bound It reflects the relevant protected state. Scope-bound It permits only the validated consequence. Nonce- or freshness-bound It cannot be validly replayed outside the applicable freshness state. Epoch-bound It remains consistent with applicable policy, authorization, and revocation state. Sink-bound It is valid only at the intended Finality Sink. Non-bearer Copying, observing, storing, forwarding, or possessing it does not by itself create authority for effectuation. Where single- use effectuation is intended, the authority MUST be consumed, invalidated, burned, or rendered unusable before or atomically with successful effectuation. The source explicitly requires freshness, unconsumed state, revocation state, exact Candidate-Act binding, protected evidence/state binding, and intended sink binding to be verified. 2.6. Second Boundary — Independent Finality Sink Verification Das Expires 27 February 2027 [Page 9] Internet-Draft Agentic Execution Finality August 2026 The second boundary is the Finality Sink. The Finality Sink MUST NOT merely trust the fact that the PED previously approved the Candidate Act. It MUST independently verify the applicable finality authority immediately before effectuation. The Finality Sink SHOULD verify, where applicable: authority validity Candidate Act identity/digest protected validation evidence protected-state reference or transition scope purpose destination jurisdiction data precision nonce freshness policy epoch revocation epoch consumption state permitted consequence class effectuation-boundary identity Finality Sink identity The Finality Sink MUST reject the Candidate Act if a required verification fails. A failed Finality Sink verification MUST NOT merely create an alert while allowing the consequence to proceed. It MUST prevent effectuation. For example: Data export failure: no protected data leaves the boundary. Payment failure: no settlement occurs. Telecom failure: no governed network consequence occurs. Satellite failure: no protected command or RF effect occurs. AI tool-call failure: the tool call remains non-effective. Location failure: exact GPS coordinates are not released. This independent sink-side verification is explicitly required by your disclosed architecture. 2.7. Successful Effectuation Das Expires 27 February 2027 [Page 10] Internet-Draft Agentic Execution Finality August 2026 If Finality Sink verification succeeds, the implementation MUST ensure that the finality authority cannot be reused outside its permitted semantics. For single-use operations, consumption, invalidation, burning, or protected-state advancement SHOULD occur before or atomically with effectuation. The implementation SHOULD also create sink-side finality evidence identifying the completed protected consequence. The execution sequence is therefore: 1. Candidate Act created | 2. Candidate Act held non-effective | 3. PED validates act-specific predicates | 4. Protected validation evidence committed | 5. Scoped non-bearer finality authority released | 6. Finality Sink independently verifies authority | 7. Authority/state consumed or advanced | 8. Permitted consequence becomes effective | 2.8. Sink-side finality evidence recorded This progression closely follows the seven evidence-gated stages expressly described in the source specification. 9. Fail-Closed Requirement A conforming implementation MUST fail closed for a protected consequence when required execution-finality state cannot be verified. The following conditions SHOULD result in denial where applicable: missing authority invalid authority expired authority stale authority replayed authority revoked authority previously consumed authority Candidate Act mismatch descriptor mismatch scope mismatch purpose mismatch destination mismatch jurisdiction mismatch precision mismatch policy-epoch mismatch revocation-epoch mismatch nonce mismatch protected-state mismatch Finality Sink mismatch effectuation-boundary mismatch The important property is structural: failure prevents consequence rather than merely documenting that an unauthorized consequence occurred. This is the difference between execution finality and conventional audit- oriented control. 2.9. Why This Is Different From Ordinary App Permissions Das Expires 27 February 2027 [Page 11] Internet-Draft Agentic Execution Finality August 2026 A conventional system may implement: if app_has_location_permission: location = get_precise_location() send(location) The execution-finality architecture separates these operations: if app_has_location_access: location = obtain_location_locally() candidate = create_candidate_export( data=location, purpose=purpose, destination=destination, jurisdiction=jurisdiction, requested_precision=precision ) keep_non_effective(candidate) validation = PED.validate(candidate) if validation fails: deny() evidence = PED.commit_validation_evidence(validation) authority = PED.release_scoped_finality_authority( candidate, evidence ) if FinalitySink.verify(authority, candidate) fails: deny() FinalitySink.consume(authority) release_only_permitted_effect(candidate) The difference is therefore: ACCESS PERMISSION != EXPORT AUTHORITY and: UPSTREAM ALLOW != FINAL EFFECTUATION The source makes the same structural distinction between generic policy permission and act-specific, protected-state-bound, nonce-bound, epoch-bound, scope-bound, sink-bound finality authority. 2.10. Agentic-AI Enforcement Example Das Expires 27 February 2027 [Page 12] Internet-Draft Agentic Execution Finality August 2026 The same protocol applies when the initiator is an autonomous AI agent. For example: User: "Find a nearby hospital." Agent: obtains precise device location locally Agent decision: call external discovery service The AI's access to precise location does not automatically authorize transmission of that precision. The external API call becomes a Candidate Act. The PED may determine: Purpose: nearby service discovery Required precision: approximate / regional Requested transmission: exact latitude + longitude Decision: downgrade precision The Finality Sink may therefore authorize: approximate region while preventing release of: exact coordinates The AI remains capable of performing the user-requested task, but it does not acquire unrestricted authority to disclose the most sensitive form of the underlying data. This implements the broader principle: AI reasoning authority is not data-export authority. Tool-use authority is not unrestricted consequence authority. Access to precise GPS is not authority to disclose precise GPS. 2.11. Protocol Invariant Das Expires 27 February 2027 [Page 13] Internet-Draft Agentic Execution Finality August 2026 The complete Phase 2 invariant can therefore be stated as: Candidate Act | v Non-Effective State | v Protected Enforcement Domain | v Act-Specific Validation | v Protected Validation Evidence | v Scoped Non-Bearer Finality Authority | v Independent Finality Sink Verification | +------ FAILURE ------> remain non-effective | `------ SUCCESS | v authority consumed | v permitted consequence No individual element substitutes for this chain. A policy engine alone is insufficient. An app permission alone is insufficient. An access token alone is insufficient. An attestation alone is insufficient. A human approval alone is insufficient. A LAVR alone is insufficient. A Finality Sink without act-bound authority is insufficient. The execution-finality property arises because these elements remain mutually bound across the transition from computation to consequence. 3. Agent Candidate Act and Dispatch Sink Interface 3.1. Embodiment A — Agentic AI and Autonomous Tool Use 3.1.1. Problem Das Expires 27 February 2027 [Page 14] Internet-Draft Agentic Execution Finality August 2026 Modern AI systems increasingly operate as agents rather than passive text generators. An agent may: • call an API; • invoke a function; • operate a browser; • execute a shell command; • write a file; • update memory; • modify a vector database; • initiate a payment; • send a message; • call another agent; • access an MCP server; • operate an enterprise system; or • issue a physical or network command. The technical problem is that generation of a tool call and authority to cause the tool's consequence are not the same event. An AI model may correctly produce syntactically valid tool-call arguments while the proposed action is nevertheless unauthorized because of: • prompt injection; • poisoned retrieval; • stale memory; • malicious tool output; • unauthorized delegation; • changed policy; • changed user authorization; • destination mismatch; • excessive scope; • runtime model-state deviation; or • an untrusted input that influenced the agent's reasoning. The source specifically applies the architecture to model outputs, generated token streams, function-call arguments, retrieval queries, memory writes, browser actions, shell commands, computer-use actions and delegated agent acts. 3.1.2. Agent Candidate Act A consequential tool request SHOULD first be represented as an Agent Candidate Act. Example: Act-Type: TOOL_CALL Agent-ID: enterprise-agent-27 Tool-ID: customer-payment-api Function: issue_refund Requested-Amount: 500 Customer-ID: 18422 Instruction-Source: authenticated support workflow Purpose: customer refund Policy-Epoch: 481 Das Expires 27 February 2027 [Page 15] Internet-Draft Agentic Execution Finality August 2026 Finality-Sink: payment-api-dispatcher The AI system MAY prepare the call and arguments. It MUST NOT cause the external call merely because inference has completed. 3.1.3. Agentic PED Validation The PED MAY validate: agent identity model or ALF state runtime behavior instruction provenance tool identity function identity argument scope user authorization delegation authority memory provenance retrieval provenance policy epoch revocation state purpose destination permitted consequence class Finality Sink identity If the required predicates are not satisfied, no usable finality authority is released. 3.1.4. Tool-Dispatch Finality Sink Das Expires 27 February 2027 [Page 16] Internet-Draft Agentic Execution Finality August 2026 The applicable Finality Sink MAY be placed at: • tool dispatcher; • MCP invocation interface; • function-call gateway; • browser-control interface; • shell-execution interface; • API gateway; • file writer; • memory-write controller; • message-send controller; or • equivalent consequence boundary. The source explicitly identifies such interfaces as possible Finality Sinks. Thus: AI says: "Call Tool X" | v This is only a Candidate Act | v PED validates | v Finality Sink independently verifies | v Tool actually executes The resulting principle is: Tool selection is not tool-execution authority. 4. JSON API and Schema for Agent Candidate Acts This section defines a concrete JSON interoperability profile for representing an agent-generated Candidate Act, protected validation evidence, scoped finality authority, and the request/response exchange at a Tool-Dispatch Finality Sink. The JSON objects are intended to make the execution-finality interface directly reviewable by protocol and API implementers. A future revision may define a dedicated media type or alternative binary encoding without changing the semantic bindings defined here. Das Expires 27 February 2027 [Page 17] Internet-Draft Agentic Execution Finality August 2026 4.1. JSON Encoding Conventions All protocol objects in this profile are JSON objects encoded using UTF-8. Field names are case-sensitive. Unknown fields MAY be ignored only when the implementation is configured to permit extension fields; a security-critical implementation SHOULD reject unknown fields unless an extension namespace or version negotiation mechanism authorizes them. Timestamps use RFC 3339 format. Digests identify both the algorithm and encoded digest value. A recipient MUST verify semantic bindings rather than trusting possession of an object. { "version": "1.0", "object_type": "agent_candidate_act", "candidate_act_id": "act-7f39b8b8", "created_at": "2026-08-26T17:40:00Z", "expires_at": "2026-08-26T17:40:15Z" } 4.2. AgentCandidateAct Object AgentCandidateAct represents an operation selected, generated, delegated, or prepared by an agent but not yet permitted to become externally effective. The object binds the proposed effect to the initiating principal, agent, tool, function, argument digest, purpose, destination, policy state, freshness state, and intended Dispatch Sink. { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "urn:ietf:params:json-schema:agent-finality:candidate-act:1", "title": "AgentCandidateAct", "type": "object", "additionalProperties": false, "required": [ "version", "object_type", "candidate_act_id", "act_type", "created_at", "expires_at", "initiating_principal", "agent", "tool", "purpose", "arguments_digest", "consequence_class", Das Expires 27 February 2027 [Page 18] Internet-Draft Agentic Execution Finality August 2026 "policy_state", "freshness", "finality_sink" ], "properties": { "version": { "type": "string", "const": "1.0" }, "object_type": { "type": "string", "const": "agent_candidate_act" }, "candidate_act_id": { "type": "string", "minLength": 16, "maxLength": 128 }, "act_type": { "type": "string", "enum": [ "TOOL_CALL", "FUNCTION_CALL", "API_REQUEST", "BROWSER_ACTION", "SHELL_ACTION", "MESSAGE_SEND", "FILE_WRITE", "MEMORY_WRITE", "AGENT_DELEGATION", "PAYMENT_REQUEST", "OTHER" ] }, "created_at": { "type": "string", "format": "date-time" }, "expires_at": { "type": "string", "format": "date-time" }, "initiating_principal": { "type": "object", "required": [ "principal_id", "principal_type" ], Das Expires 27 February 2027 [Page 19] Internet-Draft Agentic Execution Finality August 2026 "properties": { "principal_id": { "type": "string" }, "principal_type": { "type": "string", "enum": [ "user", "service", "enterprise", "device", "agent" ] }, "authorization_context_id": { "type": "string" } } }, "agent": { "type": "object", "required": [ "agent_id", "runtime_id" ], "properties": { "agent_id": { "type": "string" }, "runtime_id": { "type": "string" }, "model_id": { "type": "string" }, "model_version": { "type": "string" }, "alf_digest": { "type": "string" }, "delegation_depth": { "type": "integer", "minimum": 0 }, "parent_agent_id": { "type": "string" } Das Expires 27 February 2027 [Page 20] Internet-Draft Agentic Execution Finality August 2026 } }, "tool": { "type": "object", "required": [ "tool_id", "function_id" ], "properties": { "tool_id": { "type": "string" }, "function_id": { "type": "string" }, "tool_endpoint": { "type": "string" }, "tool_protocol": { "type": "string", "enum": [ "MCP", "HTTP_API", "LOCAL_FUNCTION", "BROWSER", "SHELL", "A2A", "OTHER" ] } } }, "purpose": { "type": "object", "required": [ "purpose_id", "declared_purpose" ], "properties": { "purpose_id": { "type": "string" }, "declared_purpose": { "type": "string" }, "user_intent_reference": { "type": "string" }, Das Expires 27 February 2027 [Page 21] Internet-Draft Agentic Execution Finality August 2026 "purpose_epoch": { "type": "integer", "minimum": 0 } } }, "arguments_digest": { "type": "object", "required": [ "algorithm", "value", "canonicalization" ], "properties": { "algorithm": { "type": "string", "enum": [ "SHA-256", "SHA-384", "SHA-512" ] }, "value": { "type": "string" }, "canonicalization": { "type": "string", "enum": [ "JCS", "implementation-defined" ] } } }, "destination": { "type": "object", "properties": { "destination_id": { "type": "string" }, "endpoint": { "type": "string" }, "jurisdiction": { "type": "string" }, "recipient_id": { "type": "string" Das Expires 27 February 2027 [Page 22] Internet-Draft Agentic Execution Finality August 2026 } } }, "consequence_class": { "type": "string", "enum": [ "INFORMATIONAL", "DATA_DISCLOSURE", "PERSISTENT_STATE_CHANGE", "FINANCIAL", "NETWORK_CONTROL", "PHYSICAL", "COMMUNICATION", "OTHER" ] }, "policy_state": { "type": "object", "required": [ "policy_epoch", "authority_epoch", "revocation_epoch" ], "properties": { "policy_epoch": { "type": "integer", "minimum": 0 }, "authority_epoch": { "type": "integer", "minimum": 0 }, "revocation_epoch": { "type": "integer", "minimum": 0 }, "policy_profile_id": { "type": "string" } } }, "freshness": { "type": "object", "required": [ "nonce" ], "properties": { "nonce": { Das Expires 27 February 2027 [Page 23] Internet-Draft Agentic Execution Finality August 2026 "type": "string", "minLength": 16 }, "sequence": { "type": "integer", "minimum": 0 }, "session_id": { "type": "string" } } }, "instruction_provenance": { "type": "object", "properties": { "instruction_digest": { "type": "string" }, "source_type": { "type": "string", "enum": [ "user", "system", "developer", "tool", "retrieval", "memory", "agent" ] }, "trusted_chain_digest": { "type": "string" } } }, "finality_sink": { "type": "object", "required": [ "sink_id", "sink_type" ], "properties": { "sink_id": { "type": "string" }, "sink_type": { "type": "string", "enum": [ Das Expires 27 February 2027 [Page 24] Internet-Draft Agentic Execution Finality August 2026 "TOOL_DISPATCH", "API_GATEWAY", "BROWSER_CONTROLLER", "SHELL_GATEWAY", "MESSAGE_GATEWAY", "FILE_COMMIT", "MEMORY_COMMIT", "OTHER" ] } } } } } 4.3. ProtectedValidationEvidence Object ProtectedValidationEvidence records the protected validation result that caused finality authority to be issued. The evidence is not merely post-event logging; it is bound into the authority that the Dispatch Sink verifies before effectuation. Das Expires 27 February 2027 [Page 25] Internet-Draft Agentic Execution Finality August 2026 { "version": "1.0", "object_type": "protected_validation_evidence", "evidence_id": "pve-6d6ddc91", "candidate_act_id": "act-7f39b8b8", "decision": "ALLOW", "validated_predicates": { "principal_authorized": true, "agent_identity_valid": true, "tool_scope_valid": true, "purpose_valid": true, "instruction_provenance_valid": true, "destination_valid": true, "policy_epoch_valid": true, "revocation_state_valid": true, "freshness_valid": true, "sink_binding_valid": true }, "protected_state": { "state_reference": "ped-state-901", "monotonic_counter": 8481 }, "issued_at": "2026-08-26T17:40:01Z", "evidence_digest": { "algorithm": "SHA-256", "value": "base64url-digest" }, "protector": { "type": "TEE_SIGNATURE", "key_id": "ped-key-12", "signature": "base64url-signature" } } 4.4. AgentFinalityAuthority Object AgentFinalityAuthority is a scoped, non-bearer, normally single-use artifact. Possession alone is insufficient. The intended Dispatch Sink verifies the Candidate Act digest, protected evidence, scope, sink binding, freshness, policy epochs, and consumption state before effectuation. Das Expires 27 February 2027 [Page 26] Internet-Draft Agentic Execution Finality August 2026 { "version": "1.0", "object_type": "agent_finality_authority", "authority_id": "afa-c7d32d54", "candidate_act_id": "act-7f39b8b8", "evidence_id": "pve-6d6ddc91", "scope": { "act_type": "TOOL_CALL", "tool_id": "maps.search", "function_id": "nearby", "permitted_destination": "tool.example", "permitted_consequence_class": "DATA_DISCLOSURE" }, "binding": { "candidate_act_digest": { "algorithm": "SHA-256", "value": "base64url-act-digest" }, "protected_state_reference": "ped-state-901", "nonce": "A81D4F42B779CC21", "policy_epoch": 42, "authority_epoch": 18, "revocation_epoch": 7, "finality_sink_id": "dispatch-sink-01" }, "lifetime": { "issued_at": "2026-08-26T17:40:01Z", "not_before": "2026-08-26T17:40:01Z", "expires_at": "2026-08-26T17:40:10Z", "single_use": true }, "issuer": { "ped_id": "ped-mobile-01", "key_id": "ped-key-12", "signature": "base64url-signature" } } 4.5. DispatchSinkVerify Request and Response The agent runtime presents the Candidate Act and finality authority to the Dispatch Sink. The sink reconstructs or resolves the relevant load-bearing Candidate Act attributes and verifies them independently. The sink MUST NOT treat an upstream ALLOW result as sufficient. Das Expires 27 February 2027 [Page 27] Internet-Draft Agentic Execution Finality August 2026 { "operation": "DispatchSinkVerify", "request_id": "req-10aa19", "candidate_act": { "candidate_act_id": "act-7f39b8b8", "act_type": "TOOL_CALL", "tool": { "tool_id": "maps.search", "function_id": "nearby" }, "purpose": { "purpose_id": "nearby-service-discovery" }, "destination": { "destination_id": "tool.example" }, "freshness": { "nonce": "A81D4F42B779CC21" }, "finality_sink": { "sink_id": "dispatch-sink-01" } }, "finality_authority": { "authority_id": "afa-c7d32d54" }, "requested_effect": { "arguments_digest": "base64url-act-digest", "consequence_class": "DATA_DISCLOSURE" } } Das Expires 27 February 2027 [Page 28] Internet-Draft Agentic Execution Finality August 2026 { "operation": "DispatchSinkVerify", "request_id": "req-10aa19", "decision": "ALLOW", "verification": { "authority_signature": "VALID", "candidate_act_binding": "MATCH", "tool_scope": "MATCH", "purpose": "MATCH", "destination": "MATCH", "nonce": "FRESH", "policy_epoch": "CURRENT", "revocation_epoch": "CURRENT", "consumption_state": "UNUSED", "sink_binding": "MATCH" }, "consumption": { "authority_id": "afa-c7d32d54", "status": "CONSUMED", "consumed_at": "2026-08-26T17:40:02Z" }, "effectuation": { "permitted": true, "effect_id": "effect-bf3b5a" } } 4.6. Denial Response and Error Model A sink denial is terminal for the presented authority. Implementations SHOULD distinguish malformed input from security validation failure. A denial MUST leave the protected consequence non-effective. Das Expires 27 February 2027 [Page 29] Internet-Draft Agentic Execution Finality August 2026 { "operation": "DispatchSinkVerify", "request_id": "req-10aa19", "decision": "DENY", "error": { "code": "EF_SCOPE_MISMATCH", "message": "Requested function is outside the authorized tool scope.", "retryable": false }, "verification": { "authority_signature": "VALID", "candidate_act_binding": "MATCH", "tool_scope": "MISMATCH", "consumption_state": "UNUSED", "sink_binding": "MATCH" }, "effectuation": { "permitted": false } } 4.7. Complete Agent Transaction Example The following example shows the complete interaction from agent selection through sink-side effectuation. The exact transport carrying these JSON objects is outside the scope of this revision; HTTPS, local IPC, a protected OS call, or an agent/tool protocol binding may carry the objects. { "step_1_candidate_act": { "version": "1.0", "object_type": "agent_candidate_act", "candidate_act_id": "act-7f39b8b8", "act_type": "TOOL_CALL", "created_at": "2026-08-26T17:40:00Z", "expires_at": "2026-08-26T17:40:15Z", "initiating_principal": { "principal_id": "user-184", "principal_type": "user", "authorization_context_id": "authctx-447" }, "agent": { "agent_id": "assistant-23", "runtime_id": "runtime-ios-82", "model_id": "model-X", "model_version": "2026.08", "delegation_depth": 0 Das Expires 27 February 2027 [Page 30] Internet-Draft Agentic Execution Finality August 2026 }, "tool": { "tool_id": "maps.search", "function_id": "nearby", "tool_endpoint": "https://tool.example/nearby", "tool_protocol": "MCP" }, "purpose": { "purpose_id": "nearby-service-discovery", "declared_purpose": "Find nearby pharmacies requested by the user", "user_intent_reference": "turn-8841", "purpose_epoch": 3 }, "arguments_digest": { "algorithm": "SHA-256", "value": "base64url-args-digest", "canonicalization": "JCS" }, "destination": { "destination_id": "tool.example", "endpoint": "https://tool.example/nearby", "jurisdiction": "IN", "recipient_id": "maps-provider" }, "consequence_class": "DATA_DISCLOSURE", "policy_state": { "policy_epoch": 42, "authority_epoch": 18, "revocation_epoch": 7, "policy_profile_id": "agent-tools-v4" }, "freshness": { "nonce": "A81D4F42B779CC21", "sequence": 106, "session_id": "session-55" }, "instruction_provenance": { "instruction_digest": "sha256:user-instruction", "source_type": "user", "trusted_chain_digest": "sha256:instruction-chain" }, "finality_sink": { "sink_id": "dispatch-sink-01", "sink_type": "TOOL_DISPATCH" } }, "step_2_ped_decision": { "decision": "ALLOW", Das Expires 27 February 2027 [Page 31] Internet-Draft Agentic Execution Finality August 2026 "evidence_id": "pve-6d6ddc91" }, "step_3_authority": { "authority_id": "afa-c7d32d54", "single_use": true, "expires_at": "2026-08-26T17:40:10Z" }, "step_4_sink_verification": { "decision": "ALLOW", "authority_consumed": true }, "step_5_effect": { "effect": "maps.search.nearby invoked once with the exact authorized argument digest" } } 5. Protocol Operation, Verification, and Failure Handling 5.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as normative requirements when, and only when, they appear in all capitals. The execution-finality protocol is based on one mandatory invariant: Failure to establish current finality authority MUST NOT be converted into permission to effectuate. 5.2. End-to-End Protocol Workflow Das Expires 27 February 2027 [Page 32] Internet-Draft Agentic Execution Finality August 2026 A conforming implementation follows the following logical sequence: Act Generator PED Finality Sink | | | |-- Candidate Act ---->| | | | | | NON-EFFECTIVE | | |<---------------------| | | | | | |-- validate predicates | | |-- verify protected state| | |-- verify nonce/epochs | | | | | | [DENY] | | |---- denial evidence ---->| | | | | | Candidate remains | | | NON-EFFECTIVE | | | | | | [ALLOW] | | |-- commit evidence | | |-- create scoped | | | finality authority | | | | |---------------------- finality authority ------>| | | | verify act | | verify scope | | verify nonce | | verify state | | verify epochs | | verify sink | | | | [FAIL] | | no effect | | | | [PASS] | | consume | | authority | | | |<---------------- permitted consequence ---------| The source architecture expressly requires the Candidate Act to remain non-effective, protected evidence to be committed before or atomically with authority issuance, and independent Finality Sink verification before effectuation. 5.3. Candidate Act Construction Das Expires 27 February 2027 [Page 33] Internet-Draft Agentic Execution Finality August 2026 Before a protected consequence is attempted, the implementation SHOULD construct a Candidate Act Descriptor. A minimal logical representation is: CandidateAct { version candidate_act_id act_type act_digest initiator_id application_id agent_id tool_id purpose permitted_scope consequence_class destination_id jurisdiction data_class data_precision nonce creation_time expiration_time policy_epoch authority_epoch revocation_epoch protected_state_ref finality_sink_id } Fields MAY be omitted where they do not apply to the consequence class. However, every implementation MUST have sufficient binding information to prevent authority issued for one Candidate Act from being substituted, redirected, replayed, or used at another Finality Sink. 5.3.1. Candidate Act Digest Das Expires 27 February 2027 [Page 34] Internet-Draft Agentic Execution Finality August 2026 A Candidate Act SHOULD have a stable digest calculated over its load-bearing attributes. Conceptually: ActDigest = HASH( canonical_act_type || canonical_effect_parameters || purpose || destination || jurisdiction || permitted_scope || consequence_class || finality_sink_id ) The exact canonicalization and hash format are outside the scope of this version. However, implementations MUST ensure that changing a load-bearing attribute causes the previously issued authority to fail verification. For example, changing: Exact GPS -> coarse GPS Recipient A -> Recipient B Jurisdiction X -> Jurisdiction Y $50 -> $5,000 Tool A -> Tool B Satellite 1 -> Satellite 2 Sink A -> Sink B MUST NOT preserve authority unless the changed operation is separately authorized. 5.4. PED Processing The PED receives or reconstructs the Candidate Act Descriptor and performs protected validation. A simplified procedure is: function PED_VALIDATE(candidate): if candidate is malformed: return DENY(MALFORMED_ACT) if candidate.nonce is not fresh: return DENY(REPLAY_OR_STALE) if candidate.policy_epoch != current_policy_epoch: return DENY(POLICY_EPOCH_MISMATCH) if candidate.revocation_epoch != current_revocation_epoch: return DENY(REVOCATION_STATE_MISMATCH) Das Expires 27 February 2027 [Page 35] Internet-Draft Agentic Execution Finality August 2026 if candidate.finality_sink_id is not authorized: return DENY(SINK_NOT_AUTHORIZED) if protected_state does not permit candidate: return DENY(PROTECTED_STATE_DENIAL) if purpose is not permitted: return DENY(PURPOSE_DENIAL) if jurisdiction is not permitted: return DENY(JURISDICTION_DENIAL) if requested scope exceeds allowed scope: return DENY(SCOPE_DENIAL) if additional consequence-specific checks fail: return DENY(CONSEQUENCE_POLICY_DENIAL) evidence = COMMIT_PROTECTED_VALIDATION(candidate) authority = ISSUE_SCOPED_FINALITY_AUTHORITY( candidate, evidence, current_protected_state ) return ALLOW(authority) The pseudocode is illustrative. An implementation MAY evaluate additional predicates including ALF, Runtime Behavioral Descriptor, instruction provenance, neural-state integrity, data residency, accelerator identity, mission state, financial state, recipient state, or cumulative disclosure state. The disclosed architecture requires the PED to check act-specific predicates while the Candidate Act remains non-effective. 5.5. Protected Validation Evidence Upon successful validation, the PED MUST commit protected validation evidence before, or atomically with, issuance of usable finality authority. A conceptual evidence object may contain: ValidationEvidence { evidence_id candidate_act_digest decision = ALLOW protected_state_before protected_state_after Das Expires 27 February 2027 [Page 36] Internet-Draft Agentic Execution Finality August 2026 policy_epoch authority_epoch revocation_epoch nonce permitted_scope consequence_class finality_sink_id validation_time validation_domain_id integrity_protection } The evidence MAY be a LAVR or an equivalent protected commitment. External blockchain finality is NOT required for the hot path. The source explicitly permits local receipts, protected hash-chain entries, TEE/HSM receipts, secure-register entries, and equivalent protected commitments, with slower external anchoring occurring later. 5.6. Scoped Finality Authority A finality authority MAY be represented as an Execution Handle, protected capability, capability fragment, protected state reference, or equivalent bounded artifact. A conceptual structure is: FinalityAuthority { authority_id candidate_act_digest validation_evidence_ref permitted_scope consequence_class destination_id jurisdiction data_precision nonce policy_epoch authority_epoch revocation_epoch protected_state_ref finality_sink_id Das Expires 27 February 2027 [Page 37] Internet-Draft Agentic Execution Finality August 2026 issued_at expires_at single_use = true integrity_protection } The artifact MUST NOT operate as a generic bearer token. Merely copying the authority MUST NOT permit another process, sink, destination, jurisdiction, or Candidate Act to use it successfully. 5.7. Finality Sink Verification Algorithm Immediately before effectuation, the Finality Sink MUST independently verify the authority. Illustrative logic: function FINALITY_SINK_VERIFY(candidate, authority): if authority is absent: return DENY(NO_FINALITY_AUTHORITY) if authority integrity check fails: return DENY(INVALID_AUTHORITY) if HASH(candidate) != authority.candidate_act_digest: return DENY(ACT_MISMATCH) if authority.finality_sink_id != THIS_SINK: return DENY(SINK_MISMATCH) if authority is expired: return DENY(STALE_AUTHORITY) if authority is already consumed: return DENY(AUTHORITY_ALREADY_USED) if authority.nonce is not current: return DENY(NONCE_FAILURE) if authority.policy_epoch != current_policy_epoch: return DENY(POLICY_EPOCH_MISMATCH) if authority.revocation_epoch != current_revocation_epoch: return DENY(REVOKED_OR_STALE) if protected_state does not match: return DENY(PROTECTED_STATE_MISMATCH) Das Expires 27 February 2027 [Page 38] Internet-Draft Agentic Execution Finality August 2026 if candidate scope exceeds authority scope: return DENY(SCOPE_MISMATCH) if candidate destination != authorized destination: return DENY(DESTINATION_MISMATCH) if candidate jurisdiction != authorized jurisdiction: return DENY(JURISDICTION_MISMATCH) if candidate data precision exceeds authorized precision: return DENY(PRECISION_MISMATCH) ATOMICALLY: consume(authority) advance_replay_state() permit_effectuation() return EFFECTUATED The source expressly describes verification of capability/evidence presence, sink identity, descriptor and fragment hashes, nonce freshness and consumption, policy and revocation epochs, purpose, jurisdiction, scope, protected state, and permitted consequence class. 5.8. Authority Consumption and Replay Prevention Das Expires 27 February 2027 [Page 39] Internet-Draft Agentic Execution Finality August 2026 For a single-use operation, successful authority consumption SHOULD be atomic with the state transition that enables effectuation. An implementation MUST prevent the sequence: verify authority | v effectuate | v attacker replays same authority | v effectuate again Instead: verify | v reserve / consume authority | v advance protected replay state | v effectuate once Replay protection MAY use: • nonce consumption; • monotonic counters; • sequence numbers; • protected consumed flags; • protected state advancement; • short expiration windows; • epoch advancement; or • an equivalent anti-replay mechanism. The source requires capability consumption or protected-state advancement before or atomically with effectuation and describes nonce consumption as part of replay prevention. 5.9. Revocation Das Expires 27 February 2027 [Page 40] Internet-Draft Agentic Execution Finality August 2026 A previously issued authority MUST NOT override a newer revocation state. If an authority was created under: Revocation-Epoch = 51 and the applicable protected state has advanced to: Revocation-Epoch = 52 the older authority SHOULD fail unless an explicitly defined policy permits continued validity. Conceptually: if authority.revocation_epoch < protected.revocation_epoch: DENY Revocation SHOULD be checked at the Finality Sink, not merely when the authority was originally created. This prevents: PED approves at T1 | v authorization revoked at T2 | v old authority used at T3 from automatically becoming an effective consequence. 5.10. Policy Epoch Changes The same principle applies to policy. An authority issued before a material policy change SHOULD NOT silently inherit authority under the new policy state. Examples include: • exact location became prohibited for the destination; • an AI tool was revoked; • a telecom action was removed from the authorized scope; • a satellite entered a different mission phase; • a counterparty became blocked; • a model version was withdrawn; • a data residency rule changed; or • a child- safety policy changed. The sink SHOULD therefore compare current policy state with the policy epoch bound to the authority. 5.11. Hot-Path and Cold-Path Processing Not every Candidate Act requires identical validation cost. The architecture therefore MAY support a hot path and a cold path. 5.11.1. Hot Path Das Expires 27 February 2027 [Page 41] Internet-Draft Agentic Execution Finality August 2026 The hot path is suitable for: • frequent; • previously bounded; • low-risk; • latency-sensitive; or • pre-authorized classes of Candidate Acts. The hot path MAY rely on: local protected state fresh nonce state cached policy short-lived authority pre-bound sink identity known destination current revocation epoch bounded scope local protected evidence A hot-path operation MUST still perform Finality Sink verification. "Hot path" does not mean "skip finality." 5.11.2. Cold Path A Candidate Act SHOULD be escalated to a cold or higher-assurance path where it involves, for example: • high-value financial settlement; • exact location export; • high-value sovereign data export; • cross-jurisdiction processing; • satellite RF emission; • payload control; • cryptographic-key release; • actuator control; • unusual agent behavior; • new or unknown tool delegation; • changed destination; • uncertain jurisdiction; • policy anomaly; • missing cached state; or • high-consequence infrastructure operation. The cold path MAY require: • remote authority resolution; • fresh attestation; • deeper ALF/RBD validation; • sovereign approval; • enterprise approval; • regulatory checks; • multi-party approval; • consequence simulation; • human review; or • additional proof material. The source expressly identifies exact-location export, financial settlement, satellite RF, actuator control and high-value data egress as candidates for stronger validation. 5.12. Hot-to-Cold Escalation Das Expires 27 February 2027 [Page 42] Internet-Draft Agentic Execution Finality August 2026 A Candidate Act MUST NOT obtain default permission merely because the hot path cannot make a decision. For example: cache miss policy miss revocation uncertainty network failure unknown destination unknown jurisdiction changed sink changed tool runtime anomaly SHOULD result in: HOT PATH | v cannot prove eligibility | v COLD PATH not: HOT PATH | v cannot verify | v ALLOW The source is explicit that timeout, cache miss, policy miss, uncertainty, or network failure does not create default authority. 5.13. Cold-to-Hot Authority Refresh A successful cold-path evaluation MAY establish a bounded policy envelope for subsequent low-latency operations. For example, a cold path may establish: Approved Model: model-A Approved Tool: map-search Approved Purpose: local-service-discovery Maximum Location Precision: CITY Destination: endpoint-X Jurisdiction: permitted Policy-Epoch: 203 Das Expires 27 February 2027 [Page 43] Internet-Draft Agentic Execution Finality August 2026 Revocation-Epoch: 77 Finality-Sink: network-egress-4 Valid-Until: short bounded interval Later Candidate Acts within the exact envelope MAY use faster local validation. If any bound condition changes, the system SHOULD escalate again. The source expressly contemplates cold-path generation of protected hot-path policy objects while requiring freshness, scope, revocation and sink binding to remain valid. 5.14. Latency Model Execution finality SHOULD be implementable without requiring a remote ledger round trip for every operation. Representative embodiments in the source describe: • sub-10-ms operation for cached-policy paths; • approximately 1-5 ms in some hardware-adjacent paths; • approximately 1-20 ms for some mobile/browser/application-gateway paths; and • higher delays for stronger attestation, multi-party or regulatory validation. These figures are implementation examples, not protocol requirements. The important architectural separation is: HOT PATH --------- validate check nonce check protected state commit local protected evidence bind sink release scoped authority verify at sink effectuate COLD / AUDIT PATH ----------------- external ledger anchoring transparency log proof aggregation regulatory reporting enterprise synchronization long-term audit The cold path MUST NOT retroactively authorize an act that was not valid when effectuation occurred. External anchoring can strengthen later evidence, but it does not replace the pre-effectuation chain. Das Expires 27 February 2027 [Page 44] Internet-Draft Agentic Execution Finality August 2026 5.15. Failure and Denial Codes This section defines an IETF-draft-level proposed error taxonomy derived from the failure conditions in the source. The symbolic names below are protocol-design suggestions; the source describes the underlying failure conditions but does not prescribe these exact wire codes. A conforming implementation MAY expose equivalent numeric or symbolic codes. EF-001 MALFORMED_ACT EF-002 NO_FINALITY_AUTHORITY EF-003 INVALID_AUTHORITY EF-004 STALE_AUTHORITY EF-005 AUTHORITY_ALREADY_USED EF-006 REPLAY_DETECTED EF-007 NONCE_FAILURE EF-010 ACT_MISMATCH EF-011 DESCRIPTOR_MISMATCH EF-012 SCOPE_MISMATCH EF-013 PURPOSE_MISMATCH EF-014 CONSEQUENCE_CLASS_MISMATCH EF-020 DESTINATION_MISMATCH EF-021 JURISDICTION_MISMATCH EF-022 DATA_RESIDENCY_MISMATCH EF-023 PRECISION_MISMATCH EF-030 POLICY_EPOCH_MISMATCH EF-031 REVOCATION_STATE_MISMATCH EF-032 PROTECTED_STATE_MISMATCH EF-040 SINK_MISMATCH EF-041 EFFECTUATION_BOUNDARY_MISMATCH EF-050 ATTESTATION_FAILURE EF-051 ALF_MISMATCH EF-052 RUNTIME_BEHAVIOR_MISMATCH EF-053 INSTRUCTION_PROVENANCE_FAILURE EF-060 VALIDATION_TIMEOUT EF-061 AUTHORITY_UNCERTAIN EF-062 POLICY_UNAVAILABLE EF-063 JURISDICTION_UNRESOLVED EF-070 ESCALATION_REQUIRED EF-071 HUMAN_REVIEW_REQUIRED EF-080 FAIL_CLOSED The source identifies absence, staleness, revocation, replay, prior consumption, descriptor, nonce, policy, jurisdiction, protected-state, scope and Finality-Sink mismatch as conditions requiring the Candidate Act to remain non-effective. 5.16. Denial Behavior Das Expires 27 February 2027 [Page 45] Internet-Draft Agentic Execution Finality August 2026 A denial response MAY specify an allowed remediation. For example: EF-023 PRECISION_MISMATCH Action: DOWNGRADE_TO_CITY or: EF-063 JURISDICTION_UNRESOLVED Action: ESCALATE_TO_COLD_PATH or: EF-031 REVOCATION_STATE_MISMATCH Action: REQUIRE_FRESH_AUTHORITY or: EF-051 ALF_MISMATCH Action: QUARANTINE Permitted denial actions MAY include: • deny; • delay; • downgrade; • redact; • suppress; • quarantine; • zeroize; • request new authority; • escalate to a cold path; or • route for review. The source expressly supports denial, suppression, quarantine, redaction, zeroization, delay, downgrade, isolation and review following failed validation. 5.17. No Fail-Open on Timeout Das Expires 27 February 2027 [Page 46] Internet-Draft Agentic Execution Finality August 2026 A timeout MUST NOT be interpreted as approval. For a protected consequence: verification timeout != permission Instead: verification timeout | +--> retry within policy | +--> escalate | +--> delay | +--> downgrade | `--> deny If no permitted resolution is available, the Candidate Act remains non-effective. 5.18. Alternate-Path Closure Das Expires 27 February 2027 [Page 47] Internet-Draft Agentic Execution Finality August 2026 An implementation MUST consider alternate paths capable of producing the same protected consequence. For precise location, relevant paths may include: main application upload analytics SDK advertising SDK telemetry browser upload cloud sync backup clipboard bridge file export AI-agent tool call background service For an AI act: normal tool dispatcher direct API call shell execution browser control IPC memory write alternate plugin For hardware: CPU path GPU DMA SmartNIC DPU accelerator driver alternate interconnect Moving the act to a different path MUST NOT inherently remove the execution-finality requirement if that path can produce the same protected consequence. The source explicitly states that routing around a cold path, using stale cached authority, fragmenting an act, relocating the Finality Sink, or moving effectuation to another component does not create a bypass. 6. Security Considerations The execution-finality architecture is intended to prevent an upstream security decision, AI decision, application permission, credential, or network authorization from automatically becoming authority for an external consequence. The principal security objective is: A protected consequence MUST remain technically non- effective unless current, act-specific, scoped authority is verified at the applicable Finality Sink. Implementations MUST consider attacks against every load-bearing element of the finality chain. Das Expires 27 February 2027 [Page 48] Internet-Draft Agentic Execution Finality August 2026 6.1. Replay Attacks An attacker may attempt to reuse a previously valid finality authority. For example: Act A approved | v Authority A issued | v Act A completed | v Attacker copies Authority A | v Attempts second consequence A conforming implementation MUST prevent this. Finality authority SHOULD therefore be bound to one or more of: Candidate Act identity Candidate Act digest nonce sequence state policy epoch revocation epoch protected state scope Finality Sink identity consumption state Single-use authority MUST be consumed or otherwise made unusable before or atomically with effectuation. The source specifically identifies replay, stale retry, duplicate effectuation, cross-sink reuse and consumed-authority reuse as conditions that must prevent effectuation. 6.2. Candidate Act Substitution An attacker may obtain valid authority for one Candidate Act and attempt to substitute a different operation. Examples include: authorized: send coarse location substituted: send precise GPS or: authorized: payment = 50 Das Expires 27 February 2027 [Page 49] Internet-Draft Agentic Execution Finality August 2026 substituted: payment = 5,000 or: authorized: Tool A substituted: Tool B The Finality Sink MUST verify that the actual consequence corresponds to the act or digest bound to the authority. A load-bearing field change MUST invalidate authority unless separately authorized. 6.3. Sink Substitution and Cross-Sink Laundering Authority issued for one Finality Sink MUST NOT automatically be usable at another sink. For example: Authority: sink = approved-data-egress-A Attack: redirect through egress-B or: Authority: tool-dispatcher-A Attack: direct shell interface A Finality Sink MUST verify its own identity or protected boundary identity against the authority before effectuation. The source identifies sink mismatch, boundary mismatch and cross-sink laundering as explicit conditions for denial. 6.4. Stale Policy and Revocation An act MAY have been valid when created but invalid when effectuation is attempted. Examples include: • revoked tool authority; • changed location-export policy; • new data-residency restriction; • revoked model version; • changed mission state; • new financial restriction; • expired user authorization; or • changed recipient status. The Finality Sink SHOULD therefore verify current policy and revocation state immediately before consequence. An old upstream approval MUST NOT automatically override current protected state. Das Expires 27 February 2027 [Page 50] Internet-Draft Agentic Execution Finality August 2026 6.5. Prompt Injection and Instruction Laundering Agentic AI creates additional attacks because the proposed Candidate Act may have been influenced by content that was never intended to function as an instruction. Such sources may include: • retrieved documents; • webpages; • email; • screen-visible text; • tool responses; • database content; • persistent memory; • vector-store records; • multimodal inputs; • malicious plugins; • indirect instructions; or • another agent. The source specifically identifies hidden prompt injection, poisoned retrieval, stale memory, manipulated tool responses, screen-observed instructions and multimodal inputs as possible influences on consequence-bearing AI acts. A PED MAY therefore evaluate instruction provenance, runtime behavior, retrieval provenance, memory provenance, neural influence evidence, or equivalent trust signals before releasing finality authority. 6.6. Agentic Cascade and Delegation Attacks A trusted agent may delegate to another agent, which delegates again, creating a chain whose cumulative authority or consequence exceeds the original task. Example: User | v Agent A | +--> Agent B | +--> Agent C | +--> payment tool +--> external API +--> data export A marketplace entry, advertised capability, endpoint response, or tool description MUST NOT by itself be treated as authority for consequence-bearing delegation. The source states that discovery of an external agent does not establish trust to receive credentials, data, payment authority, file access or execution privileges. An implementation MAY maintain cumulative delegation depth, resource use, tool-call count, execution velocity or consequence state. Where the permitted envelope is exceeded, further finality authority SHOULD be withheld. Das Expires 27 February 2027 [Page 51] Internet-Draft Agentic Execution Finality August 2026 6.7. Protected-State Integrity An attacker may attempt: • rollback; • deletion of consumed state; • nonce reset; • policy-epoch rollback; • revocation-epoch rollback; • stale snapshot restoration; • duplicate authorization; or • protected-state substitution. High-assurance implementations SHOULD use protected monotonic state, sealed storage, secure counters, authenticated state transitions or equivalent mechanisms where rollback could produce a consequence. 6.8. Failure of the PED The PED is security critical. If its integrity cannot be established, the implementation SHOULD NOT release finality authority for protected consequence classes. Depending on the risk class, the system MAY: • fail closed; • downgrade; • quarantine; • require another protected validator; • require human approval; • move to a cold path; or • disable the protected consequence. 6.9. Failure of the Finality Sink The Finality Sink is equally load-bearing. An upstream PED cannot compensate for a sink that permits consequence without checking authority. The architecture therefore requires the complete chain: Non-Effective State + PED Validation + Protected Evidence + Scoped Authority + Protected State + Finality Sink Verification A Finality Sink without act-bound authority is not equivalent to the described architecture. The source expressly treats these elements as mutually load-bearing rather than independent advisory controls. Das Expires 27 February 2027 [Page 52] Internet-Draft Agentic Execution Finality August 2026 7. Agentic-AI Threat Model A representative agentic-AI deployment SHOULD consider at least the following threats: T1 Direct prompt injection T2 Indirect prompt injection T3 Poisoned retrieval T4 Poisoned persistent memory T5 Malicious tool response T6 Tool substitution T7 MCP/server substitution T8 Unauthorized delegation T9 Recursive agent escalation T10 Stale user authority T11 Destination substitution T12 Cross- jurisdiction export T13 Exact-location over-disclosure T14 Replay of previous authority T15 Cross-sink authority reuse T16 Runtime/model- state deviation T17 Alternate-path effectuation The protocol does not require that the model itself reliably detect every one of these attacks. Instead, the security objective is that a consequential operation influenced by such a condition still cannot become effective unless the required finality predicates succeed. The source permits protected descriptors and validation to bind model identity, model state, runtime behavior, instruction provenance, neural influence, policy state, nonce, scope and Finality Sink identity. 8. Interoperability and Deployment Model The execution-finality architecture is intended to coexist with existing systems. It MAY consume decisions or evidence from: identity systems OAuth/access-control systems RBAC policy engines AI safety systems attestation systems telecom authentication enterprise policy regulatory policy human approval risk engines content classifiers However, those systems provide inputs to finality validation. They do not replace Finality Sink verification. This preserves the distinction: policy decision != final consequence Das Expires 27 February 2027 [Page 53] Internet-Draft Agentic Execution Finality August 2026 9. IANA Considerations This version of the document requests no IANA actions. It does not presently define: • a new IP protocol number; • transport port; • DNS record type; • media type; • URI scheme; or • mandatory global registry. If later versions standardize wire-format fields, error codes, consequence classes, precision classes, capability types or protocol parameters, an IANA registry MAY be proposed at that time. The EF-xxx failure identifiers shown in Phase 4 are currently illustrative protocol-design identifiers and are not IANA assignments. 10. Intellectual Property Considerations Certain technical concepts described in this document are associated with pending patent applications in the DAS Protocols family. The source identifies, among others: PCT/IB2026/054453 Capability- Validated Inbound Descriptor / CVID-PCT-1 PCT/IB2026/055615 THE DAS PROTOCOLS PCT/IB2026/055760 THE DAS PROTOCOLS PART II PCT/IB2026/055870 THE DAS PROTOCOLS PART III PCT/IB2026/056058 THE DAS PROTOCOLS PART IV PCT/IB2026/053385 Algorithmic Logic Fingerprint-related architecture The source states that these filings disclose related elements including non-bearer execution handles, protected enforcement domains, neural candidate acts, AI-output finality, device-side enforcement, agentic tool-use enforcement and Algorithmic Logic Fingerprints. Any IETF intellectual-property disclosure required in connection with standardization of this work should be handled separately in accordance with applicable IETF IPR procedures. This section is informational and does not define licensing terms. 11. References The following references are relevant to the motivation, policy context, or technical lineage described in this document. Das Expires 27 February 2027 [Page 54] Internet-Draft Agentic Execution Finality August 2026 11.1. Normative References At this stage, this document does not define a completed interoperable wire protocol requiring a finalized normative dependency set. A later revision SHOULD add the applicable IETF normative references once the encoding, transport, integrity mechanism and protocol negotiation elements are selected. 11.2. Informative References The following materials are identified in the source disclosure as relevant background or policy context: [EO14110] United States Executive Order 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, October 2023. [EDPB-28-2024] European Data Protection Board, Opinion 28/2024. [EU-AI-ACT] Regulation of the European Union concerning artificial intelligence. [ENISA] European Union Agency for Cybersecurity, relevant threat-landscape and network-security material. [NATO-CCDCOE] NATO Cooperative Cyber Defence Centre of Excellence, material concerning cyber operations and critical infrastructure. [NATO-STRATCOM] NATO Strategic Communications Centre of Excellence, work concerning metadata, telemetry and information exploitation. [UK-OSA] United Kingdom Online Safety Act 2023. [3GPP] 3GPP specifications relevant to 5G, 5G-Advanced, O-RAN-adjacent deployment environments and non-terrestrial networks. Das Expires 27 February 2027 [Page 55] Internet-Draft Agentic Execution Finality August 2026 [ITU] ITU work concerning future networks and AI-assisted telecommunications. These references provide motivation or deployment context. They do not themselves define the execution-finality protocol. The source expressly maps the long-felt need to frontier-AI governance, data protection, telecommunications, sovereign infrastructure, cybersecurity, financial finality and digital child safety. 11.3. Technical-Lineage References [DAS-CVID] PCT/IB2026/054453, Capability-Validated Inbound Descriptor / CVID-PCT-1. [DAS-MOTHERSHIP] PCT/IB2026/055615, THE DAS PROTOCOLS. [DAS-II] PCT/IB2026/055760, THE DAS PROTOCOLS PART II. [DAS-III] PCT/IB2026/055870, THE DAS PROTOCOLS PART III. [DAS-IV] PCT/IB2026/056058, THE DAS PROTOCOLS PART IV. [DAS-ALF] PCT/IB2026/053385, Algorithmic Logic Fingerprint-related architecture. These applications are identified in the source as related technical disclosures. 12. Conclusion For agentic systems, model output and tool selection are upstream computation. External execution occurs only after the Candidate Act is validated, protected evidence is committed, scoped finality authority is issued, and the intended dispatch sink independently verifies that authority. The resulting rule is: tool selection is not tool-execution authority; computation is not authority. Author's Address Das Expires 27 February 2027 [Page 56] Internet-Draft Agentic Execution Finality August 2026 Sangam Das Independent Inventor Balasore 756001 Odisha India Email: info@sangamdas.com Das Expires 27 February 2027 [Page 57]