The Three-Point Guarded Request Path for the CCAR-P Exam

Three gates, three different questions

Once you accept that deployment-specific rules live in a runtime layer you build, the next question is where on the request path those runtime controls sit. The CCAR-P exam treats this as an understand-level skill because the whole design fails in a predictable way when candidates collapse three separate checkpoints into one. A guarded request path has three decision points, and each one answers a question the other two cannot.

The reason they are not interchangeable is that they inspect different things at different moments. One looks at the request as it arrives, one looks at the response the model produced, and one looks at an action the model is about to take. Placing a single control anywhere on that path leaves the other two questions unanswered, which is exactly the gap production incidents fall into.

Input screening: should this reach the model at all

Input screening runs before the model call. Its job is to decide whether the incoming request should reach the model in the first place - catching a jailbreak attempt, a prompt-injection pattern, a banned term, or an oversized payload before any tokens are spent. It is the only checkpoint that can stop a bad request from ever being processed, which makes it the right place for concerns that are cheapest to handle before generation.

What input screening cannot do is judge anything the model produces or any action the model later emits. It has seen only the request. If you rely on it as your whole defence, you are protected against bad inputs and exposed to everything downstream of the model call.

Output screening: is this response safe to return

Output screening runs after generation and before the response reaches the user. It inspects what the model actually produced - checking for toxicity, policy violations, a leaked field, or a schema breach - and decides whether that text is safe to return. It is the last gate before the user, and it is genuinely useful for catching a bad response the model generated despite a clean input.

Its blind spot is timing. Output screening looks at text, and it looks at that text only after generation. Anything the model already did on the way to producing that text - most importantly, any tool it called - has already happened by the time the output filter runs. Screening the words does nothing to unwind the deed.

Tool-call authorization: may this action run in this context

Tool-call authorization runs before any action with side effects: sending an email, writing to a database, issuing a refund. It answers a question neither of the other checkpoints touches - not "is this text safe" but "may this specific caller perform this specific action in this specific context." Because it gates the action itself, it is the only control that can stop an irreversible operation before it takes effect.

That placement is what makes it irreplaceable. A refund is a financial action; once the tool runs, money has moved. No amount of input or output screening recovers that. If a side-effecting action exists on the path, an authorization gate has to sit directly in front of it.

What the CCAR-P exam trips candidates on

The signature trap is treating a single output-side content filter as a complete guarded path. A scenario shows a clean architecture diagram with one classifier on the output, the review passes, and you are asked whether the system is guarded. The credited answer is no, because the most consequential thing the system does - a side-effecting tool call - happens before that filter ever runs, and no check exists on the input.

The companion trap is assuming an action is "covered" because the text response was screened afterward. A refund, an email send, a database write - the exam will describe one running, then an output filter inspecting the generated text and passing it. Candidates who track the ordering see that the action already executed downstream of nothing and upstream of the only control present. The action was never authorized; it was merely narrated, and the narration passed a filter.

Common misreadings to avoid

How this shows up on the exam

Domain 5 items give you a request path and ask which checkpoints are present and which question each answers. The reliable method is to trace the request in order - arrival, input screening, model call, tool authorization before any action, output screening, response - and confirm every point that needs a control has one. A missing gate is an attack surface regardless of how complete the diagram looks.

From here the domain refines each checkpoint. Deciding whether a given gate should be a classifier or a rule is the subject of model-based vs deterministic check selection, and deciding what a gate does when it errors is fail-open vs fail-closed design. The path itself resurfaces in the system vulnerability walkthrough, where you audit every entry point for a missing control, and in indirect injection via retrieved content and tool output, which reveals a fourth screening need input screening never sees.