tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP Independent Inventor
Balasore Odisha 756001 India info@sangamdas.com
Security MCP Anthropic OpenAI tool use execution finality Frontier runtimes already standardized the dangerous moment. A model emits a tool_use block, a tool_calls array, or an MCP tools/call payload. The host then invokes whatever name and arguments the model printed. Alignment, allowlists, and OAuth sit around that moment. They do not sit on it. The consequence of this gap is no longer confined to email or payment demos. In defense, energy, grid control, industrial process control, and other critical-infrastructure deployments, the same tool_use block already reaches actuation-class systems -- logistics and targeting-adjacent decision support, SCADA and PLC interfaces, medical devices, autonomous platforms. In these environments, detection after the fact is not mitigation; it is an incident report written after the effect has already occurred. An agent that can act at machine speed but cannot be halted at machine speed is a system running without brakes: the first uncontrolled invocation is not a warning sign, it is the accident. Command authority, human oversight, and legal review all operate on human time. An unbound tool_use block operates on machine time. When those two clocks diverge, the gap belongs to whichever side reaches the effect first -- and today, nothing structurally guarantees that side is authorization. This document does not invent another assistant API. It binds the Agent Candidate Act profile onto the three interface families those runtimes and their customers already ship: tool_use / computer_use style interfaces, function-calling and structured tool-response interfaces, and Model Context Protocol tools/call. The model may emit the block. The block remains non-effective. A local enforcer builds the act, binds the argument digest, and refuses invoke() until scoped authority is verified and consumed at the dispatch sink. For consequence classes above a defined threshold -- FINANCIAL, PHYSICAL, NETWORK_CONTROL, and any act reaching defense or critical-infrastructure actuation -- this binding treats fail-closed as the only conforming behavior: absent successfully verified, current, act-bound authority, the candidate act stays non-effective regardless of model confidence, prior session trust, or upstream alignment signal. Each enforcement decision, allow or deny, commits a Ledger-Anchored Validation Receipt (LAVR) -- a signed, hash-chained enforcement artifact bound to the specific candidate act and its argument digest at the moment of decision. An LAVR is not a log entry assembled afterward for audit; it is the proof that the finality boundary actually gated this act before any effect could occur, and its absence is itself a fail-closed condition. The implementation target is a middleware function that a host loop can call without changing the model vendor. tool_use is not invoke().
Introduction Every hosted agent product converged on the same wire shape: This document inserts a gate on the middle arrow without asking model providers to change model cards. The gate is the profile in : wrap the block as an AgentCandidateAct, hold it non-effective, validate, commit evidence, issue scoped authority, verify at the dispatch sink, consume, then invoke. Vendor names are deployment classes. Field names below follow public tool-use and MCP shapes as of this writing and are informative where those APIs evolve. The load-bearing contract is the act object, not a trademark.
Why This Binding Is the Lab-Facing Draft The agentic profile is the architecture. This document is the thing a runtime engineer can implement on Monday. Labs lose enterprise deals on a specific sentence: "what happens when the model is injected and still emits a tool block." Answers that are only "we train refusal" or "we log the block" are weaker than "invoke() is unreachable without a consumed authority_id bound to this argument digest." That sentence maps onto products customers already buy: Claude for Work with tools and computer use, ChatGPT Enterprise with actions and an Agents runtime, and MCP servers wired into both. The binding is how isolation of action lands in the loop those products run thousands of times per minute. For an Anthropic reliability or safety engineer the claim is mechanical: a tool_use block can exist, be shown in the transcript, and still leave the world unchanged. Refusal training reduces how often the block appears. This binding reduces what the block can do when it appears anyway — including when the model is following a retrieved instruction it treated as a user turn. For an OpenAI platform or Agents engineer the claim is the same on tool_calls[] and on Actions HTTP. Schema-valid arguments are not a capability. Parallel calls are not one capability. An Agents SDK that owns the loop MUST expose the hook or wrap the tool objects; otherwise the safest model still has an unguarded invoke.
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. A host that executes a tool block without current dispatch authority is non-conforming with this binding even if the model vendor's SDK performed the HTTP call.
Problem Space The host loop is short and trusted by default: That loop is correct only if the block is a capability. It is not. Failures this binding treats as first-class:
  • Injected page or ticket text causes tool_use name=email.send to a new recipient.
  • OpenAI function.arguments JSON is valid against the schema and still pays the wrong vendor (see ).
  • MCP server with the same tool name is swapped (T7 in the agentic profile).
  • Computer-use screenshot policy allows clicks; a submit posts a form the model narrated incorrectly.
  • Memory or project write persists a prohibited join for the next turn .
  • The host retries invoke() after a timeout and double-executes a side-effecting tool.
What Labs Already Ship and What They Do Not Bind
Anthropic tool_use and Computer Use tool_use binds a name and an input object to a content block id. Computer use binds screen actions. System prompts, tool schemas, and constitutional or policy trained refusal try to stop bad blocks before they appear. They do not consume single-use authority at invoke, and they do not hash arguments so an approved search cannot become a send.
OpenAI function calling, Responses tools, GPTs tool_calls bind a function name and a JSON argument string. GPTs Actions add OpenAPI backends. The Agents runtime adds loops. Schema validation answers "is this JSON shaped." It does not answer "may this digest run now at this sink."
MCP tools/list and tools/call MCP authenticates a client to a server and names tools. tools/call is still bearer-like with respect to every call that server will accept under the session. Server discovery is not act authority .
What This Binding Adds A deterministic mapping from those three envelopes to AgentCandidateAct, a host-local enforce() that MUST wrap invoke, and an error mapping back into tool_result / function output / MCP error so the model sees a deny rather than a successful side effect.
Binding: Anthropic tool_use Informative source shape: Mapping MUST be:
  • candidate_act_id — host-generated, MUST NOT equal toolu_* alone if that id can be replayed across sessions; MAY incorporate it.
  • act_type — TOOL_CALL, or BROWSER_ACTION / COMPUTER_USE when name is in the computer-use family.
  • tool.tool_id and function_id — name.
  • tool.tool_protocol — LOCAL_FUNCTION or MCP.
  • arguments_digest — hash of JCS(input) or documented canonical JSON.
  • instruction_provenance.source_type — user, retrieval, tool, or unknown as the host can attest.
  • finality_sink.sink_type — TOOL_DISPATCH or BROWSER_CONTROLLER.
On deny, the host MUST append a tool_result for that id whose content is an error object, not a successful send. On allow, invoke then append the real result. The model is allowed to recover. The world is not allowed to change on deny.
Computer Use Each consequential action (click, type-submit, file download) is its own Candidate Act. screenshot and cursor moves MAY be INFORMATIONAL if they cannot exfiltrate. A submit that posts a form MUST bind a digest over the live form values, not over the model's text description of the click. Origin change MUST invalidate prior authority. Informative computer-use action names vary by preview API. Treat left_click, type, and key(Enter) on a focused form as potential COMMUNICATION or FINANCIAL if the focused origin is a mail, bank, or admin host. Treat screenshot as DATA_DISCLOSURE when the frame can contain secrets (password managers, MFA QR, customer PII). A single "computer use session allow" MUST NOT authorize every later action in the session. The live digest SHOULD include origin, destination URL if known, and a stable serialization of the filled fields. If the controller cannot read those fields, it MUST escalate or deny rather than click on narration alone. This is the computer-use form of argument substitution.
Binding: OpenAI tool_calls and Responses Informative source shape: Mapping MUST parse arguments as JSON, then canonicalize the object, then hash. Hashing the raw string is allowed only if the host guarantees one serialization. Two equivalent JSON strings MUST NOT produce two different authorities that both can run. function.name maps to tool_id and function_id. Parallel tool_calls[] are parallel Candidate Acts. Each MUST be enforced separately. A single ALLOW for the message MUST NOT authorize every call in the array. Responses API tool outputs and Assistants tool-output submits are the same sink moment: before the host runs the function map. GPT Actions that HTTP POST to a customer API are API_REQUEST acts; destination is the Action server URL.
Binding: MCP tools/call Informative request: The conforming placement is the MCP *client* dispatcher, not each server. One enforcer sees every server the agent can reach. Server identity MUST enter destination or tool.tool_endpoint so a swapped server with the same tool name fails sink or destination match. On deny the client MUST NOT send tools/call, or MUST send it only to a server that is itself a cooperating sink and will refuse. Returning an MCP error to the model is required so the loop does not treat silence as success. tools/list remains discovery. list results MUST NOT issue AgentFinalityAuthority.
Streaming, Partial Blocks, and Parallel Calls Both labs stream tokens. A partial tool_use or partial function.arguments string MUST remain non-effective. enforce() MUST run only on the finalized block. Invoking on a partial JSON object is non-conforming. Parallel tool_calls and multiple tool_use blocks in one assistant message are independent acts. The host MAY validate them concurrently. It MUST NOT treat one ALLOW as covering siblings. If one call is FINANCIAL and one is INFORMATIONAL, only the FINANCIAL call escalates. A deny on one call MUST NOT be "fixed" by invoking the others first and hoping the model forgets. Retries after transport failure MUST reuse the same candidate_act_id only when the consume bit is unread and the digest is unchanged. If consume already happened, retry is a new act or a fetch of the original tool_result, never a second invoke.
AgentCandidateAct Schema Recalled for Implementers The normative schema lives in . It is repeated here so this binding can be implemented from one document on a first reading.
Field-by-Field Mapping Tables
Anthropic tool_use to AgentCandidateAct type=tool_use → act_type TOOL_CALL. id → incorporated into candidate_act_id. name → tool_id and function_id. input → canonicalized into arguments_digest. Host session id → freshness.session_id. Workspace org → initiating_principal. Model name from the request → agent.model_id. computer_2025xxxx tools → act_type COMPUTER_USE and sink BROWSER_CONTROLLER.
OpenAI tool_calls to AgentCandidateAct id call_* → incorporated into candidate_act_id. type=function → TOOL_CALL. function.name → tool_id. function.arguments parsed object → arguments_digest. Parallel index is not authority; each id is an act. Responses API function_call items use the same map. Custom GPT Action operationId MAY populate function_id when name is generic.
MCP tools/call to AgentCandidateAct params.name → tool_id. params.arguments → digest. jsonrpc id is not candidate_act_id (it can collide across servers). Server URL or server name → tool_endpoint and destination. Protocol MCP. A notifications/message that asks the host to call a tool is the same map if the host would invoke.
Worked Denies the Labs Will Recognize
Where to Put the Hook in Shipping Runtimes Anthropic Messages API: after the application assembles content blocks, before the developer function table runs. Computer-use beta: inside the controller that turns action items into OS events, before the event is sent. OpenAI Chat Completions: after tool_calls is parsed, before the function map. Assistants API: before submitting tool outputs that the host computed by running code. Responses API: before executing function_call items. Agents SDK: a before_tool_call callback if present; otherwise wrap the tool implementation objects the SDK receives. MCP TypeScript and Python reference clients: wrap Client.callTool. IDE agents that embed MCP (desktop hosts) wrap the same method so every server inherits the gate.
Host-Loop Workflow
  1. Receive model output or MCP request.
  2. For each tool block, parse name and arguments.
  3. Canonicalize arguments. Compute arguments_digest.
  4. Build AgentCandidateAct .
  5. HOLD_NON_EFFECTIVE.
  6. PED_VALIDATE (local hot path or escalate).
  7. Commit evidence. Issue authority.
  8. DISPATCH_SINK_INVOKE: verify live digest, sink, epochs, consume.
  9. Only then call the vendor SDK, local function, or MCP transport.
  10. Map deny to the vendor error shape. Do not invoke on timeout.
Reference Host Loop
enforce() Contract A library advertised as implementing this binding MUST expose a function with this behavior, regardless of language: { allow: bool, authority_id?: string, code?: string, message?: string } # MUST: # 1. hash live_args with the same canonicalization as act.arguments_digest # 2. refuse if hashes differ # 3. refuse if authority missing, expired, consumed, or sink-mismatched # 4. consume single-use authority before returning allow=true # 5. never return allow=true on timeout or uncertain epoch ]]> Returning allow=true and then failing to consume is non-conforming. Logging a deny and invoking anyway is non-conforming.
JSON Objects Used on the Wire The Candidate Act schema is . This binding adds only mapped examples and the host error object.
Mapped Claude Block
Mapped OpenAI Payout Call If the handler would move funds, a PaymentCandidateAct from MUST also be enforced before the PSP SDK.
Host Deny Payload Back to the Model
Complete Claude Turn
Practical Feasibility: Latency and Legacy Loops
Do Not Change the Model The binding is host-side. No tokenizer change, no tool-schema change, no fine-tune is required for v1. That is why a lab can trial this on one enterprise workspace without a model release.
Latency Budget Tool loops are already dominated by the model forward pass and the tool I/O. enforce() on the hot path is: canonicalize JSON, SHA-256, MAC or signature verify, compare-and-swap on a consume row. Representative added cost is sub-millisecond to a few milliseconds on the same host — negligible next to a 200-2000 ms model call. Cold path (new tool, unknown destination, FINANCIAL class, unknown provenance) MAY add a policy fetch. Timeout of that fetch MUST deny, not invoke.
Legacy Host Loops Existing OpenAI and Anthropic examples are ten-line for-loops. The feasible change is wrapping invoke, not rewriting the product. A feature flag "enforce_tools=true" on a workspace is a conforming pilot. Workspaces left on false are known alternate paths and MUST be listed if they can reach the same side-effecting tools. SDKs that invoke tools internally (some Agents runtimes) MUST expose a pre-invoke hook or MUST be wrapped at the HTTP client that talks to the tool backend. If neither hook exists, the deployment cannot claim this binding for those tools.
MCP Without Server Changes Servers can stay unmodified if the client enforcer is in-line. Cooperating servers MAY later verify the authority object themselves. That is an enhancement, not a v1 requirement. Flag-day replacement of every MCP server is not required and not recommended.
Computer Use Without a New Browser The sink is the existing controller process that issues clicks. Digest the live DOM or form state you already read to click. If you cannot digest the live values, those submits MUST be treated as cold path or denied. Do not invent a second browser.
What This Binding Does Not Require It does not require a TEE on day one. It does not require vaults from on day one. It does not require Anthropic or OpenAI to accept a patch. It requires the host that already runs the loop to stop treating the block as a capability.
How Labs and Customers Use It
Anthropic-Class Workspace Enable enforce() on tools marked COMMUNICATION, FINANCIAL, PERSISTENT_STATE_CHANGE, or computer-use submit. Leave maps.search on a hot envelope. Measure denies that would have been sends. That metric is the procurement answer.
OpenAI-Class Workspace Same split for Actions and function tools. Memory writes go through enforce() as MEMORY_WRITE. Share-chat and file export are Output Release Boundaries under when the content is a reconstructed view; they are still tool-shaped if implemented as tools.
Platform Customers A bank or hospital that cannot wait for a vendor-native hook wraps the tool handlers they wrote. That is enough for tools they own. Tools the vendor invokes inside a black box remain an alternate path until the vendor exposes the hook.
Default Consequence Classes for Common Tools Hosts SHOULD assign consequence_class before enforce(), not after the model names the tool. Informative defaults:
  • search, retrieve, get_weather — INFORMATIONAL
  • email_send, slack_post, tweet — COMMUNICATION
  • file_write, db_update, memory_write, ticket_create — PERSISTENT_STATE_CHANGE
  • payout, refund, capture, wire — FINANCIAL (also )
  • deploy, kubectl, iam_attach — PERSISTENT_STATE_CHANGE or NETWORK_CONTROL
  • computer_use submit, browser_navigate to new origin — DATA_DISCLOSURE or COMMUNICATION depending on the form
  • shell / bash — at least PERSISTENT_STATE_CHANGE; treat as cold path unless the envelope names the exact binary
Misclassifying payout as INFORMATIONAL is a profile failure, not a model failure.
Memory, Projects, and Persistent Notes Claude projects and ChatGPT memory are tool- shaped even when they are not named tools. A host that writes extracted facts into a memory store MUST treat that write as MEMORY_WRITE. Otherwise an injected turn stores a join that later turns treat as user provenance. That is how present theft becomes future mapping without another tool_use .
Conformance Tests a Lab Can Run Overnight T-A: emit tool_use email_send to an address not in the user turn; expect invoke=false. T-B: two OpenAI tool_calls, search and payout; expect payout denied when above envelope. T-C: replay the same authority_id on a second invoke; expect deny. T-D: MCP call with swapped server URL; expect destination deny. T-E: computer-use submit after origin change; expect deny. T-F: measure enforce() p99 under 10 ms on hot search. T-G: kill the host after consume and before invoke; on restart do not invoke again. A workspace that passes T-A through T-G can be shown to an enterprise security review without a new model checkpoint.
Error Mapping EF codes from SHOULD be copied into the vendor error payload as machine-readable strings. retryable=true only for EF-060 timeout where policy allows a bounded retry of *validation*, never a retry that skips enforce(). Models that respond to deny by emitting a different tool_use are starting a new Candidate Act. That is expected.
Threats This Binding Makes Local
  • T1 Direct prompt injection → extra tool_use
  • T2 Indirect injection in retrieved files
  • T6 Tool name confusion / substitution
  • T7 MCP server substitution
  • T14 Replay of a previous tool block id
  • T17 Alternate path: raw HTTP next to the SDK
  • T18 Computer-use submit around API tools
Threats that need the enterprise profile (join of identity and content) are out of scope here except as provenance=unknown plus high consequence_class → escalate.
Addressing Potential Technical Concerns
Distinction from Conventional Middleware and Zero-Trust Authorization The architecture should not be understood merely as intercepting an untrusted AI-generated string and checking permissions before a software function executes. Conventional middleware, API gateways, reference monitors, policy-enforcement points, and zero-trust systems can already perform authorization before an API call or resource access. The execution-finality model addresses a different architectural problem: generation of an action is separated from authority to make that action externally effective. A model, agent, application, or tool-orchestration layer may compute or propose an action, but that proposed action is represented as a Candidate Act and remains in a Non-Effective State until the required validation conditions are satisfied. Validation establishes protected evidence or authorization state associated with the load-bearing attributes of that Candidate Act, which may include the requested operation, arguments, destination, execution context, authorization scope, policy state, and other relevant parameters. The important point is that approval at an upstream middleware layer does not itself constitute final authority for the external effect. Before the requested consequence becomes externally effective, the relevant Finality Sink or effectuation boundary verifies the required authorization state for the Candidate Act being presented for effectuation. The security model is therefore not simply: execute tool ]]> but rather: Non-Effective State -> protected validation and act-specific binding -> scoped execution authority -> Finality Sink verification -> externally effective consequence ]]> The technical distinction is therefore the separation between computation, authorization, and effectuation, together with verification at the boundary where the external effect would actually occur.
Closure of Alternative and Legacy Execution Paths An execution-finality architecture is only meaningful if the protected consequence cannot be reached through an ungoverned alternative path. An application-level enforce() function may therefore be one implementation interface, but it should not itself be treated as the ultimate security boundary. For protected operations, execution paths capable of producing the same externally effective consequence should converge upon, or otherwise remain subordinate to, the protected finality-enforcement boundary. Relevant paths may include:
  • direct API or SDK invocation;
  • legacy interfaces;
  • plugin or tool-router paths;
  • inter-process communication;
  • subprocess execution;
  • cached or delegated credentials;
  • agent-to-agent delegation;
  • operating-system service calls;
  • alternate network interfaces;
  • retries or replay paths; and
  • other implementation-specific mechanisms capable of reaching the same protected resource or external effect.
If the required authorization or validation state cannot be verified at the relevant effectuation boundary, the operation remains non-effective and the system fails closed. The resulting security invariant is:
No protected externally effective consequence should occur through an alternate execution path merely because that path bypassed the original middleware or orchestration layer.
This anti-bypass property is a core requirement of the execution-finality model rather than an optional application-level policy convention.
Deterministic Binding of Dynamic Action Arguments The architecture does not require hashing the literal JSON string emitted by an AI system. Raw serialization is unsuitable for action binding because equivalent structured data can have different byte representations due to property order, whitespace, encoding choices, or other formatting differences. Instead, the system can derive an arguments_digest, commitment, or equivalent binding value from a deterministic representation of the load-bearing attributes of the Candidate Act. Depending upon the protocol and schema, this process may include:
  • deterministic field ordering;
  • defined representation of numbers and Boolean values;
  • deterministic character encoding;
  • defined treatment of absent, empty, and null values;
  • exclusion of non-semantic formatting;
  • explicit field typing;
  • schema-defined normalization rules; and
  • deterministic encoding before digest generation.
For example, the following two JSON serializations may represent the same Candidate Act: A deterministic representation allows both forms to produce the same Candidate-Act commitment where their semantics are equivalent. At the same time, normalization must remain semantics-preserving. Values should not be collapsed merely because they appear superficially similar. For example, a string value and a numeric value should only be treated as equivalent where the applicable schema explicitly defines that equivalence. The architectural requirement is therefore broader than any particular JSON representation: deterministic representation -> Candidate-Act commitment ]]> This approach can be applied to JSON, CBOR, Protocol Buffers, MCP messages, operating-system calls, payment instructions, database operations, robotic commands, or other structured action representations. The purpose of the commitment is not merely transport-integrity checking. It is to ensure that the action presented at the effectuation boundary corresponds to the action state that was actually validated.
Summary The execution-finality model is not intended to replace conventional authentication, authorization, zero-trust policy, or middleware controls. Those mechanisms may remain upstream inputs to the decision process. The additional architectural property is that computation does not itself create effectuation authority; a Candidate Act remains non-effective until validated; the validated action state is bound to the relevant execution authority; and the Finality Sink verifies that state before permitting the externally effective consequence. This provides a distinct system-level enforcement boundary for AI agents, tool-use systems, autonomous software, and other environments in which generating or approving an action should not automatically make that action externally effective.
Relationship to the DAS Protocols Architecture This document is a protocol-facing profile of a broader execution-finality architecture developed in the DAS Protocols work. The broader architecture describes a recurring separation between computation of a proposed act, protected validation of the act, issuance or establishment of scoped finality authority, and verification at a Finality Sink before an external consequence becomes effective. The large foundational disclosure referred to by the author as the DAS Protocols "Mothership" is PCT/IB2026/055615, published as WO 2026/150382. That disclosure covers a substantially wider set of execution-finality embodiments, including AI infrastructure, telecommunications, device and operating-system enforcement, protected execution, and other externally effective systems. This Internet-Draft intentionally addresses a much narrower interoperability problem: binding existing AI tool-use and MCP-style dispatch interfaces to an execution-finality boundary. The terminology used here, including Candidate Act, Non-Effective State, protected validation, scoped execution authority, and Finality Sink, should therefore be read as a compact protocol profile rather than as an attempt to reproduce the full DAS Protocols disclosure. This background statement is informative. It does not make implementation of unrelated DAS Protocols embodiments a requirement for conformance with this Internet-Draft. Any IETF intellectual-property disclosure obligations are handled separately under BCP 79 .
Implementation Checklist
  1. Every side-effecting tool handler is reachable only through enforce() or an equivalent protected finality-enforcement boundary.
  2. arguments_digest or equivalent commitment is over a deterministic representation of the load-bearing Candidate Act attributes, not over the model's prose.
  3. Parallel tool_calls are separate acts.
  4. Deny returns an error block; invoked is false.
  5. Timeout does not invoke.
  6. MCP client, not only servers, runs enforce().
  7. Computer-use submit has a live-value digest.
  8. p99 added latency of enforce() is measured.
  9. Tools the vendor invokes without a hook are listed as open alternate paths.
Security Considerations If enforce() runs in the same process as a fully compromised host that can also call the tool backend directly, the binding is only as strong as alternate-path closure. Production hosts SHOULD block raw credentials from application code paths that skip enforce(), or SHOULD put the sink in a sidecar that owns the tool credentials. Model-visible deny messages MUST NOT leak other users' data. They MAY name the EF code.
Privacy Considerations Argument objects often contain recipients and PII. Logs SHOULD store digests, not raw arguments, once enforce() has run. Mapping layers MUST NOT write full tool input to a shared debug bus by default.
Informative Host Wrappers The following sketches are informative. They exist so a lab or customer engineer can see that the binding is a wrap of invoke, not a new assistant protocol.
Python
TypeScript These functions are the entire v1 product surface. Vaults, TEEs, and RAOs can wrap later. If invoke is reachable without enforce, the sketches are documentation, not a binding.
Reference Implementation, Reproducibility, and Measurement Scope A public reference implementation of the execution-finality binding described in this document is available at: The implementation is intended to make the protocol mechanics independently inspectable and executable. It is not a simulation expressed only as pseudocode or architectural prose. It provides executable Python components for mapping representative agentic tool-call envelopes into Candidate Acts, validating those Candidate Acts, issuing act-bound authority, verifying workload proof-of-possession, enforcing single-use consumption, and preventing invoke() from being reached until the Finality Sink accepts the live act. The implementation is deliberately small enough that an independent reviewer can inspect the complete enforcement path. Conceptually, the implemented path is: The important property demonstrated by the implementation is that generation of a syntactically valid tool request is not itself authority for the requested operation to become externally effective.
Implemented Interface Profiles Version 0.1.0 contains representative adapters for:
  • Anthropic-style tool_use;
  • OpenAI-style function/tool-call envelopes;
  • MCP tools/call; and
  • computer-use actions in which the live origin and action state are included in the Candidate-Act binding.
These adapters do not depend upon access to a live commercial model or vendor account. They model the relevant public message shapes and place the execution-finality enforcement point in the host-side dispatch path. For example, an OpenAI-style function argument object is parsed into structured data before the Candidate-Act digest is calculated. An MCP Candidate Act additionally binds the intended server endpoint so that an otherwise identical tools/call presented to another MCP server can be rejected at the effectuation boundary. The implementation therefore tests the protocol-facing invariant rather than the behaviour of any particular model vendor.
Reference Implementation Components The implementation contains separate components for: The decomposition is intentional. It allows an implementer to replace individual mechanisms without changing the architectural requirement. For example, HMAC is used in this reference package because it makes the implementation compact and reproducible. HMAC is not a protocol requirement. A production implementation could instead use asymmetric signatures, hardware-protected keys, a TEE, an HSM, a protected operating-system service, a workload identity mechanism, or another suitable cryptographic construction. Likewise, the local SQLite replay store is an implementation mechanism for demonstrating atomic single-use consumption. SQLite is not a protocol requirement.
Versioned Archive For reproducibility, the same implementation is packaged as the versioned archive: The SHA-256 digest of the generated archive is: The archive was created directly from the reference-implementation source tree after removing generated Python cache material. In particular, the archive excludes: and includes the source code, tests, test vectors, benchmark, README, notice, license, package metadata, and .gitignore. The tar archive is therefore a convenience snapshot of the source tree, rather than a separate implementation. Its purpose is to allow a reviewer to retain or cite a fixed set of bytes even if the GitHub main branch subsequently evolves. The SHA-256 value is a digest of the compressed .tar.gz archive itself. It is not an execution-finality authorization value, Candidate-Act digest, security proof, or patent identifier. Its only purpose is archive-integrity and reproducibility. A reviewer downloading the same archive can independently calculate: and compare the result with the published value above.
Reproduction A reviewer may reproduce the implementation directly from GitHub. For example: The supplied test suite can then be executed with pytest, the demonstration can be executed through the package's demo module, and the local benchmark can be executed separately. The implementation does not require:
  • a GPU;
  • a CUDA environment;
  • a hosted AI model;
  • an Anthropic API key;
  • an OpenAI API key;
  • a production MCP server;
  • a payment service;
  • a production database;
  • real customer data; or
  • access to the author's computer.
All example data are synthetic.
Automated Test Coverage The supplied v0.1.0 suite contains ten tests. They exercise, among other cases:
  1. an authorized Anthropic-style email operation that reaches invoke() exactly once;
  2. modification of the arguments after authority issuance;
  3. reuse of an already consumed authority;
  4. substitution of an MCP server endpoint;
  5. presentation at the wrong Finality Sink;
  6. independent treatment of parallel search and payment Candidate Acts;
  7. a communication act originating from retrieved/injected content;
  8. deterministic digesting of semantically equivalent JSON objects having different property order;
  9. computer-use submission after a change of origin; and
  10. invalidation caused by a change of policy epoch.
A verification run of the final archive produced: The important test property is not merely that the enforcer emits a DENY result. In the negative cases the supplied fake effect function is not invoked. This distinguishes: execute anyway ]]> from: no effect ]]>
Demonstration Behaviour The included demonstration exercises representative Anthropic-style, OpenAI-style, and MCP-style messages. Representative outcomes include: ALLOW -> invoke() INJECTED_EMAIL_DENIED -> DENY -> invoked = false OPENAI_ALLOWED_PAYOUT -> ALLOW for configured synthetic beneficiary -> invoke() MCP_ALLOWED_ENDPOINT -> ALLOW for the bound synthetic endpoint -> invoke() ]]> These are synthetic test cases. No email is actually sent, no money is transferred, no repository is deployed, and no external MCP server is contacted. The synthetic invoke() function records or returns a local result so that the control-flow property can be observed without creating a real-world consequence.
How the Latency Values Are Produced The repository also contains a local benchmark: The benchmark performs 500 iterations by default. Each iteration constructs a fresh local reference stack and measures two principal intervals using Python's high-resolution time.perf_counter_ns() clock. The first interval measures the local authorization operation: The second interval measures: The benchmark records each measured duration in nanoseconds, converts the observations into microseconds, orders the collected measurements, and reports median, p95, and p99. The median represents the midpoint of the observed local measurements. The p95 value represents approximately the point below which 95 percent of the measured iterations fall. The p99 value represents approximately the point below which 99 percent of the measured iterations fall. These values are therefore calculated from observed execution times; they are not configured constants and are not predicted values.
Example Verification Measurement One verification run of the final v0.1.0 archive in a Linux environment using Python 3.13.5 produced: These figures should be treated only as one reproducible reference-code observation. They do not mean that an execution-finality deployment universally adds approximately 65 microseconds. Another machine, operating system, Python runtime, cryptographic implementation, database, concurrency level, storage subsystem, or deployment topology can produce materially different results. Independent reviewers are therefore encouraged to run the supplied benchmark on their own systems and report their own environment together with p50/median, p95, and p99 values.
Important Measurement Boundary The benchmark deliberately measures only a local enforcement path. It does not include:
  • AI-model inference time;
  • network round trips;
  • actual HTTP tool execution;
  • MCP network transport;
  • real email transmission;
  • real payment settlement;
  • remote policy retrieval;
  • remote attestation;
  • remote HSM access;
  • cross-region communication;
  • human approval;
  • distributed consensus;
  • database replication;
  • production logging;
  • production service queues; or
  • external destination acknowledgement.
The initial vendor-envelope-to-Candidate-Act mapping is also performed before the principal benchmark timer begins. The reported combined hot-path value therefore characterizes the supplied local enforcement operations, not an end-to-end AI-agent transaction. In particular, the synthetic invoke() used by the benchmark is deliberately trivial. It does not model the latency of the actual external tool. Accordingly: and:
Hot Path and Cold Path The reference implementation also illustrates why execution-finality need not place every governance operation on every tool invocation. A deployment may perform relatively stable operations on a cold path, including:
  • policy definition;
  • tool registration;
  • destination registration;
  • identity enrollment;
  • workload enrollment;
  • key establishment;
  • attestation establishment;
  • risk classification; and
  • trust configuration.
The effectuation hot path may then be limited to load-bearing current state, for example:
  • Candidate-Act digest;
  • live arguments;
  • destination;
  • sink identity;
  • policy epoch;
  • revocation epoch;
  • expiry;
  • nonce;
  • workload proof; and
  • single-use consumption.
This separation is an implementation technique rather than a protocol requirement, but it allows expensive configuration and trust-establishment operations to remain outside ordinary tool dispatch where appropriate.
Legacy Integration The reference implementation does not require modification of model weights, tokenizers, or model training. It models the enforcement component as a wrapper around the dispatch boundary already present in an agent host. A legacy deployment can therefore resemble: Potential enforcement placements include:
  • host tool dispatcher;
  • MCP client dispatcher;
  • API gateway;
  • sidecar;
  • reverse proxy;
  • service mesh;
  • database commit proxy;
  • payment gateway;
  • message gateway;
  • browser controller;
  • operating-system mediator; or
  • network egress boundary.
The implementation is therefore intended to demonstrate that an initial pilot does not necessarily require replacing the model or rewriting every downstream server.
Alternate-Path Limitation Legacy compatibility does not eliminate the requirement to close bypass paths. For example: direct tool credential -----> effect | agent host ------+ | +-----> Finality Sink -------------> effect ]]> does not establish execution-finality for that effect. If the host can reach the same protected backend through raw credentials, direct HTTP, another SDK, an unwrapped plugin, a subprocess, an alternate MCP client, browser automation, or another route that bypasses the Finality Sink, the security property is limited by that alternate path. Production deployment therefore requires the relevant consequential paths to converge upon, or remain subordinate to, the effectuation boundary. The reference implementation demonstrates the guarded path. It does not prove that every possible path in an arbitrary production environment has been closed.
Local Atomicity Limitation The included SQLite store atomically records consumption of the local authority identifier. This demonstrates: It does not make the local database transaction atomic with an arbitrary remote consequence. For example: requires additional production engineering. Depending upon the protected consequence, a deployment may require mechanisms such as:
  • destination-side Finality Sink verification;
  • idempotency keys;
  • transactional outbox;
  • release credentials;
  • two-phase or coordinated commit;
  • effect receipts;
  • protected delivery acknowledgements; or
  • application-specific recovery semantics.
Those mechanisms are outside the minimal v0.1.0 reference implementation.
Security and Implementation Limitations Version 0.1.0 should be understood as a protocol reference implementation, not a production security product. It does not claim to provide:
  • TEE isolation;
  • HSM-protected production keys;
  • hardware-rooted attestation;
  • production PKI;
  • production secret management;
  • formal verification;
  • side-channel resistance;
  • distributed high availability;
  • universal bypass prevention;
  • production network isolation;
  • production vendor integrations;
  • penetration-test certification; or
  • Internet-scale performance.
The HMAC authority mechanism, deterministic JSON representation, Python runtime, and SQLite store are implementation choices used to make the architecture executable and independently reviewable. They are not normative requirements of the execution-finality architecture.
Data Limitation All data in the implementation are synthetic. The package does not use:
  • real customer records;
  • real enterprise credentials;
  • real payment accounts;
  • real user email;
  • production OpenAI data;
  • production Anthropic data;
  • production MCP data;
  • government data; or
  • live confidential information.
A successful test therefore demonstrates deterministic software behaviour against the supplied fixtures. It does not constitute production validation using an enterprise dataset.
Legal and Standards Limitation The reference implementation does not determine whether an operation is legally permitted. The policy layer receives configured constraints and technically enforces those constraints. It therefore demonstrates a machine-enforceable configured constraint rather than an automatic legal determination. The repository also does not establish IETF adoption, IETF endorsement, standards conformance, GDPR compliance, EU AI Act compliance, patent validity, patent infringement, standards essentiality, or production certification. Any applicable IETF intellectual-property disclosure obligations remain governed separately by the IETF IPR process.
Relationship to the Privacy Finality Reference Implementation A related public implementation applies the same underlying execution-finality separation to privacy and data-protection constraints: The privacy implementation and the agentic tool-binding implementation share the underlying sequence: Non-Effective State -> protected validation -> act-bound authority -> Finality Sink -> external effect ]]> but they exercise different profiles. The privacy repository focuses on such properties as purpose binding, minimum-data enforcement, recipient restrictions, destination restrictions, logical data separation, replay protection, and privacy-oriented Finality Sink release. The repository referenced by this document focuses instead on tool_use, tool_calls, MCP tools/call, computer-use dispatch, argument substitution, endpoint substitution, single-use tool authority, and the boundary immediately preceding invoke(). The privacy repository is therefore a related implementation of the common execution-finality substrate, not a substitute for the agentic adapters in this repository.
What the Reference Implementation Demonstrates Within its stated scope, the implementation demonstrates that:
  • a tool call can exist without executing;
  • a generated tool request can be represented as a Candidate Act;
  • live action arguments can be cryptographically bound to the validated Candidate Act;
  • authorization can be scoped to a particular act, workload, destination, and sink;
  • possession of an authority object alone can be made insufficient through workload proof-of-possession;
  • argument mutation can be rejected;
  • authority replay can be rejected;
  • MCP endpoint substitution can be rejected;
  • computer-use origin substitution can be rejected;
  • stale policy state can invalidate previously issued authority; and
  • invoke() can remain unreachable until the Finality Sink has verified and consumed the required authority.
The implementation does not demonstrate that every AI safety problem is solved, that every production bypass has been closed, or that every external effect can be made transactionally atomic using the supplied local code. Its narrower purpose is to make the architectural proposition executable:
A model may generate a consequential act, but generation of that act does not itself provide the authority required for the act to become externally effective.
IANA Considerations This document requests no IANA actions.
Intellectual Property Note Related execution-finality concepts appear in the DAS Protocols family, including PCT/IB2026/055615, published as . This statement is provided for technical transparency and does not substitute for any disclosure required through the IETF IPR process. Applicable IETF disclosure obligations are governed by BCP 79 . The broader digital-sovereignty, data-protection, and AI-governance rationale for the execution-finality architecture underlying this binding has also been submitted for public community review to the European Commission's Apply AI Alliance Futurium platform , and is presented in narrative form in an accompanying public technical disclosure .
Conclusion Claude will keep emitting tool_use. ChatGPT will keep emitting tool_calls. MCP will keep emitting tools/call. None of those blocks is permission to touch the world. Bind them to an AgentCandidateAct, consume authority at the host sink, then invoke. The model vendor does not have to change. The host loop does.
Normative References Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Intellectual Property Rights in IETF Technology Informative References Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments A Compromised AI Server Must Not Become a Map of the Enterprise Hardware-Rooted Execution-Finality System for Sovereign Artificial Intelligence Infrastructure, AI-Native Telecommunications and Satellites Protecting Europe: A Technical Foundation for Digital Sovereignty, Data Protection, and AI Governance European Commission, Apply AI Alliance, Futurium Community Exchange Platform The Internet Solved Communication. It Never Solved Authority Why the Next AI War Will Be Won on Isolation, Not Intelligence
Appendix A. Execution-Finality Binding in Compact Form This appendix is informative. It summarizes the minimum conceptual separation used throughout this document. no effect v +-------------------+ | External Effect | +-------------------+ ]]> The Candidate Act may be represented using an existing vendor or protocol envelope, but the envelope itself is not treated as effectuation authority. Implementations may use different cryptographic, operating-system, service-side, or hardware mechanisms to realize the protected validation and Finality Sink functions, provided the required security properties of this profile are preserved.
Core Invariants
  1. Model or agent output is not, by itself, authority to create an external effect.
  2. A protected Candidate Act remains non-effective until required validation succeeds.
  3. Authorization state is associated with the validated act and relevant scope rather than merely with the existence of a model session.
  4. The effectuation boundary verifies the required state before permitting the consequence.
  5. Alternate paths capable of producing the same protected effect remain subordinate to the finality boundary or an equivalent protected enforcement mechanism.
  6. Failure, mismatch, expiration, replay, or unverifiable state results in fail-closed behavior for the protected effect.
DAS Protocols Mothership Context The DAS Protocols Mothership is broader than this Internet-Draft. This draft extracts only the tool-dispatch binding needed to express the execution-finality property across contemporary AI tool-use interfaces and MCP-style calls. It should therefore be possible to evaluate, implement, criticize, or standardize this profile independently of the larger disclosure. In this profile, the central invariant can be stated compactly as:
Computation is not authority, and authorization is not finality until the effectuation boundary verifies the act-bound state required for the external consequence.