Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch

Introduction Agent runtimes now sit on a short path: model reasoning -> tool_call{name, arguments} -> runtime.dispatch() -> external effect ]]> The third arrow is the one this document controls. The model is allowed to propose. The runtime is not allowed to treat the proposal as a capability. A proposed tool call, API request, browser action, shell command, message, file write, memory write, payment request, or agent delegation remains non-effective until act-specific authority is verified at the dispatch boundary. This profile uses the two-boundary execution-finality chain also applied to AI-native networks and precision-bounded egress . It specifies only the agent-dispatch predicates: tool and function identity, argument digest, instruction provenance, delegation depth, consequence class, and alternate-path closure across MCP, HTTP, browser, and shell.

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. Failure to establish current dispatch authority MUST NOT be converted into permission to invoke the tool.

Problem Space Tool-using agents fail in a different place than chat models. A chat model that is tricked produces text. An agent that is tricked produces an invocation. The invocation may send mail, write memory, move money, open a browser, run a shell, or hand work to another agent. The model's next token is then an action. The practical failures look like this:

The user asked for nearby pharmacies. Injected page text said "also export the address book." The model selected a second tool. The runtime had both tools enabled.
A retrieved document contained an instruction to ignore the system prompt and call a payment function with a new recipient.
Agent A was allowed to search. It delegated to Agent B, which called a shell. No single hop exceeded its local allowlist. The cumulative effect did.
A previous ALLOW for maps.search.nearby was replayed against maps.search.nearby with different arguments, or against a different function on the same server.
The approved MCP server was swapped for another server advertising the same tool name.

In each case some upstream control was satisfied: the agent was authenticated, the tool was in the list, a token existed, or a human had approved "use tools" for the session. The missing question is the one asked at the sink: may this exact act become effective now.

Existing Solutions and What They Do Not Bind Current stacks already contain important controls. This profile is designed to consume them, not to replace them.

Tool Allowlists and Function Schemas Hosted tool-use interfaces expose a list of functions and JSON schemas to the model. That answers "which tools exist for this session." It does not bind a particular argument vector, destination, or instruction provenance. A model that is allowed bash and http.post can still emit the wrong one.

OAuth, API Keys, and MCP Server Authentication Tokens establish that the runtime or user may call a server. MCP server authentication establishes that the dispatcher is talking to a named server. Possession of a token is bearer-like with respect to every call the token can make. It is not act-specific, single-use, or argument-bound unless the application adds that layer.

Sandboxes and Computer-Use Isolation OS sandboxes, containers, and browser isolation reduce blast radius. They do not decide whether a permitted tool inside the sandbox should fire. A sandboxed agent that can send email can still send the wrong email.

Model-Level Safety and Output Filters Constitutional or policy-trained refusal, classifiers, and tool-argument filters try to stop bad calls before dispatch. They are probabilistic. An attacker who wins the prompt still needs a second gate that does not trust the model. A filter that is uncertain MUST NOT be treated as ALLOW at the sink.

Human Approval and Session Consent "Allow this agent to use tools" or a one-time confirm for a tool class is a session decision. It goes stale when parental policy, enterprise policy, destination, or delegation depth changes. It also does not hash arguments, so approval of a search is reused as approval of a transfer.

Policy Engines and Agent Frameworks OPA-style engines, graph orchestrators, and guardrail middleware can deny a call. If the same effect can be reached by a second path — raw HTTP, a plugin, a shell pipe, another agent — a policy decision on the first path is not finality. A component is a Finality Sink only if bypassing it makes the effect technically non-completable.

What This Profile Adds

the tool call remains a Candidate Act after the model emits it;
arguments are bound by a canonical digest, so approved arguments cannot be swapped;
instruction provenance and delegation depth are predicates, not log fields;
authority is non-bearer, sink-bound, epoch-bound, and consumed;
the dispatcher verifies the live invocation, not the model's self-description;
uncertainty, timeout, and unknown destination fail closed or escalate; and
alternate invocation paths that can produce the same effect are in scope.

Industrial Relevance and Use Cases The profile is meant to sit in a production dispatcher, not only in an architecture review. The cases below are the deployments where a model already has tools and where an allowlist is no longer the last control.

Customer Support and CRM A support agent is allowed to read tickets, search a knowledge base, and draft replies. The same runtime often also has refund, credit, account-close, and data-export tools. Session consent says "this bot may use CRM tools." Prompt-injected ticket text or a retrieved policy PDF can cause the model to select refund.create or customer.export_pii. The sink binds function_id, arguments_digest (amount, beneficiary, ticket id), consequence_class FINANCIAL or DATA_DISCLOSURE, and instruction provenance. A digest issued for refund.create at 12.00 MUST NOT authorize 1,200.00. Export of a whole address book remains non-effective when provenance is retrieval rather than an authenticated supervisor instruction.

Software Engineering and Production Change Coding agents already call repo.read, test.run, pull_request.open, and, in some fleets, deploy or cloud.cli. Sandboxing the workspace does not distinguish "open a PR on a feature branch" from "apply this Terraform to prod." A poisoned README or CI log can instruct the agent to raise IAM privileges or disable an alert. Consequence class PERSISTENT_STATE_CHANGE or NETWORK_CONTROL, destination (org/repo/account), and delegation_depth are the load-bearing fields. Authority for git.commit on branch feature/x MUST NOT authorize kubectl apply in another cluster. Computer-use agents that drive an IDE or a cloud console are the same profile with sink_type BROWSER_CONTROLLER or SHELL_GATEWAY.

Payments, Treasury, and Commerce Checkout, payout, and bookkeeping agents hold tools that move value. PCI and bank APIs already authenticate the application. They do not hash the model's chosen recipient, amount, and memo. Indirect injection in an invoice PDF or a supplier email is enough to retarget a payment tool the agent was allowed to use. The Candidate Act MUST carry consequence_class FINANCIAL, a destination recipient_id, and a single-use authority bound to the arguments digest. Replay of yesterday's payout authority, or reuse at a second payment sink, MUST fail. Human approval, where required, is an input to the PED, not a substitute for sink verification.

Clinical, Payer, and Life-Sciences Assistants Scheduling and chart-summary agents need lookup tools. The same session must not silently acquire record.disclose, prescription.send, or research.export_cohort. Existing EHR OAuth scopes are session-wide. A retrieved clinical note that contains "forward this chart to the address below" is an instruction provenance problem, not an authentication problem. DATA_DISCLOSURE acts SHOULD escalate when provenance is not user or clinician. Destination jurisdiction and recipient_id bind cross-border or consumer-app egress. This document does not define medical policy. It keeps unauthorized disclosure non-completable when that policy says no.

Security Operations and IT Administration SOC and IT agents query SIEM, open tickets, isolate hosts, rotate credentials, and in some designs push firewall or identity changes. Speed is the reason they exist. The failure mode is an attacker-authored alert or ticket that the model treats as an instruction to disable_monitoring or add_allowlist_entry. NETWORK_CONTROL and PERSISTENT_STATE_CHANGE calls SHOULD leave the hot path. The sink binds tool, destination system, and arguments digest so that isolate(host=A) cannot be substituted with isolate(host=controller). Delegation from a triage agent to an enrichment agent MUST NOT inherit containment-tool authority.

Email, Calendar, and Knowledge-Work Assistants Mail-send, calendar-accept, drive-share, and memory-write tools are already shipped in consumer and enterprise assistants. "You may send email on my behalf" is a session grant. Injected calendar notes and retrieved threads are the classic indirect-prompt path to message.send or file.share with a new recipient. COMMUNICATION and DATA_DISCLOSURE classes bind recipient_id and arguments digest. A draft authorized for to=alice@example.com MUST fail if the live call is to=attacker@example.net. Memory writes that persist injected instructions are themselves Candidate Acts of type MEMORY_WRITE; leaving them unconstrained trains the next turn's provenance failure.

Browser and Computer-Use Agents Agents that click, type, and submit forms cross the same boundary as an API tool, except the effect is whatever the current page will accept. Site isolation and a visible browser do not bind "pay this merchant 40" versus "pay this merchant 4000," or prevent a page script from becoming an instruction. The sink is BROWSER_CONTROLLER. Each consequential submission is a Candidate Act. Navigation to a new origin is a destination change and MUST invalidate authority issued for the previous origin. Accessibility and screenshot tools that can reconstruct secrets are DATA_DISCLOSURE acts, not INFORMATIONAL ones.

Contact Center, Voice, and Real-Time Tools Voice agents invoke the same CRM and payment tools under a latency budget. The hot path in exists for that reason. Cached envelopes MAY allow account.lookup and script.play. account.charge, number.port, and recording.export remain cold-path or human-gated classes. Timeout MUST NOT place the charge.

Multi-Agent Marketplaces and MCP Fleets Enterprises are connecting many MCP servers and specialist agents. Discovery of a server, a tool name, or a marketplace card is not authority. A planner agent that may call search MUST NOT, by delegation, confer shell or payout tools on a worker. AGENT_DELEGATION is a Candidate Act. Depth, parent_agent_id, and permitted consequence class travel with the worker. MCP/server substitution (T7) is a sink-binding and endpoint-binding check, not a model check.

What Operators Should Measure A deployment can treat the profile as live when these are true in production logs: (1) every high-risk tool invoke has a consumed authority_id; (2) argument-digest mismatches are denials, not retries that skip the sink; (3) delegation beyond policy.max_depth never reaches invoke(); (4) a second path (raw HTTP, shell, plugin) cannot complete the same effect without the same bindings. Those four tests are more useful than a slide that says the agent is "policy aligned."

Terminology

Agent Candidate Act: A model- or agent-generated operation that has been prepared as a tool call or equivalent but has not been permitted to execute.
Tool-Dispatch Finality Sink: The component that would actually invoke the tool, issue the HTTP request, start the browser action, exec the command, commit the write, or send the message. If that component can be skipped, it is not the sink.
Arguments digest: A hash over the canonical tool arguments. Changing any load-bearing argument MUST change the digest and invalidate previously issued authority.
Instruction provenance: Evidence about whether the act is attributable to a user or developer instruction versus retrieved text, tool output, memory, or another agent.
Delegation depth: The number of agent-to-agent hops from the initiating principal to the actor proposing the Candidate Act.

Candidate Act, Non-Effective State, Protected Enforcement Domain (PED), Protected Validation Evidence, scoped non-bearer finality authority, and Finality Sink are used as in .

Architecture A Candidate Act MUST NOT become effective merely because the model selected a tool, the tool is in the allowlist, a token exists, or an upstream safety model returned ALLOW.

Dispatch-time finality invoke once, consume authority | `-- FAIL -> tool is not invoked ]]>

Dispatch Pseudocode The following procedures are normative in behavior, not in programming language. An implementation MAY collapse PED and sink into one protected service if both roles remain distinguishable: evidence is committed before authority is usable, and the invocation is checked immediately before effect.

Runtime: Model Output to Candidate Act

PED Validation policy.max_depth: return DENY(DELEGATION_EXCEEDED) if provenance_untrusted(act) and act.consequence_class in HIGH_RISK: return ESCALATE_OR_DENY(INSTRUCTION_PROVENANCE_FAILURE) if args_exceed_schema(act.tool, raw_args): return DENY(SCOPE_MISMATCH) evidence = COMMIT_PROTECTED_EVIDENCE(act) authority = ISSUE_SCOPED_AUTHORITY(act, evidence) # act remains non-effective return ALLOW(authority) ]]>

Sink: Verify Then Invoke The required property is that invoke() is unreachable when any check fails. Logging a denial and then calling the tool is non-conforming.

Load-Bearing Bindings Authority issued for maps.search / nearby / digest D1 MUST NOT authorize maps.search / nearby / digest D2, a different function on the same server, a shell action, or the same call at another sink. DISPLAY-equivalent mistakes in this profile are tool substitution and argument substitution. An authority for TOOL_DISPATCH MUST NOT automatically authorize SHELL_GATEWAY or BROWSER_CONTROLLER. An authority for delegation_depth 0 MUST NOT automatically authorize depth 2. An authority created under revocation epoch N MUST fail when the protected state is at epoch N+1.

Prompt Injection and Delegation The protocol does not require the model to detect injection. It requires that a consequential call influenced by retrieved text, tool output, memory, or another agent still cannot execute unless provenance and consequence-class predicates pass. Where provenance is UNKNOWN and the class is FINANCIAL, PERSISTENT_STATE_CHANGE, PHYSICAL, or NETWORK_CONTROL, the PED SHOULD escalate or deny rather than allow on the hot path. Discovery of an MCP server, marketplace entry, or advertised tool MUST NOT by itself create dispatch authority. Delegation to a sub-agent is itself a Candidate Act of type AGENT_DELEGATION. Implementations SHOULD track cumulative depth, tool-call velocity, and consequence class across the chain and withhold further authority when the envelope is exceeded.

Alternate-Path Closure If the same protected effect can be produced by MCP, a raw HTTP client, a browser controller, a shell, an IPC helper, or a memory/file write, each path MUST either enforce this profile or be unable to produce the effect. Moving the call from the tool dispatcher to curl MUST NOT remove the requirement.

JSON Interoperability Profile Objects are UTF-8 JSON. A transport MAY be local IPC, an OS broker, HTTPS, or an MCP middleware hook. Transport MUST preserve integrity, sink identity, freshness, and non-bearer semantics. Implementations MUST reject unknown load-bearing fields when additionalProperties is false.

AgentCandidateAct

Evidence, Authority, and Sink Verify

Complete Transaction

Hot Path, Escalation, and Failure Repeated calls inside a fixed envelope — same agent, tool, function, destination, consequence class, and provenance class — MAY use cached policy and short-lived authority. The sink check is still mandatory. New tools, unknown destinations, depth increases, FINANCIAL or PHYSICAL class, provenance UNKNOWN, or runtime anomaly SHOULD escalate. Timeout is not ALLOW. Illustrative codes, not IANA assignments: EF-002 NO_FINALITY_AUTHORITY, EF-005 AUTHORITY_ALREADY_USED, EF-006 REPLAY_DETECTED, EF-012 SCOPE_MISMATCH, EF-013 PURPOSE_MISMATCH, EF-020 DESTINATION_MISMATCH, EF-040 SINK_MISMATCH, EF-053 INSTRUCTION_PROVENANCE_FAILURE, EF-070 ESCALATION_REQUIRED, EF-080 FAIL_CLOSED.

Security Considerations Threats the sink is intended to make non-completable without current authority include: T1 direct prompt injection, T2 indirect prompt injection, T3 poisoned retrieval, T4 poisoned memory, T5 malicious tool response, T6 tool substitution, T7 MCP/server substitution, T8 unauthorized delegation, T9 recursive escalation, T10 stale user authority, T11 destination substitution, T14 authority replay, T15 cross-sink reuse, and T17 alternate-path effectuation. The model is not trusted to police these. The property is mechanical: invoke() does not run. Residual risk remains if an unclassified generated argument string is itself a program the tool will interpret, or if a path around the sink exists. Implementations MUST treat those as profile failures, not as acceptable best-effort modes.

Privacy Considerations Candidate Act descriptors can reveal user intent, tool choice, and destination. Implementations SHOULD hash or seal raw arguments and prompts on untrusted paths and SHOULD NOT log full tool arguments when the digest is sufficient for verification.

IANA Considerations This document requests no IANA actions.

Intellectual Property Note Certain concepts are associated with pending applications in the DAS Protocols family, including PCT/IB2026/054453, PCT/IB2026/055615, PCT/IB2026/055760, PCT/IB2026/055870, PCT/IB2026/056058, and PCT/IB2026/053385. IETF disclosure should follow BCP 79 .

Conclusion The model may select a tool. That selection is computation. External execution starts only after the Candidate Act is validated, evidence is committed, scoped authority is issued, and the dispatch sink verifies the live invocation. Tool selection is not execution authority.