Analysis
Indirect Prompt Injection: How Agents Widen the Attack Surface | by Burak Tülüceoğlu | Sep, 2026 | Medium
Publication date not yet evaluated · Added · 10 reports medium.com
Page published · Page updated
Coverage timeline
Why it matters
Indirect prompt injection lets attackers hide instructions in any content an AI agent ingests, so defenders building or deploying agents must treat all retrieved data as untrusted and constrain the actions agents can take.
An explainer on indirect prompt injection argues that the technique is simply an LLM following the wrong instructions embedded in untrusted content (documents, emails, web pages, tool responses), and that autonomous AI agents dramatically widen the attack surface because they act on injected text by sending emails, changing documents, or leaking data. The piece walks through why models cannot reliably distinguish instructions from content and how agentic capabilities turn a benign-looking sentence into a real risk.
Summary
This is an analytical guidance article explaining indirect prompt injection: the phenomenon where a large language model follows instructions embedded in untrusted content rather than only obeying the legitimate user. The author frames prompt injection not as a sophisticated exploit but as ordinary natural-language text crossing an improperly designed trust boundary between instructions and data.[0]
The article centers on a July 2026 experiment in which nine AI services were asked to perform a mechanical name-counting task on a document that also contained two embedded instructions. Seven of the nine services followed at least part of the embedded instructions, and two followed both — including a request to modify persistent account-wide memory or settings — demonstrating how easily unsophisticated, plainly-visible injected text is executed.[0]
The author argues the danger escalates when models are wired to privileged tools and act autonomously (agents and browser agents), and offers system-design mitigations — least privilege, separation of reading from acting, confirmation for consequential actions, and independent validation of tool calls — rather than relying on prompt-only defenses.[0]
Complementary background reinforces the framing: prompt injection is described as manipulating an LLM into ignoring intended instructions because models process system prompts and user inputs as the same text sequences, akin to social engineering for AI, and is distinguished from jailbreaking, which targets a model's built-in safety guardrails rather than the surrounding application.[15]
How it works
Prompt injection occurs because applications feed trusted instructions (system prompt, user request) and untrusted data (uploaded documents, emails, web pages, tool responses) into the same model context, and the model must infer probabilistically which text is an instruction versus content. There is no reliable semantic separator — unlike SQL injection which can be prevented with parameterized queries — so wrapping content in XML tags, delimiters, or 'treat as data' labels only helps and does not guarantee the boundary.[0]
In indirect prompt injection the attacker never talks to the AI directly; they plant instructions inside content (a résumé, contract, support ticket, email, web page, source-code comment, pull request, calendar invite, or retrieved document) that a victim later asks an AI to process, so simply asking the model to 'summarize this file' can trigger the injected instruction.[0]
The experiment showed the failure also arises during translation: the model sees both the translation request and the quoted sentence as tokens describing desired behavior, so it may execute text it was only supposed to translate — in one case translating a proverb and then adopting the translated version as a response suffix. The real damage requires the combination of untrusted content, model interpretation, privileged tools, and insufficient oversight.[0]
At its core the technique exploits the fundamental design of prompt-based AI systems to override, modify, or bypass intended guardrails; because LLMs cannot reliably distinguish legitimate instructions from directions inserted within the input, injected text is interpreted as part of the model's own directives.[15]
Key takeaways
- Prompt injection is not a magic exploit; it is ordinary natural-language text crossing an improperly designed trust boundary, and the model behaves as designed by noticing and following instructions regardless of source.[0]
- Indirect prompt injection is trivially easy to trigger — plainly visible embedded instructions, with no Unicode tricks or jailbreaks, caused seven of nine tested services to obey — and the risk scales sharply once the model is an agent with privileged tools and autonomy.[0]
- Prompt-only defenses like 'treat documents as data' help but are not security boundaries because the defensive and malicious instructions are both interpreted by the same probabilistic system; containment must come from system design such as least privilege, action confirmation, and independent tool-call validation.[0]
- Once an AI system can act, treat every piece of text it reads as potentially executable in the sense that it may influence decisions, tool calls, memory, and external actions.[0]
- Prompt injection resembles social engineering applied to a cognitive system, and should be distinguished from jailbreaking: the former manipulates the application by exploiting instruction/content confusion, while the latter targets the model's built-in safety guardrails.[15]
Defensive actions
- Grant agents the minimum possible, narrow, temporary, task-specific tool permissions rather than connecting every integration.: An assistant that summarizes contracts does not need permission to send emails, delete files, or update payment details; limiting tools removes the privileged-tool component that makes injection consequential.[0]
- Separate reading from acting, validating summarization output before it reaches privileged tools and passing structured values rather than unrestricted natural language.: Introducing a controlled decision stage prevents untrusted content from directly influencing privileged actions.[0]
- Require explicit user confirmation for consequential actions, showing the actual action and parameters rather than a generic 'continue' prompt.: Sending data externally, deleting records, transferring money, or modifying account settings should not proceed on model confidence alone.[0]
- Treat persistent memory writes as privileged operations with their own validation and confirmation.: A document should not be able to change account-wide preferences merely by containing a sentence asking the model to remember something — exactly the persistence two services fell for in the experiment.[0]
- Use deterministic code for deterministic tasks and validate tool calls independently outside the model, checking destinations, file paths, recipients, permissions, amounts, and command arguments.: Every unnecessary model call adds a place where untrusted language can affect behavior; a confidently generated tool call is not inherently safe.[0]
- Isolate high-risk browsing sessions with separate accounts, containers, browser profiles, and credentials, and maintain an audit trail of processed content, triggering instructions, tools called, and human approvals.: Browser agents bridge otherwise-isolated origins, so an agent reading a public page and then using an authenticated session collapses the browser's trust boundary; isolation and logging reduce blast radius and enable investigation.[0]
- Test with hostile documents embedding malicious instructions in PDFs, emails, HTML, images, repositories, comments, metadata, and tool responses — not just obvious 'ignore previous instructions' phrases.: Real attacks use role-play, fake error messages, encoded content, long-context distraction, and instructions disguised as application data.[0]