Indirect Prompt Injection Leading to Unauthorized Agent Tool Execution
- Scenario
- A malicious instruction inside an untrusted document enters the RAG context.
- Attack
- The agent reads retrieved content as trusted instruction.
- Potential Impact
- Unauthorized tool execution and data exposure.
Attack Path
- 01Untrusted DocumentAttacker-supplied
- 02RAG RetrievalReturned as context
- 03LLMReads text as instruction
- 04AgentPlans an action
- 05Tool / APIAgent's own privileges
- 06Sensitive ResourceReached unauthorised
Evidence
A document containing an embedded instruction block is ingested through the standard upload path and indexed into the vector store with no content-boundary marking.
On a subsequent unrelated user query, the retriever returns the poisoned chunk inside the assembled context window. Trace logs show the agent's planner treating the retrieved text as an instruction rather than as data.
The resulting tool call is issued with the agent's service identity, and it succeeds. In a full engagement this section carries request captures, trace excerpts and a reproducible proof-of-concept script.
Business Impact
An attacker who can place a document anywhere in the retrieval corpus — a shared drive, a support ticket attachment, a crawled web page, a forwarded email — can cause the agent to act on their behalf against systems the end user can reach.
Because the action is performed by the agent's own identity, it appears in audit logs as legitimate activity, which delays detection and complicates incident response.
For regulated organisations the exposure is not only the data reached but the inability to demonstrate that automated actions were authorised.
Technical Impact
Confidentiality: the agent can be directed to retrieve and disclose records the requesting user is not entitled to see.
Integrity: tools with write capability can be invoked to modify records or trigger downstream workflows.
Trust boundary: the failure is architectural — retrieved content and user instructions occupy the same trust level in the prompt, so no single filter fully resolves it.
Recommended Remediation
Separate data from instruction. Mark retrieved content with explicit, non-forgeable boundaries and instruct the model that retrieved text is never authoritative.
Constrain the agent's tools to least privilege, scoped to the requesting user's own permissions rather than a shared service identity.
Require explicit confirmation for any tool call that writes, transmits, or reaches outside the current session's data scope.
Sanitise and content-scan documents at ingestion, before embedding, rather than only at query time.
Log the provenance of every retrieved chunk that influences a tool call, so an action can be traced back to the document that caused it.
Add a regression test that replays the proof-of-concept payload on every release.
Retest Result
In a SilverXAI engagement every finding is retested after remediation and its status recorded as Resolved, Partially Resolved, or Open, with the evidence that supports that verdict.
The retest result is included in the final report and in the attestation summary you can share with customers and auditors.
Framework Mapping
Control and regulatory references are inferred: a finding is evidence that a control objective is not evidenced by the tested system, not a determination of compliance.
- CWE-1427 — Improper Neutralization of Input Used for LLM Prompting
- CWE-285 — Improper Authorization
- LLM01 — Prompt Injection
- LLM06 — Excessive Agency
- LLM08 — Vector and Embedding Weaknesses
- AML.T0051.001 — LLM Prompt Injection: Indirect
- AML.T0053unverified — LLM Plugin Compromise
- MEASURE 2.7 — AI system security and resilience are evaluated and documented
- MANAGE 2.4unverified — Mechanisms to supersede, disengage or deactivate AI systems
- ISO/IEC 42001:2023 — Annex Aunverified — AI system operation, monitoring and technical controls
- EU AI Act Art. 15 — Accuracy, robustness and cybersecurity
- MAS TRM Guidelinesunverified — Technology risk management for AI-enabled systems