An AI agent's indirect injection surface is defined by every place it reads content it did not directly ask a human for. Listing these paths explicitly is more useful than thinking about indirect injection abstractly, because each path has a different owner, a different fix, and a different level of attention most teams currently give it.
Retrieval pipelines
Retrieval-augmented generation pulls documents into an agent's context based on relevance to a query. If any of those documents can be authored or edited by someone outside a trusted review process, a public wiki, a shared drive with broad write access, a knowledge base fed by scraped content, an attacker can plant a sentence designed to be read as an instruction once it gets retrieved. The document does not need to be retrieved often to be dangerous; it only needs to surface once for the right query.
The fix here starts with restricting write access to sources that feed retrieval and applying the same review standard to that content as you would to code that runs in production, since in effect, retrieved content influences what the agent does.
Browsing and web-fetching tools
An agent with a tool that fetches and reads web pages has an injection surface that includes every page it might be asked to visit. This is particularly hard to fully control because the web is open by definition, and an attacker does not need any relationship with your organization to publish a page designed to be fetched and read by an agent performing research or fact-checking on a user's behalf.
Mitigating this path usually means restricting which domains or sources an agent's browsing tool can reach when that is feasible for the use case, and treating anything fetched from the open web as maximally untrusted content, with tighter limits on what actions can follow directly from information found there.
Email and messaging content
An assistant that summarizes or acts on incoming email or chat messages inherits an injection surface that includes anyone who can reach that inbox or channel, which for many organizations means effectively anyone on the internet. A message does not need to look suspicious to a human skimming it to contain a sentence that reads as an authoritative instruction to a model processing it in full.
This path deserves particular caution when the agent has any tool access beyond drafting a reply, since an injected instruction in an email could otherwise cause the agent to take an action based on content from an unauthenticated external sender.
Tool responses and API results
When an agent calls a tool and receives a response, that response is often fed back into the model's context to decide the next step. If the tool calls out to an external service, or if the tool's own data source could be manipulated, an attacker with the ability to influence that response can inject instructions the same way a malicious document would. This path is easy to overlook because tool responses feel like "your own system's data," even when the tool is pulling information from something outside your direct control.
Treating tool responses as untrusted input to the next reasoning step, rather than as implicitly trustworthy because they came from your own integration, closes a gap that is otherwise easy to miss during design.
Shared memory and multi-user context
If an agent's memory persists across sessions, or if multiple users' interactions feed into a shared knowledge store the agent later draws on, an injection successfully planted by one user or through one interaction can resurface for a different user entirely. This turns what might have been a contained, single-session injection attempt into a persistent one, and it is often the hardest path to notice, because the original injection event and its later effect can be separated by a significant amount of time.
Multi-agent hand-offs
In systems where one agent's output becomes another agent's input, an injection that succeeds against the first agent can propagate to the second, which may have different or greater tool access. Treating an upstream agent's output as untrusted, rather than as a trusted internal signal simply because it came from "your own pipeline," is necessary to stop this propagation.
A practical approach across all these paths
Rather than trying to build a perfect filter for each path individually, the more reliable pattern across all of them is the same: constrain what each path is allowed to influence. Retrieved and fetched content should inform the model's answer, not silently expand its authority to call new tools. Tool responses should be treated as data, checked against expectations where feasible, rather than as new instructions. Memory writes should be reviewable and revocable, so a planted instruction does not persist indefinitely once discovered.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary applies regardless of which of these paths originally influenced the model's decision to request a tool call, since the check happens at the point of the action, not at the point of the original content. This gives a consistent backstop across paths that would otherwise each need their own bespoke defense to have any enforcement at all.
The path-specific mitigations, restricting retrieval sources, scoping browsing domains, treating tool responses as untrusted, and controlling memory writes, still need to be designed and implemented for each specific integration.
A short checklist by path
- Restrict and review write access to sources feeding retrieval.
- Restrict browsing tools to necessary domains where feasible, and treat
fetched content as maximally untrusted.
- Treat email and messaging content as untrusted regardless of sender
familiarity.
- Treat tool responses as untrusted data, not implicitly trusted internal
signals.
- Make memory writes reviewable and revocable across sessions and users.
- Treat upstream agent output as untrusted input in multi-agent hand-offs.
Indirect prompt injection is not one problem with one fix. It is several distinct paths, each requiring its own specific control, and a defense that only addresses the most obvious path, usually retrieval, leaves the others open.