The LLM System Risk Taxonomy for the CCAR-P Exam

A checklist you run against every design

Most of the risk in an LLM system falls into a small, nameable set of categories. The CCAR-P exam treats knowing them as a remember-level skill, because they are the checklist an architect runs a proposed design against - the vocabulary that turns a vague worry about "AI security" into a set of specific questions with specific controls. Naming them is the first step of any risk assessment, and every deeper skill in this task statement assumes you can recite them.

The value of a taxonomy is coverage. When you can list the five categories, you can walk a design and ask, for each one, whether a control stands in the way. A design that has never been checked against "indirect injection" or "data exposure through logging" has an unexamined surface, and the exam is fond of scenarios where the missing category is exactly the one that failed in production.

The five categories

Direct prompt injection is a user crafting input that overrides the system's instructions and redirects its behaviour. The attacker controls the user turn, so this attack targets input screening directly.

Indirect prompt injection is malicious instructions arriving through retrieved content or tool outputs that the model treats as trusted, which user-input screening never inspects. It is a distinct surface from direct injection, defended at a different point in the pipeline.

Token-budget exhaustion is oversized or adversarially padded input consuming the context or output budget - truncating useful work or inflating per-request cost. It is a security and reliability failure, not merely a cost nuisance.

Tool and action abuse is the model being induced to call a side-effecting tool outside policy. This is the exact failure that tool-call authorization exists to stop.

Data exposure is sensitive fields entering the context window or the logs where they should not, creating a leak that can occur independently of anything the model outputs.

Why the boundaries between categories matter

The categories are deliberately distinct because their controls are distinct. The most common oversimplification is collapsing "prompt injection" into one category, when direct and indirect injection need controls at different points - user-input screening for one, retrieved-content and tool-output screening for the other. Treating them as a single item leaves one of the two surfaces uncovered.

The other boundary worth holding is that data exposure can happen purely through logging, independent of the model. A system can produce clean, screened output and still leak a Social Security number into a log file. Because the exposure did not travel through the model's response, no output filter would catch it - which is why data exposure is its own category rather than a subcase of output screening.

What the CCAR-P exam trips candidates on

The first trap is treating prompt injection as a single category rather than two distinct attack surfaces. A scenario defends the user's message thoroughly and calls injection handled; the credited reading names indirect injection as a separate, still-open surface. The taxonomy exists precisely so you do not conflate the two.

The second trap is forgetting that data exposure can happen purely through logging. A scenario shows a clean, well-screened model output and asks whether sensitive data is protected; candidates who equate data protection with output screening miss that the logging pipeline is a separate exposure point. The exam rewards checking all five categories rather than stopping at the ones the visible controls already address.

Common misreadings to avoid

How this shows up on the exam

Domain 5 items ask you to identify the risk categories present in a proposed architecture, usually expecting at least three with a matching mitigation each. The reliable method is to run all five categories against the design rather than stopping at the visible controls, paying special attention to the two injection surfaces and to logging as an exposure point. The categories you almost miss are the ones the exam is testing.

This taxonomy is the entry point to the whole risk task statement. It expands into the direct vs indirect injection distinction and token-budget exhaustion as an attack surface, it is applied end to end in the system vulnerability walkthrough, and each category maps onto a checkpoint from the three-point guarded request path.