Indirect prompt injection can change an AI agent’s plan, answer, tool arguments, or stored context after it reads attacker-controlled material. The damage depends on what the agent can access and what its execution controls allow; reading a malicious page does not automatically give an attacker every account permission.
I would assess the effects through three questions: what changed in the task, which capability was used, and whether the effect persisted. That produces a more useful risk picture than treating every suspicious sentence as an equally serious compromise.
Start with the agent’s actual authority
An AI agent combines model-generated decisions with a workflow that can read information or perform operations. Its exposure comes from those concrete connections. A support assistant limited to one public knowledge base has a different risk profile from an agent that can browse, search private files, and send messages in the same session.
List the available resources, tools, and destinations before assessing an indirect attack. Include the permissions of the service account behind each tool. A narrow-looking interface can hide broad access if the execution service does not enforce resource limits itself.
My first recommendation is to distinguish what the model can propose from what the system can execute. The model may generate an unacceptable plan, but a properly enforced boundary can prevent that plan from changing anything. Conversely, a polite final answer does not undo a tool action that already exposed information.
The plan can drift while the answer still sounds relevant
A source can redirect the agent’s intermediate objectives without making the final answer obviously strange. During research, an injected passage might encourage it to prioritize one source, skip a verification step, or treat a claimed prerequisite as mandatory. The agent can remain on the general topic while pursuing the attacker’s preferred route.
This matters for systems that repeatedly plan, act, observe, and replan. A small change in the next action can determine which material arrives later and which checks are performed. The effect is a workflow deviation rather than a visible refusal or a bizarre response.
I would compare the sequence of actions with the original task scope. Look for new objectives introduced by outside material and ask who authorized them. A document can explain a procedure, but it cannot grant permission to expand a task into unrelated account changes or privileged operations.
| Effect | Observable evidence | Important distinction |
|---|---|---|
| Plan change | New out-of-scope objective | Proposal versus execution |
| Data exposure | Content and destination records | Read access versus disclosure |
| State change | File or record history | Draft versus published result |
| Persistent influence | Stored memory or index entry | Current chat versus later tasks |
Tool arguments can carry the damaging change
A tool name may be appropriate while its parameters are not. An agent asked to draft a response could select the correct messaging tool but attach the wrong file or use a recipient suggested by an untrusted document. Checking only which tools were called misses that distinction.
Review the target resource, destination, payload, and operation type together. An approval for one action should not silently authorize a different operation with changed details. The service that actually executes the call needs to verify the user’s scope rather than accepting a model-generated claim that approval already exists.
I would make action previews concrete enough to catch these changes. For a file edit, show the path and modification. For a send, show the destination and included content. A broad confirmation such as “continue with the task” gives a reviewer too little information to identify an injected change.
Confidentiality and integrity can fail independently
Confidentiality concerns who receives information; integrity concerns whether information or state is changed correctly. An agent can violate one without the other. A manipulated summary may damage integrity without sending secrets, while an unnecessary disclosure may expose data without editing the original document.
The same separation helps with severity assessment. Identify the information involved, who could access the result, and whether any shared system state changed. A private incorrect draft and a published incorrect notice should not receive the same incident description merely because both began with an injected instruction.
I would avoid a single generic “data breach” label until the observed effects justify it. Record what the trace actually establishes. When the destination or contents of a suspected transfer are uncertain, preserve that uncertainty and investigate the execution records rather than inferring a completed leak from the model’s proposed action alone.
OWASP’s agent security guidance separates tool permissions, memory controls, approvals, and monitoring because agent failures can cross more than one boundary.
A compromised memory can outlive the current task
Some agents store preferences, summaries, or reusable task notes. If untrusted source instructions enter those stores as authoritative guidance, later tasks may inherit the influence. An attacker-controlled source can then affect work beyond the conversation in which it was first read.
Memory is not automatically unsafe, and persistence does not happen in every agent. Inspect the application’s actual storage behavior. Separate user-approved preferences from retrieved facts, generated summaries, and tool observations. Each record should have an origin and a reason it is allowed to influence future behavior.
I would give persistent memory a review and deletion path. After an incident, inspect the relevant entries and derived summaries before reconnecting the workflow. Starting a fresh conversation may remove transient context, but it does not repair a poisoned index, a shared task record, or a permission configuration that remains overly broad.
One agent can pass the influence to another
A multi-agent workflow can spread a malicious directive through ordinary handoffs. A research component may summarize outside content; a planning component may treat the summary as a recommendation; an execution component may receive the resulting action request. Each step can make the original source less visible.
Do not assume that text is trusted because another internal agent produced it. The handoff should preserve the source’s role and separate reported evidence from permissions. An internal message describing a document is not the same as a user-authorized operation.
My approach would keep execution decisions narrow even when the research chain is complicated. The final tool service should check the acting user, resource scope, and exact operation independently. Adding more reasoning agents can help organize a task, but it does not create an authorization boundary merely by increasing the number of model calls.
Availability and cost are part of the impact
An injected workflow can consume resources without stealing data. Repeated searches, recursive subtasks, oversized responses, or unnecessary tool calls can increase completion time and usage costs when the surrounding system allows them. The exact expense depends on the application’s pricing and limits; no universal multiplier is meaningful.
Watch for a legitimate task that repeatedly fails to finish or expands into unrelated work. Separate those symptoms from ordinary slow retrieval or provider errors. A suspicious loop is evidence to investigate, not proof that every expensive request is malicious.
I would set enforced step, time, and usage budgets for a task. When a limit is reached, pause with a clear reason rather than automatically granting more scope. A per-tenant budget also helps prevent one affected workflow from consuming the resources needed by unrelated users who have done nothing wrong.
Measure the effect with harmless, outcome-based tests
Build tests around the effects you need to prevent: wrong recipient, out-of-scope file access, altered shared state, or unauthorized memory persistence. Use fake records and controlled destinations. The expected outcome should name the operation that must remain blocked even if the model requests it.
Include the full sequence, not just the first model reply. An agent may refuse a direct request but later accept a similar instruction in a tool result. A successful single-turn refusal therefore says little about the entire workflow after several observations and handoffs.
I would also test legitimate completion under the same restrictions. A security control that stops every tool call can appear perfect while destroying the feature. The useful goal is an agent that completes permitted work and cannot turn an outside source into additional authority, with evidence for both sides of that claim.
The personal prevention guide offers a narrower personal workflow for reducing the capabilities an injected instruction could misuse.
Contain the affected capability before restarting
When you suspect an indirect attack, pause ongoing actions and identify the earliest untrusted input associated with the deviation. Inspect what completed, what was merely proposed, and which stored state may be affected. Disable the particular risky capability when a narrower containment step is sufficient.
If credentials were exposed, revoke or rotate them through the issuing service. If files or records changed, use the appropriate history and recovery mechanisms. Preserve relevant evidence with restricted access; copying all private context into a general incident channel can create another disclosure.
For a practical next step, I would choose the agent’s highest-consequence capability and verify that its execution service enforces scope without trusting the model’s explanation. That is where an apparently small instruction hidden in a routine source can become a real external effect, and where a strong boundary can stop it.
Common questions
Can a read-only agent cause harm?
Yes. It can produce misleading answers or disclose information it can read. Read-only access reduces write risk but does not remove every confidentiality risk.
Does every injected plan succeed?
No. The model may reject it, or the application may block the proposed action. Record the actual execution outcome.
Are multiple agents a defense by themselves?
No. Handoffs need preserved provenance and independent authorization. Another model’s summary can still carry untrusted influence.