- In short
- Indirect injection is a malicious instruction that arrives through retrieved content or a tool response the model treats as trustworthy, rather than through the user's own message. Because user-input screening only ever inspects the original user turn, it never sees instructions hidden inside a fetched document or a tool output, so those reach the model after screening has already passed. The fix is to run the same classifier used on user input against retrieved content and tool outputs before they enter the model's context.
A second injection vector the user never touches
Input screening catches instructions the user sends directly. The CCAR-P exam treats it as an analyse-level skill to recognise that this leaves a whole class of attack untouched, because a malicious instruction does not have to come from the user at all. In a system that retrieves documents or calls tools, an instruction can arrive embedded in content the system itself fetched - and by the time that content reaches the model, user-input screening has already passed the request.
This is not a niche edge case. In enterprise deployments that pair an LLM with retrieval or tool use, indirect injection is the dominant injection vector precisely because the defence everyone builds first - screening the user's message - has no visibility into it. The model treats a retrieved document or a tool response as trustworthy source material, and an instruction hidden inside that material can steer its behaviour just as a direct instruction would.
- Indirect injection via retrieved content and tool output
- An attack in which a malicious instruction is embedded in content the system retrieves (a RAG document) or receives from a tool, rather than in the user's message. Because user-input screening only inspects the original user turn, the instruction reaches the model after screening has passed. The defence is to apply the same classifier to retrieved content and tool outputs before they enter the model's context.
Why user-input screening cannot see it
User-input screening runs on the original user turn - the message the person typed. That is the only text it inspects. When a RAG system then retrieves a document to answer the request, or an agent calls a tool and receives a response, that content enters the pipeline after the screening step has already run and passed. The classifier never had a chance to look at it, because it was not there when the classifier ran.
The mechanism matters for the exam. In a RAG system, a malicious instruction sitting inside a retrieved document reaches the model after input screening has approved the request. In an agentic system, a tool response can carry instructions the model treats as authoritative. The blind spot is not a weakness in the classifier - it is a consequence of where the classifier sits. The source of the instruction is different, so the point of inspection has to be different too.
The fix: screen the content, not just the user
The defence follows directly from the diagnosis. Because the instruction arrives through retrieved content and tool outputs, you screen retrieved content and tool outputs - running the same model-based classifier you already apply to user input, but at a second point: before that content is appended to the model's context. Same classifier, different insertion point, chosen deliberately to cover the blind spot the first insertion point leaves open.
This is why the injection defence is not a single filter but a pattern applied wherever untrusted text can enter the context. The user's message is one entry point; a fetched document is another; a tool response is a third. Each is a place an instruction can arrive, and each needs the screening applied at that place. Treating "we screen the input" as complete coverage is the error the exam is built to catch.
What the CCAR-P exam trips candidates on
The first trap is concluding that a strong input-screening layer is sufficient protection for a RAG or tool-using agent. The scenario invests heavily in a well-tuned classifier on the user's message and asks whether the injection risk is handled. The credited reading is no - that classifier only ever sees the user turn, so a document the system fetches or a tool it calls can still carry an instruction straight past it.
The second trap is failing to notice that a malicious instruction can arrive through a document the system itself requested, not through anything the user typed. Candidates who think of injection as purely a user-message problem miss that the attacker never had to touch the user's input at all - they only had to plant an instruction in a source the system would later retrieve. The exam rewards recognising the retrieved-content and tool-output vector as a first-class attack surface with its own required control.
Worked example
A support agent answers questions by retrieving articles from a partner knowledge base and can call tools to look up account details. The team is proud of a strong prompt-injection classifier on the user's message. In production, a knowledge-base article contains hidden text instructing the model to reveal another customer's data, and the agent follows it. Why did the classifier not stop this, and what is the fix?
The classifier did not stop it because it never saw it. Input screening runs on the user's message, and the malicious instruction was not in the user's message - it was inside a knowledge-base article the system retrieved after screening had already passed the request. The attacker did not need to craft a clever user prompt; they only needed to get their instruction into a document the system would later fetch and hand to the model as trusted context.
This is indirect injection, and it is the dominant vector precisely in systems like this one that combine retrieval and tool use with a strong input filter. The strength of the input classifier is irrelevant to the attack, because the attack routes around it entirely by choosing a different entry point.
The fix is to apply the same classifier at the point the untrusted content actually enters the context: screen each retrieved article before it is appended to the model's context, and screen each tool response the same way before the model consumes it. The knowledge base should also be treated as an untrusted source subject to content controls, but the load-bearing change is running injection screening on retrieved content and tool outputs, not only on the user's turn.
Common misreadings to avoid
Misconception
A strong prompt-injection classifier on the user's message protects a RAG or tool-using agent against injection.
What's actually true
Misconception
If the harmful instruction never appeared in anything the user typed, it is not really prompt injection.
What's actually true
How this shows up on the exam
Domain 5 items describe a RAG or agentic system with input screening and a failure that traces to a retrieved document or tool response. The reliable method is to ask where the untrusted text entered the context: if it entered through anything other than the user's message, input screening did not see it, and the fix is to screen that entry point with the same classifier. Any answer that only strengthens the user-message filter is treating the symptom, not the vector.
This knowledge point sharpens the three-point guarded request path by revealing a screening need beyond the user turn, and it reuses the classifier chosen in model-based vs deterministic check selection. It is the concrete case behind the direct vs indirect injection distinction in the risk taxonomy, and it sets up skill supply-chain auditing, where the untrusted content is bundled code rather than a document and needs an even earlier control.
A RAG-based agent with a strong input-screening classifier follows a malicious instruction hidden inside a retrieved knowledge-base article. What best explains the failure and its fix?
People also ask
What is indirect prompt injection?
Why does input screening miss injection from a retrieved document?
How do you defend a RAG system against hidden instructions?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.