- In short
- Direct injection is injected instruction that arrives directly from the user, so it targets input screening; indirect injection is instruction smuggled in through content the system itself retrieves or receives from a tool, so it bypasses input screening entirely because it never appears in the original user message. Both require the same class of classifier, but it must be applied at different points in the pipeline, and a retrieved document is not automatically trustworthy just because the system fetched it.
Two attack surfaces that share a name
Within the risk taxonomy, "prompt injection" is the item most likely to be misread as a single thing. The CCAR-P exam treats telling the two apart as an understand-level skill, because direct and indirect injection differ not in what the classifier looks for but in where the attack enters - and that difference is what decides whether your defence sees it at all. Getting the distinction right is the difference between a design that covers both surfaces and one that covers only the obvious one.
The shared name hides the crucial fact: these are two entry points, not two flavours of the same entry point. One arrives in the user's message; the other arrives in content the system fetched. A control placed for the first is blind to the second, no matter how good it is, because it is watching the wrong doorway.
- Direct vs indirect injection distinction
- Direct injection is an instruction that arrives in the user's own message, so it targets input screening directly. Indirect injection is an instruction smuggled in through content the system retrieves or a tool returns, so it bypasses input screening entirely by never appearing in the original user turn. Both need the same class of classifier applied at different points.
Direct injection: the attacker owns the user turn
In a direct injection, the attacker controls the user message and crafts it to override the system's instructions. Because the malicious content is in the user turn, it lands squarely in front of input screening - the classifier sees it, and a well-tuned classifier has a real chance of catching it. This is the injection everyone pictures first, and it is the one input screening was built for.
The important consequence is scope: input screening is a genuine, appropriate defence for direct injection. The mistake is not in trusting input screening here - it is in assuming that because input screening handles this surface, it handles injection in general.
Indirect injection: the attack routes around the classifier
Indirect injection never appears in the user's original message. The attacker plants an instruction in a source the system will later fetch - a document in the retrieval corpus, a response from a tool - and the model treats that fetched content as trustworthy. Because the instruction arrives after the input-screening step has already run and passed the request, the classifier never inspects it. The attack does not defeat the classifier; it bypasses it by choosing a different entry point.
This is why a retrieved document or a tool response is not automatically trustworthy just because the system fetched it. The act of retrieval is not a safety check. Content that the system pulled in can carry an instruction as hostile as anything a user could type, and it arrives at a point in the pipeline the user-message classifier was never positioned to watch. The same class of classifier can catch it - but only if it is also applied to retrieved content and tool outputs at their own entry point.
What the CCAR-P exam trips candidates on
The first trap is assuming a well-tuned input classifier stops both attack types. The scenario emphasises how strong the input screening is and asks whether the injection risk is covered. The credited reading is that the classifier only ever sees the user's original message, so indirect injection - which never appears there - is untouched no matter how good the classifier is.
The second trap is classifying an attack as "not injection" because the harmful instruction never appeared in the user's own words. A scenario describes an instruction that arrived through a retrieved document, and an answer option dismisses it as something other than injection. The credited reading is that indirect injection is a genuine injection attack; the source being a fetched document rather than a user message changes where you defend, not whether it counts.
Worked example
Two incidents hit the same agent. In the first, a user typed a message telling the model to ignore its instructions and dump its system prompt. In the second, a document the agent retrieved from the corpus contained hidden text telling the model to email a customer list to an external address. The team's input classifier caught the first but not the second. Classify each attack and explain the classifier's split result.
The first incident is direct injection. The malicious instruction was in the user's own message, so it landed in front of the input classifier, which is exactly the surface that classifier defends - and it caught it. Nothing surprising there; input screening did its job on the attack it was positioned to see.
The second incident is indirect injection. The harmful instruction was never in anything the user typed; it was planted in a document the agent retrieved and treated as trustworthy source material. That content entered the context after input screening had already passed the request, so the classifier never inspected it. The classifier did not fail on the second attack - it was never given the chance to see it, because the attack entered through a different doorway.
The split result is the whole lesson: one classifier, one entry point, one surface covered. To catch the second attack, the same class of classifier must also run on retrieved content before it enters the context. And the second attack is unambiguously injection - the fetched source does not make it something else. Anyone tempted to call it "not injection" because the user never typed it has mislabelled the surface and would leave it undefended.
Common misreadings to avoid
Misconception
A well-tuned input classifier stops both direct and indirect injection.
What's actually true
Misconception
If the harmful instruction never appeared in the user's own words, it is not really injection.
What's actually true
How this shows up on the exam
Domain 5 items present an injection incident and ask you to classify it and locate the defence. The reliable method is to ask where the instruction entered: if it was in the user's message, it is direct injection and input screening is the surface; if it arrived through retrieved content or a tool response, it is indirect injection and input screening never saw it. The classifier is the same class; only the insertion point differs.
This distinction is the analytical half of the risk taxonomy, sitting between the LLM system risk taxonomy that names the categories and the indirect injection via retrieved content and tool output knowledge point that details the fix. It also draws on model-based vs deterministic check selection, since both surfaces use the same class of model-based classifier, and it feeds the system vulnerability walkthrough.
An agent's input classifier caught a user who typed 'ignore your instructions,' but missed a hidden instruction inside a retrieved document that caused a data leak. How should the two attacks be classified and understood?
People also ask
What is the difference between direct and indirect injection?
Why does a good input classifier not stop indirect injection?
Is an attack still injection if the user never typed it?
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.