Security and Safety

Security and Safety is 8.1% of the CCDV-F blueprint — roughly 4 of the 53 scored questions. It has the most sub-skills of any small domain: AI Application Security (3.2%), Guardrails and Safe Deployment (2.3%), Identity, Secrets, and Key Management (1.6%) and Claude Hooks (1.0%). Four named areas across four questions means breadth beats depth here; a candidate who has covered all four superficially will outscore one who has mastered injection defence alone.

The organising idea is that a model is a confused deputy waiting to happen. It acts with your application's authority, and it reads content — web pages, documents, emails, tool results, repository files — that an attacker may have written. Prompt injection is therefore not a filtering problem but a trust-boundary problem, and the mitigations are about where untrusted content enters, what the model is allowed to reach, and what happens before an action executes.

The second idea is the difference between instruction and enforcement. Telling a model not to do something is guidance it weighs. A permission rule that denies a tool, a hook that blocks an action, a credential the sandbox never sees — those are guarantees, executed by the harness rather than decided by the model. Almost every correct answer here moves a control from the first category into the second, and almost every distractor solves a security problem by adding a sentence to the system prompt.

What the exam actually tests

• —Direct versus indirect prompt injection — who the adversary is, and why the mitigations differ
• —Delivering untrusted third-party content in tool results with explicit provenance, never as system or plain user text
• —Least privilege for agents: bounded tool access, sandboxing, and screening tool output before acting on it
• —Refusals as a normal response with `stop_reason: "refusal"` — not an error, and not something to retry unchanged
• —Hooks and permission rules as harness-enforced guarantees rather than model-weighed guidance
• —Credential handling: keys in the environment or a secret store, scoped down, never in prompts or message history

Two injection threat models, two playbooks

Anthropic's guidance splits the problem cleanly. In **direct** injection — the classic jailbreak — the user of your application is the adversary, trying to talk the model out of its instructions. In **indirect** injection the user is trusted, but the model processes third-party content such as a web page, an email, a document or a tool result that carries adversarial instructions. The defences differ. Direct injection is handled with harmlessness screening on input, validation, prompt design, monitoring, and responding to repeat offenders. Indirect injection is handled structurally: deliver untrusted content inside `tool_result` blocks rather than in the system prompt or a plain user text block, tell the model explicitly what the content is and where it came from, state the handling policy in the system prompt, and JSON-encode the content so its boundaries are unambiguous.

Reduce the blast radius, then screen

No prompt-level control is reliable enough to stand alone, so the substantive defences limit what a successful injection can achieve. Give the agent the narrowest tool set and data access the task needs, sandbox execution, and keep irreversible actions behind approval. A complementary control is screening: run tool output through a cheap, fast classifier before the main model acts on it — a small model with a structured output returning a boolean such as `injection_suspected` is a documented pattern — and treat a positive as a reason to stop rather than to continue carefully. One rule is easy to overlook and worth memorising: do not put *your own* instructions inside tool results. If your legitimate instructions arrive by the same channel as untrusted content, you have taught the model to obey that channel.

Guardrails and safe deployment

Guardrails are the operational half of the domain: reducing hallucination, increasing output consistency, limiting prompt leak, and handling refusals gracefully. The refusal path is the most mechanically specific. Current frontier models run safety classifiers that can decline a request, and a decline is **not** an error — it arrives as a successful response carrying `stop_reason: "refusal"`, with a `stop_details` object whose category may be `cyber`, `bio`, `frontier_llm`, `reasoning_extraction` or `general_harms`. Benign work adjacent to those areas can trigger one, so applications in security or life-sciences domains should expect it. Branch on `stop_reason`, not on the inner detail fields, which can legitimately be null; and recover by resetting the conversation context or routing to a fallback rather than resending the same request.

Claude hooks: enforcement the model cannot skip

Hooks are the blueprint's named enforcement mechanism, and they earn their own sub-skill because they change the security model. A hook is a handler configured to run at a defined point in a session's lifecycle — before a tool call, after one, on prompt submission, at session start or end, and many others — and it is executed by the harness, not chosen by the model. That is the entire point: a rule in a prompt is guidance the model weighs against everything else in its context, while a hook fires every time. A hook that exits with code 2 is a blocking error, and a pre-tool-use hook can return a structured decision that allows, denies or escalates a call for approval. Use hooks for the invariants you cannot afford to lose, and permission rules for the tools and paths that should never be reachable at all.

Identity, secrets and key management

Credentials belong to the harness, never to the conversation. An API key is read from the environment or a secret store; it never appears in a system prompt, a user message, a tool description or a memory file, because all of those are persisted in conversation history and stay readable long after the request. Beyond storage, three habits matter. Scope down — an agent can do anything its key allows, so issue the narrowest permissions the task needs. Do not pass tokens through: a token issued to one service must not be forwarded to another, a rule the Model Context Protocol states normatively and enforces through audience binding. And treat caller-supplied identifiers as untrusted — authorise a file or resource ID against the caller rather than simply dereferencing it.

Where candidates go wrong

How to study this domain

Four sub-skills across roughly four questions means covering all four rather than going deep on one. Give AI Application Security the largest share at 3.2%, then guardrails at 2.3%, secrets at 1.6% and hooks at 1.0%.

The highest-yield thing to memorise is the indirect-injection playbook, because it is a short checkable list: untrusted content goes in tool results, label what it is and where it came from, state the policy in the system prompt, JSON-encode it, keep your own instructions out of that channel, limit access, screen outputs, and red-team your own agent. Recall that list and every injection scenario becomes answerable — the correct option is nearly always one of those items, the distractor nearly always a prompt-only fix.

Second, learn the refusal path exactly: successful response, `stop_reason: "refusal"`, category in `stop_details`, reset or fall back rather than retry. Small, precise, and easy to fumble under time pressure.

Finally, practise sorting controls into guidance and guarantee. Take ten requirements you have shipped and decide for each whether it belongs in an instruction file, a permission rule, a hook, or code. That sorting exercise is, in substance, what this domain examines.

Common questions