How Indirect Prompt Injection Reaches a Tool Call
Indirect prompt injection differs from direct prompt injection in that the malicious instruction does not come from the user's prompt. It arrives embedded in content the agent retrieves and processes on the user's behalf: a webpage, a PDF, an email, or the output from another tool.
Security researcher Simon Willison first drew this distinction, noting that an agent ingesting third-party content has no reliable way to distinguish data from instructions once that content enters its context window. Academic research demonstrated this concretely by showing that LLM-integrated applications retrieving external web content could be compromised through instructions hidden in that content, with no direct involvement from the user at all.
The practical consequence for security engineers is that any agent with tool access and any capability to read untrusted content carries an attack surface that extends beyond the immediate conversation.
| Stage | What Happens |
|---|---|
| Untrusted Content Ingestion | The agent processes a document, web page, or tool output containing hidden instructions. |
| Instruction Interpretation | The model treats embedded text as an instruction rather than data to summarize or analyze. |
| Unauthorized Tool Call Attempt | The agent issues a tool call the user never requested, using its existing permissions. |
Why Content Filtering Alone Falls Short
OWASP's Top 10 for LLM Applications classifies prompt injection as a critical risk category precisely because it can manipulate a model into performing unintended actions, including unauthorized function or tool invocation. NIST's adversarial machine learning taxonomy treats prompt injection as an integrity attack: one that alters model output and downstream behavior rather than simply producing objectionable text.
This framing matters because content filters are built to catch known patterns of malicious or unsafe language. Injected instructions can be phrased in countless ways, split across sources, encoded, or disguised as ordinary formatting. A filter tuned to detect one variant will miss others.
NIST's AI Risk Management Framework explicitly positions prompt injection within broader system security and integrity risk management, not as a content-moderation task alone.
The core limitation of input filtering
Filtering reduces some attacks but does not address the underlying problem: the agent still holds the ability to execute a tool call that was never authorized by the user or the system.
| Dimension | Tool-Call Governance | Content Filtering |
|---|---|---|
| What is evaluated | The action, target resource, scope, and privilege level of the call | The text of the incoming prompt or retrieved content |
| Obfuscation resistance | High: policy applies regardless of how the instruction was worded | Low: novel phrasing, encoding, or fragmentation bypasses known patterns |
| Enforcement point | At execution, before any external action occurs | At ingestion, before the model processes content |
| Provenance awareness | Can distinguish user-sourced from content-sourced instructions | Cannot attribute origin once content enters the context window |
| Attack surface addressed | Unauthorized actions, privilege abuse, data exfiltration via tools | Known malicious language patterns in direct input |
Tool-Call Governance as a Distinct Control Layer
Tool-call governance introduces a policy enforcement point between what the model outputs and what actually executes. Instead of trying to interpret whether a piece of natural language was manipulative, this layer evaluates the tool call itself: the target resource, the action type, the requested scope, and whether that combination is permitted for the given agent and context.
This shifts the defense from an unreliable text-classification problem to a bounded, rule-based authorization decision.
Effective governance also requires provenance tracking, so that policy logic can distinguish a tool call originating from a trusted system or user instruction from one triggered by content the agent retrieved from an untrusted source. A tool call to modify a record or send data externally, if traced back to instructions embedded in a scraped document rather than the user's own request, can be flagged or blocked before it executes, regardless of how the injected text was worded.
Key insight
The question to answer at enforcement time is not "does this text look malicious?" but rather "is this specific action, on this specific resource, authorized for this agent in this context?"
Implementation Considerations for Security Teams
Establishing tool-call governance requires deliberate architectural choices. The following practices are worth establishing early, before agents reach production workloads that handle sensitive data or have write access to external systems.
-
Define a tool permission manifest per agent
Each agent deployment should have an explicit list of permitted tools, target resources, and action types. Actions not on the manifest are denied by default, regardless of what the model requests.
-
Track instruction provenance through the pipeline
Tag whether a tool call originated from a user instruction, a system prompt, or content retrieved from an external source. Policy rules can then apply stricter constraints to content-sourced calls, such as requiring explicit user confirmation before any write or send action.
-
Apply least-privilege scoping at the tool level
Avoid granting broad filesystem, email, or API access when the agent's task requires only a narrow subset. Scoping permissions to the minimum necessary limits the blast radius if an injection attack succeeds in triggering a tool call.
-
Log every tool call with full context
Audit logs should capture the tool name, arguments, the reasoning trace that led to the call, the provenance tag, and whether the call was permitted or blocked. This creates the forensic trail needed for incident review and policy refinement.
-
Treat policy violations as security events, not errors
A blocked tool call from a content-sourced instruction is likely an injection attempt. Route these events to security monitoring rather than application error logs so that patterns can be detected and investigated.
Frequently Asked Questions
Does tool-call governance replace content filtering?
No. The two controls are complementary. Content filtering can reduce noise and block the most obvious injection attempts early in the pipeline. Tool-call governance provides a second, independent enforcement layer that catches attacks that evade filtering. Defense-in-depth requires both.
How does provenance tracking work in practice?
Each segment of the agent's context, whether from a user message, a system prompt, or a retrieval result, is tagged with its source at the time it enters the pipeline. When the model produces a tool call, the governance layer can trace which context segments contributed to that decision and apply policy rules based on the trust level of those sources.
Can an agent still be useful if content-sourced tool calls require confirmation?
Yes. Read-only tool calls, such as searching or summarizing, can generally proceed without additional confirmation. The confirmation requirement targets write, send, and delete actions triggered by content from untrusted sources, which are the high-risk subset worth the added friction.
What does this look like for agents with many tools?
The permission manifest approach scales by grouping tools into categories with shared policies. For example, all external data-send operations might require user confirmation when triggered by retrieved content, while internal read operations from verified databases proceed without friction. The manifest is maintained as configuration rather than requiring per-tool code changes.
How should teams prioritize this work relative to other AI security controls?
Tool-call governance is most urgent for agents that combine tool access with the ability to read untrusted external content. If an agent can both read arbitrary web content and send emails or modify records, that combination should be governed before other lower-risk configurations. Agents that are read-only or that process only trusted internal data carry lower injection risk and can be addressed in a second phase.