Tool Output Injection

What Is Tool Output Injection?

Tool output injection is indirect prompt injection carried by the data that a tool returns to a model. The carrier can be a browser or fetch tool, a connector, a retriever, an API wrapper, a plugin or integration, a database client, an internal service adapter or another agent invoked as a tool. The influencing material arrives on the response side of a tool call, after the application has already decided that the call itself was acceptable.

The component performing the call may be perfectly legitimate: authenticated, signed, internally operated and correctly implemented. That says something about the transport and the operator. It says nothing about the authority of the content the tool transports, because that content usually originates in an external or partly attacker-influenced system.

Model influence is also not automatically a security outcome. A tool result may shift a plan, a summary or a proposed next call, and the workflow can still end with nothing security relevant happening. Impact additionally requires reachable data or capabilities and an absent, overbroad or failing deterministic control.

Trusted Tool Versus Trusted Content

Many production tools act as multiplexers: a single trusted interface in front of many content authors. A CRM tool returns notes written by customers, a ticket tool returns text written by reporters, a browser tool returns pages written by anyone. The trust decision therefore belongs to the content and its provenance, not to the component.

Scope and Related Attack Classes

These classes combine in real incidents. A poisoned page reached through a browser tool is both website prompt injection and tool output injection; the same content indexed for retrieval becomes RAG prompt injection. This article treats the shared primitive: the moment tool-returned data enters model context and can steer the next step.

Tool description or registration poisoning, covered on this site as MCP tool metadata injection, acts on the catalogue before any call; tool output injection begins after invocation.

Tool selection manipulation is deliberately excluded. Research on that class, such as ToolHijacker, targets the tool library and the selection step before a call happens. Tool output injection begins after a call has been made and concerns the response.

The Tool Invocation Pipeline

Tool, parser and policy are system components under the operator's control. The data flowing through them is untrusted by default. A provenance and trust decision can change how a result is labeled, retained and evaluated, but it never converts externally or user-influenced content into an authoritative instruction: known provenance is not instruction authority, and a trusted processor is not a trusted payload. Deployments differ: some agents call a single read-only tool, others chain retrieval, transformation and mutation tools across many turns.

Tool Result Surfaces

Every one of these can be perfectly legitimate content. They matter here because they are the places where an external author's words can arrive in a system-shaped wrapper.

Data Versus Instruction Authority

Language in a tool result is evidence about an external system. A sentence that sounds like a directive is still data: it may describe what a customer wants, what a page claims or what a record contains. Treating it as workflow instruction is an application design decision, and in nearly all cases the wrong one.

Result components need separate handling, and structured output is not the same as trustworthy output. A JSON document that validates against a schema gives structural assurance about shape and types, but its free-text fields can still carry externally authored content; schema validity says nothing about semantic or instruction trust. Inside a single response, system-generated control metadata such as status, identifiers and types should enter context and policy decisions separately from payload text written by an external party. Structured fields, identifiers, status codes, headers and free-text values have different trust characteristics and should not be flattened into a single undifferentiated blob before entering context.

Request-Side Versus Response-Side Trust

Call authorization and result handling answer different questions. Call authorization asks whether this principal, in this task, may invoke this tool with these arguments against this destination. Result handling asks how the returned data may enter context, which parts are kept, what provenance they carry and what they are allowed to influence.

Conflating the two produces a common architectural error: because the call passed authorization, everything the call returned is treated as part of the sanctioned workflow.

Provenance, Transformation and Model-Visible Representation

Between an external system and the model there is usually a chain of transformations, and every step can lose source identity:

Provenance must survive all of it. A summary that no longer says which record, which URL or which field it came from cannot be reviewed, and a reviewer cannot distinguish an application statement from a stranger's sentence.

The model-visible representation is the object of study. It is frequently shorter, reordered and reformatted compared to the raw response, so telemetry that stores only the raw payload cannot explain what actually influenced the plan.

Multi-Step and Agentic Amplification

A single result rarely causes harm on its own. The risk grows when the result shapes the next step: another query, another tool, a different host, a file path, a recipient, an endpoint or a mutation. This is cross-tool influence: result A may legitimately inform which tool B is called, against which host, recipient or path, but it must never create tool permission, destination approval or data authority on its own. In multi-step agents, output becomes input, and each hop can carry the influence further while attribution fades.

No universal assumption is warranted about what an agent may do. Many deployments can only read. Others may write records, send messages, call external endpoints or execute code. Each of those is a separate capability behind a separate gate, and every cross-tool edge is a new authorization gate: that tool A was trusted or its call authorized transfers no authority to tool B or its parameters. Each gate should be evaluated against the current parameters rather than the original task approval.

Offensive Perspective for Authorized Assessment

For authorized testing, the useful question is not whether a model can be influenced. It usually can. The question is which realistic path leads from a source the tester may legitimately control to a security-relevant effect, and which gate stops it first.

Report the deepest gate genuinely observed. An influenced plan that never passed authorization is an influence finding, not unauthorized action, and stating it precisely is what makes the result actionable. This page describes barriers and measurement; it does not provide reusable injection strings, concealment techniques or exfiltration procedures.

The Tool Output Injection Success Chain

Competing Constraints

These constraints are also the design targets. Each deterministic constraint cuts the chain. Depending on where it holds, the outcome ranges from no model exposure at all to observable influence without a security-relevant effect.

Offensive Review Questions

Worked Scenario: Bounded Support Record Review

A support agent workflow is asked to summarize a synthetic customer record and suggest a next step. One customer-writable field in the test data contains instruction-like text that frames an unrelated objective, naming a different internal tool and an external recipient.

The scenario uses synthetic data, bounded permissions and reversible effects. Its value lies in showing which gate held: the agent was influenced, the proposal was observable, and the deterministic layer outside the model decided the outcome.

Capability and Authorization Boundaries

A proposal is a request, not a permission. Treat each of the following as a separate capability with its own decision: reading a record, running a follow-up search, fetching a URL, opening a file, sending a message, updating a record, creating a ticket, making an outbound network call and executing code.

1. 01
   Initiating principal

   Evaluate every action against the current permissions of the human or service that started the task, not against the agent's maximum reach.

2. 02
   Task-scoped capability

   Grant short-lived, narrowly scoped capability for the task at hand instead of standing ambient access.

3. 03
   Destination and data class

   Decide separately which resources may be read and which recipients, hosts or endpoints may receive data.

4. 04
   Exact-action binding

   Bind approval and authorization to an immutable or uniquely identifiable action, resource, target, parameters and state, never to a workflow as a whole.

5. 05
   Re-authorization on change

   When relevant parameters or the underlying state change between proposal and execution, authorize again; blanket approval for the workflow is not a substitute, and this closes time-of-check to time-of-use gaps.

6. 06
   Separation of effects

   Keep propose, read, write, send and execute as distinct rights that can be granted independently.

Information Flow and Egress

Tool results are doubly relevant to information flow: they may contain sensitive data, and they may simultaneously suggest new destinations for it. A workflow that reads confidential records and can call arbitrary outbound endpoints has combined both halves of an exfiltration path in one agent.

Detection, Telemetry and Their Limits

Prompt-injection classifiers, result scanners and heuristics are valuable signals and can support annotate-and-block controls, but they are probabilistic. They produce false positives and false negatives, and they must never serve as the sole authorization control or as proof that a result is safe. Telemetry likewise evidences sequence and correlation; it does not prove internal model causation.

Prevention and Secure Architecture

1. 01
   Untrusted by default

   Treat every tool result as untrusted unless a separate, explicit provenance and trust decision says otherwise.

2. 02
   Preserve provenance and boundaries

   Keep source identity, field boundaries and structure visible instead of merging everything into one text block.

3. 03
   Minimize returned content

   Select the fields the task needs, cap sizes and avoid dumping whole payloads into context.

4. 04
   Schema-aware parsing

   Validate structure and types, while stating clearly that schema validity is not semantic trust.

5. 05
   Separate channels

   Keep data channels distinct from instruction and configuration channels in the prompt architecture.

6. 06
   Deterministic authorization

   Decide actions, resources and destinations outside the model, in code and policy.

7. 07
   Least privilege and task-scoped tools

   Expose only the tools a task requires, with the narrowest scope and shortest lifetime.

8. 08
   Egress restriction

   Constrain outbound destinations and data classes independently of model output.

9. 09
   Exact-action approval

   Bind human approval to the reviewed action, parameters and destination, and re-check on change.

10. 10
    Isolation

    Run execution and file handling in sandboxes without ambient secrets or sensitive local state.

11. 11
    Sensitive-data minimization

    Redact or withhold sensitive values where the task does not require them.

12. 12
    Detection as signal

    Use scanning and anomaly detection to raise and route events, never as a substitute for authorization.

13. 13
    Derived-state invalidation

    Track lineage so summaries, memories, caches and indexes can be invalidated and rebuilt.

Persistence and Derived Artifacts

Tool results often do not end with the task. They flow into conversation summaries, agent memory, caches, vector indexes, generated tickets, notes and reports. Those derived artifacts can outlive the source record and reappear in later tasks, for other users, without the original attribution.

Incident Response

Controlled Security Testing and Metrics

Test with synthetic data, bounded permissions and reversible effects, in an environment that mirrors the real tool topology. Report each gate separately with an explicit denominator, and do not combine them into a single score, because a composite hides which control actually held.

The Tool Output Injection lab is a controlled simulation for practicing these boundaries: a trusted tool returning untrusted content, response-side result handling, and follow-on tool, destination and action authorization. It uses fictional data only and contains no payloads.

Whether a successful influence would have been visible to the user is a legitimate additional research dimension. Recent work on tool-using agents decomposes attack success into covert and overt outcomes, arguing that user-visible reporting changes the practical risk. Use that as a reported nuance with attribution, not as the primary metric.

Common Misconceptions

Standards and Research Context

OWASP LLM01:2026 covers indirect injection through external sources consumed by the application. NIST defines indirect prompt injection as prompt injection executed through resource control, and defines resource control separately as attacker control of external resources consumed at inference time. Both describe mechanism, not guaranteed impact.

Microsoft Zero Trust and retrieval-hygiene guidance recommends treating external and model-context data as untrusted and preserving provenance and permissions at each read and write. Microsoft Foundry documents tool response as an intervention point, currently in preview, where the full payload returned by a tool can be scanned for indirect attacks before it reaches agent memory or the end user; the tool call and tool response intervention points apply only to the tool paths documented as supported there, not as a universal Foundry property. The Microsoft Agent Framework safety guidance explicitly treats content in the tool role as untrusted, because data returned by tools and context providers can originate in external or user-influenced sources. These are product capabilities and recommendations, described as such rather than as universal properties.

Greshake et al. reports the practical viability of indirect prompt injection against real-world LLM-integrated applications. More recent work focuses specifically on the tool boundary: AttriGuard describes adversarial directives embedded in untrusted tool outputs and proposes a runtime defense based on causal attribution of tool invocations; a 2026 paper proposes defending indirect prompt injection via tool result parsing; and a 2026 study decomposes attack success into covert and overt outcomes from the user's perspective. ToolHijacker addresses a different step, manipulating tool selection through the tool library, and is cited here only to keep that class distinct. None of these results are reproduced here as attack procedures.

Frequently Asked Questions