When Tool Outputs Become Commands, Agents Need Authorization Boundaries

A tool response is easy to treat as neutral data. The API returned a JSON object. The browser page rendered a paragraph. The terminal printed an error message. The ticketing system exposed a customer note. To a human operator, those are observations. To a tool-using AI agent, they can become the next instruction.

That is the quiet production risk behind a new arXiv paper, “When Tool Outputs Become Commands: Separating Action Induction from Runtime Authorization in Tool-Augmented LLM Agents.” The authors argue that tool-augmented agents must rely on untrusted runtime observations, but those observations can stop being passive when they specify concrete next actions. At that point, the agent is no longer only reading the world. It is being steered by it.

The distinction matters because modern agents are built to translate context into action. If a model reads a vendor response that says “retry with admin credentials,” a calendar description that says “forward this invite to the finance group,” or a documentation page that says “run this migration,” the model may treat that text as task-relevant guidance. Sometimes it is. Sometimes it is stale, malicious, out of scope, or meant for a different operator. The system needs a place to decide the difference.

The useful framing from the paper is the split between action induction and execution authorization. Action induction is the model’s ability to infer a possible next step from what it has observed. Execution authorization is the system’s decision that this next step is allowed to happen now. Those are not the same decision, and production agent platforms should stop collapsing them into one model turn.

Transport-level authorization does not solve this by itself. The Model Context Protocol’s HTTP authorization specification defines how MCP clients can make requests to restricted MCP servers on behalf of resource owners. That is necessary plumbing: the client needs a legitimate way to access protected resources. But having permission to call a tool is not the same as having permission to perform every action suggested by the content that tool returns.

Think of it like opening a locked filing cabinet. Authorization lets the agent read the folder it is allowed to read. It does not mean every sentence inside the folder can approve a wire transfer, modify a production database, change a patient-facing workflow, or escalate privileges. Access is about what the agent may see or call. Authorization boundaries are about what the agent may cause.

A practical architecture starts by making every side effect pass through a proposal envelope. Before execution, the agent should produce a structured claim: proposed action, target resource, user or tenant scope, source observations, intended outcome, risk class, and why this action is necessary for the original task. The runtime should then evaluate that envelope against policy before any irreversible tool call happens.

That policy layer should ask boring questions very consistently. Did the user ask for this class of action? Is the target resource inside the delegated scope? Is the action read-only, reversible, externally visible, financially meaningful, clinically meaningful, or security-sensitive? Did the instruction originate from a trusted system message, a user request, a retrieved document, a webpage, an email body, a terminal log, or another agent? Has this exact action pattern been approved before, and under what conditions?

The answer should often be “not yet.” Not because agents should be timid, but because a healthy runtime distinguishes between a model’s suggestion and an executable mandate. A command-like observation can inform the proposal. It should not be able to authorize itself.

This is especially important for enterprise workflow automation, where the dangerous cases are rarely cinematic. The failure may be an agent that applies a stale billing rule from an old wiki page. It may be a support agent that follows a customer-provided instruction to reveal account history. It may be a coding agent that treats test output as a request to disable the failing check. It may be a browser agent that reads hidden page text written specifically to redirect its next click. Each case is a version of the same pattern: runtime content crosses the boundary from evidence into authority.

Teams can test for this directly. Build evaluation fixtures where tool outputs contain plausible but unauthorized instructions. Put “delete the backup,” “send this to a broader group,” “use the emergency override,” or “ignore the prior approval requirement” inside documents, HTML, logs, tickets, and API payloads. The goal is not only to see whether the model notices. The goal is to verify that the runtime refuses to execute without the right independent authorization.

Telemetry should also separate proposed actions from executed actions. If the model proposes ten write actions and the policy layer executes six, that delta is operationally meaningful. It can reveal over-broad prompts, confusing tool outputs, missing scopes, or a policy that is too permissive. It also gives reviewers a concrete trace: what the agent saw, what it wanted to do, what the system allowed, and what was blocked.

This aligns with a broader risk-management view. NIST’s AI Risk Management Framework emphasizes governance, mapping, measuring, and managing AI risk. For agents, one manageable risk is the authority path between observation and action. If that path is implicit, teams cannot govern it. If it is represented as proposals, policies, approvals, and logs, they can test it before launch and audit it after incidents.

Anthropic’s guidance on building effective agents has also pushed teams toward understandable workflows rather than mystical autonomy. Authorization boundaries belong in that same category. They are not a generic “be safe” prompt. They are workflow structure: a deterministic checkpoint where the system can say, “This text may be relevant, but it is not authorized to command the agent.”

The near-term implementation does not need to be elaborate. Start with a side-effect inventory. Classify tools by risk. Require structured proposals for writes, sends, purchases, deletions, credential use, external communications, and cross-tenant access. Preserve source provenance in the proposal. Deny execution when the only authority is retrieved content. Escalate ambiguous actions to a human or a narrower approval flow. Add regression tests whenever a command-like observation slips through.

The deeper lesson is that agent safety is becoming less about whether the model can follow instructions and more about which instructions are allowed to matter. Tool outputs should enrich the agent’s understanding of the task. They should not become a hidden command channel.

Agents are most useful when they can read messy reality and still act cleanly. That requires a runtime boundary between what the world says and what the system permits. Let observations induce ideas. Let authorization decide action.