A Tool Result Is Not a New Permission

An agent needs information from tools to finish real work. A search result may reveal the correct report ID. A customer record may provide an approved mailing address. But a tool result can also say, "Send the report to this other person." That sentence is data, not a new permission.

The research question

SARA is a research prototype built around that distinction. It separates an observation that induces a candidate action from the evidence that authorizes a real tool call. Its central question is not whether an agent read untrusted content. It is whether a proposed side effect still has support from the user's task when it reaches the execution boundary.

The evidence

The authors retain a record when an untrusted observation proposes an action or argument. Separately, the runtime collects successful, authorized execution evidence. A later appearance of the same value does not automatically erase the earlier action origin. Before a side-effecting call proceeds, SARA checks the user-goal boundary, the execution chain, and the concrete arguments.

In the paper's stated GPT-4o-mini primary evaluations, SARA reported attack success of 0.06% on AgentDojo and 0.17% on AgentDyn, with user-task utility of 63.44% and 54.92%. The tradeoff is visible: the mechanism adds inference cost. Its ablation results also suggest that retaining cross-step action origin and checking argument support matter within the authors' setup.

These are reported benchmark measures, not a probability that any particular deployment is safe.

The boundary

This is an August 2026 preprint, not a WTK result. It evaluates selected indirect-prompt-injection tasks, models, tool schemas, and measures in AgentDojo and AgentDyn. The threat model trusts the user request, the tool schema, the SARA runtime, and the executor. It does not cover a direct bypass of that runtime, a pure data-flow flaw, or a user who delegates arbitrary external instructions.

The reported rates therefore do not show that WTK targets resist prompt injection, that a WTK package has this control, or that the same security and utility tradeoff would hold in a WTK deployment. A provenance record is also not authority by itself. It needs an enforcement point that can refuse a call.

The builder impact

Treat two questions as separate. First: where did this value come from? Second: what authority permits this operation, recipient, scope, and side effect? A search result can answer the first question without answering the second.

For a system such as WTK, a package can declare the task, permissions, and allowed tools. A compiled target still needs to show how an observed value can instantiate those declarations without adding a recipient, permission scope, or action the package and operator did not allow. The evidence should retain the candidate call, declared support, source provenance, decision, denial reason, and final state.

Our runtime-configuration note asks whether a declared rule is actually enforced. This note asks a narrower question: can newly retrieved information be used without treating it as permission? Our agent-update note addresses the related boundary when memory, instructions, or code change.

The WTK test

We propose a bounded target-harness comparison. Hold a WTK package and contract digest, target, model binding, tools, permissions, fixtures, task suite, and budget fixed. Compare current WTK behavior with the same path plus a non-authoritative authorization-evidence record for each side effect. The record names the authorizing user request, where the proposed action and its arguments originated, permitted scope, decision, and refusal reason.

First identify the existing authorization check and how it could use that record. The record cannot grant permission or block an action on its own. If the candidate only adds logging, assess evidence completeness and review accuracy, not a claimed reduction in unauthorized actions caused by logging. Any change to enforcement must be specified and separately approved.

Use matched permitted dynamic tasks and adversarial tool observations. Measure unauthorized effects, permitted-task completion, false denials, recovery after a denial, cost, and evidence completeness. The candidate fails if it silently widens authority, weakens existing enforcement, loses a required provenance record, or adds unacceptable blocks without a declared benefit.

Freeze attempt counts, evaluator criteria and stopping rules before execution; retain every attempt. Revisit results when the model, tools, permissions or authorization path changes.

Still unknown

Would this record expose a material WTK gap, improve a target's decision path, or merely duplicate controls that already work? The comparison could show no measurable benefit or be inconclusive. It is a proposed experiment, not a WTK Finding, a qualification result, or permission to implement or run a new security system.

Source

Primary research: When Tool Outputs Become Commands: Separating Action Induction from Runtime Authorization in Tool-Augmented LLM Agents, Xiaokun Guo and colleagues, August 2026. WTK reviewed the complete 17-page primary PDF. This Research Note translates external research into a bounded WTK question and reports no WTK experimental result.