Reviewed and updated October 8, 2026.
An assistant can encounter instructions inside a document, webpage, email or tool result that it was asked to read as data. Indirect prompt injection tries to turn that content into authority over the assistant's behavior. The potential harm depends on what data the system can disclose and what actions its tools can execute.
OWASP's prompt injection guidance describes this external-content attack and notes that retrieval or fine-tuning does not fully mitigate it. Its list identifier is not an empirical ranking of attacks against your application.
List untrusted inputs, protected data, permitted recipients and executable actions. Treat retrieved content as evidence to inspect, not an instruction source. Labeling or filtering it can help the model, but the backend must still enforce which data may reach which destination and which actions are allowed.
Keep credentials out of model context. Restrict tools to defined operations and validate their arguments and business authorization. For consequential writes, present the exact proposed action and target for approval; bind that approval to the checked proposal. A later model-generated change needs another decision.
Suppose a purchasing assistant reads a supplier PDF containing text instructing it to upload the company's supplier list to an external address. This is a threat-model example, not a tested attack result.
A safer proposed configuration gives the PDF reader no arbitrary upload capability. The assistant can produce a draft comparison using approved fields. If a separate sharing tool exists, it accepts only approved destination identifiers and checks the user's permission and the data's sharing policy. A URL from the PDF cannot become an approved recipient simply because the model repeats it.
Test the malicious instruction in plain text, document metadata and split passages. Check whether protected material reaches output, network destinations or logs. Also test a legitimate request to share an approved document, so a defense that blocks all work is not mistaken for a useful solution.
The CaMeL research paper separates trusted control flow from untrusted data and uses capability-based policies on tool calls. Its results concern the specified implementation and evaluation environment. A pair of models exchanging text does not automatically reproduce that policy enforcement, and logical separation is not a physical air gap.
Read-only operation reduces action exposure but can still leak information in answers, citations or rendered links. Sanitize output for the channel where it is displayed. Do not allow generated markup to load unapproved remote resources carrying sensitive values.
Prompt rules, content detection, output checks, tool restrictions, permissions and approval each address different paths. The OWASP prevention cheat sheet recommends layered defenses and adversarial testing. Passing a finite attack set does not prove universal prevention.
Record what was tested, which actions were blocked and what remains possible. Prefer a bounded workflow or draft-only assistant when action boundaries cannot be enforced reliably. Re-test after adding a source, tool, renderer or permission path.
Review ALLTIPLY's deployment and security considerations, then request a project review with the untrusted sources, protected data and actions the proposed application would expose.
Optional Google Analytics stays off until you choose Accept analytics.
