Tool-call safety
Execution Finality for Agent Tool Calls
A model-generated tool call is a candidate action, not proof that the action is authorized to become effective. This Internet-Draft proposes a host-side gate that binds exact arguments and destination to scoped, single-use authority before dispatch.
Status first
Section titled “Status first”draft-das-agentic-tool-binding-03 is an active individual IETF Internet-Draft, not an RFC, IETF standard or IETF-endorsed specification. Revision -03 was published 5 September 2026 and expires 9 March 2027 unless updated or replaced. Its document header says Intended status: Informational; the IETF Datatracker currently lists no RFC stream and no intended RFC status for the submission.
The draft addresses a narrow execution boundary inside agent hosts: a model can emit a syntactically valid tool_use, function/tool-call, MCP tools/call or computer-use action, but generation of that request does not itself establish that the requested real-world effect is authorized.
Its proposed invariant is therefore structural rather than model-behavioral: hold the generated action non-effective until a local enforcement path has bound the exact action, validated authority, and consumed that authority at the dispatch boundary immediately before effectuation.
The execution-finality boundary
Section titled “The execution-finality boundary”A conventional host loop often collapses two different events:
- the model generates a tool request; and
- the host invokes the named tool with those arguments.
The draft inserts a gate between them. Its host-loop sequence is broadly:
- parse each generated tool block;
- canonicalize the live arguments and compute an argument digest;
- map the request into an AgentCandidateAct;
- keep the act non-effective;
- validate policy/authority;
- issue act-bound authority only after successful validation;
- at the Finality Sink, re-check the live digest, destination/sink and freshness state, then consume the authority;
- invoke only after those checks succeed.
That sequence is intended to prevent a common category error: treating schema-valid model output, previous trust in a conversation, or possession of a broad credential as permission for this exact consequential act.
What is bound
Section titled “What is bound”The draft’s security proposition depends on binding authority to the action that will actually execute, not merely to a tool name.
| Bound coordinate | Why it matters |
|---|---|
| Candidate-act identity | Keeps one generated act distinct from another or from a replay |
| Tool/function identity | Prevents authority for one operation being silently reused for another |
| Canonical argument digest | Makes post-approval argument substitution detectable |
| Destination / tool endpoint | Makes an otherwise identical call to a substituted backend distinguishable |
| Workload / agent context | Narrows who may present the authority |
| Policy/freshness state | Allows later policy change or expiry to invalidate stale authority |
| Finality Sink | Prevents an authority issued for one enforcement boundary being accepted at another |
For computer-use actions the same principle applies to live state. The draft treats consequential clicks/submissions as separate candidate acts and says authority should bind the state that will actually be submitted, rather than trusting the model’s textual description of that state.
Fail-closed is scoped to the proposal
Section titled “Fail-closed is scoped to the proposal”The draft defines consequence classes including FINANCIAL, PHYSICAL and NETWORK_CONTROL, and requires fail-closed behavior above its configured threshold. Under that proposal, missing or invalid current act-bound authority means the candidate act remains non-effective.
That is a requirement of this draft’s proposed binding, not a claim about how UHP, MCP, Anthropic, OpenAI, or other agent runtimes currently behave.
The draft also couples each allow/deny enforcement decision to a Ledger-Anchored Validation Receipt (LAVR). Within the proposal, that receipt is evidence that the finality boundary evaluated the specific candidate act; it should not be generalized into proof that a later external system completed the requested effect or that the decision was legally correct.
MCP: useful binding idea, but correct the session wording
Section titled “MCP: useful binding idea, but correct the session wording”The draft contains an explicit mapping for MCP tools/call and places the conforming hook at the MCP client dispatcher, so one client-side enforcer can see the MCP servers reachable by the agent. It binds the intended server endpoint as part of the destination and says a denied call must not be sent to a normal server.
There is an important version boundary, however. One section of the draft characterizes MCP authorization in terms of what a server accepts “under the session.” Released MCP 2026-07-28 removed protocol-level sessions and the Mcp-Session-Id header, removed the initialization handshake, and moved protocol version/capabilities to every request. Current MCP therefore has a stateless protocol core, with application state carried through explicit handles when needed.
The durable concept in this draft is not the older session wording. It is the proposed per-act dispatch gate around an exact tools/call request and destination. That gate can be evaluated independently of whether the surrounding MCP revision is sessionful or stateless.
This site does not treat the draft as correcting or extending MCP core.
Alternate paths are the hard production problem
Section titled “Alternate paths are the hard production problem”The draft is unusually explicit about bypasses. A protected Finality Sink does not establish execution-finality if the same effect remains reachable through another route such as raw credentials, direct HTTP, a second SDK, an unwrapped plugin, subprocess execution, another MCP client or browser automation.
Production assurance would therefore require the consequential paths to converge on, or remain subordinate to, the same effectuation boundary. A middleware wrapper that guards only one convenient path is evidence for that guarded path, not proof that the host cannot bypass it elsewhere.
The draft also acknowledges a local atomicity limit: consuming a local single-use authority and causing a remote effect are not automatically one atomic transaction. Idempotency keys, destination-side verification, transactional outbox patterns, protected acknowledgements, effect receipts or application-specific recovery may still be necessary.
Reference implementation evidence
Section titled “Reference implementation evidence”The author publishes a v0.1.0 runnable reference implementation covering representative Anthropic-style tool_use, OpenAI-style function/tool calls, MCP tools/call and computer-use actions.
The draft documents a supplied 10-test suite covering cases such as argument mutation, authority replay, MCP endpoint substitution, wrong-sink presentation, parallel candidate acts, injected-content provenance, deterministic JSON digesting, computer-use origin substitution and policy-epoch invalidation. Its recorded archive verification result is 10 passed.
Those are author-supplied synthetic reference tests, not independent production validation. The draft explicitly says the implementation is not a production security product, does not prove universal bypass closure, uses synthetic data, and does not provide production PKI/HSM/TEE guarantees, formal verification, penetration-test certification or Internet-scale performance.
The linked GitHub repository is public and source-available; its repository metadata does not expose an OSI-standard license identifier (NOASSERTION). Do not infer a broader open-source licensing status from public availability alone.
Relation to UHP
Section titled “Relation to UHP”UHP standardizes the external client↔server contract for executing a selected complete harness. A UHP-served harness may internally call tools, MCP servers, browser/computer-use surfaces or other effectful integrations, but those internal dispatch paths are not made execution-finality-safe merely because the outer UHP request is valid.
| Question | UHP | Tool-binding draft |
|---|---|---|
| How does a client invoke a complete harness? | Standardized by UHP | Out of scope |
| Is model-generated tool output itself authority? | No general UHP guarantee | Explicitly no |
| Where is the proposed enforcement point? | Implementation-specific internal runtime concern | Immediately before consequential dispatch / effectuation |
| Does it bind exact live arguments? | Not a general UHP primitive | Yes, through a canonical argument digest |
| Does it define MCP semantics? | No | No; it proposes a host/client-side binding around tools/call |
| Does it prove an external effect completed? | No general inference | No; local gating and effect completion remain distinct |
For UHP implementers, the relevance is architectural: protocol authorization to run a harness and authorization for a particular downstream effect are different decisions. A server can conform to UHP while still needing its own per-tool policy, credential, sandbox and effect-boundary controls.
Relation to control-delivery evidence
Section titled “Relation to control-delivery evidence”Agent Control Delivery Evidence asks what evidence justifies saying that a stop, revoke, cancel or other control was emitted, received, enforced and observed across all required targets.
This execution-finality draft asks a different question: what must happen before a generated consequential act is allowed to cross the dispatch boundary at all?
They can complement each other:
- execution-finality concerns pre-effect gating of a candidate act;
- control-delivery evidence concerns delivery/enforcement/effect reconciliation for controls across runtime boundaries.
Neither document is a UHP extension, and neither substitutes for UHP conformance.
Evidence boundaries
Section titled “Evidence boundaries”- Work in progress. Revision
-03can change, expire or be replaced. - Individual submission. The Datatracker explicitly says the document is not IETF-endorsed and has no formal standing in the standards process.
- Dependency on another draft. The binding maps generated calls into the separate Agent Candidate Act profile; maturity of this draft does not upgrade that dependency.
- Current MCP differs from one draft characterization. MCP
2026-07-28is stateless at the protocol core; session-oriented wording in the binding draft should not be copied into current MCP descriptions. - Reference code is bounded evidence. Synthetic tests demonstrate the supplied guarded path, not production deployment security or closure of every alternate effect path.
- No UHP adoption claim. No reviewed primary source establishes a standardized UHP mapping or HarnessRouter implementation of this proposal.
Related pages
Section titled “Related pages”Read UHP security for the protocol’s documented trust boundaries, UHP vs MCP for current MCP architecture, Agent Control Delivery Evidence for control-outcome reconciliation, and HarnessRisk for lifecycle-oriented adversarial harness evaluation.