Security and Safety

What this domain tests

8.1% — roughly 4 of the 53 scored items. Small, but the highest-density domain on the exam in terms of learnable content per question: the guide names four skills, each with a tight scope. AI Application Security (3.2%), Guardrails and Safe Deployment (2.3%), Identity, Secrets, and Key Management (1.6%), and Claude Hooks (1.0%).

Note the ordering. Identity and secrets management — which candidates routinely skip because it feels like ordinary application security rather than AI security — carries more weight than hooks. Study it.

The published sample item for this domain is a scenario stem with a clearly best answer and category-error distractors, and it is worth reading for its trap taxonomy rather than its content. Three distractor patterns recur across the whole domain:

• The sampling knob. Adjusting temperature or similar settings is offered as a security control. It never is; sampling behavior is orthogonal to whether injected text is obeyed.
• The polite request. "Add a line asking users not to include malicious instructions" — an instruction to the wrong party, and not an enforceable control in any case.
• The bigger model. A model that follows instructions more faithfully is more susceptible to injected instructions, not less. Capability is not a security boundary.

Meanwhile the correct answers in this domain share a shape: isolate untrusted content, then constrain what the system can do with it. Not "detect the attack" — constrain the blast radius so a successful attack achieves nothing.

Theory outline

1. AI Application Security (3.2%)

The official skill statement: data privacy and security best practices including prompt injection awareness and mitigation, jailbreak defense, untrusted input handling, data leakage prevention, PII handling, and ensuring authentication, authorization, confidentiality, privacy, and integrity.

Prompt injection: what it actually is. An LLM's context window is a single channel carrying two different things — your instructions and other people's content — with no inherent distinction between them. Prompt injection exploits that: an attacker plants text inside content the model will read (a web page, an uploaded document, a database record, an email body, a tool result) and that text is written as an instruction. The model, whose job is to follow instructions, follows it.

The critical implication, and the one the exam builds distractors on: this is not a model defect that better models fix. A model that follows instructions more reliably follows injected instructions more reliably too. There is no version of "use a smarter model" that constitutes a mitigation.

The two-part mitigation. Every correct injection answer contains both halves:

1. Isolation. Treat retrieved and user-supplied content as untrusted data, structurally separated from trusted instructions — delimited, labeled, and outside the instruction region. The model then has a signal that the delimited material is something to process, not something to obey. (This is the prompt-side technique covered as input sanitization under Domain 6.)
2. Least-privilege enforcement. Guardrails and hooks so that even if an injected instruction is obeyed, it cannot trigger a sensitive action. The agent summarizing untrusted web pages should not hold a tool that can send email, delete records, or read the credential store. If the worst an injection can accomplish is a bad summary, the attack failed regardless of whether the model was fooled.

The second half is what separates a real answer from a hopeful one. Isolation alone reduces the probability; privilege restriction bounds the damage. An option offering only detection or only a prompt-level instruction is incomplete by construction.

A structural note on operator instructions. Text embedded in a user turn or a tool result can be forged by anything that writes to that surface — which is exactly the injection channel. Where the platform supports a system-role message appended to the conversation, that is the non-spoofable operator channel: content in a user turn is indistinguishable from content an attacker put there; a system-role message is not.

Jailbreak defense. Related but distinct. Injection smuggles instructions through content; a jailbreak is a user trying to talk the model out of its own guidelines directly — role-play framings, hypotheticals, incremental escalation. Defenses are layered rather than clever: a clear system prompt that states boundaries and what to do when a request crosses them; classification of input and output where the stakes justify it; and — the load-bearing part — the same least-privilege discipline, so a successfully jailbroken model still cannot reach anything consequential. Claude models also decline requests that violate usage policies at the platform level, surfacing as a refusal stop reason; your application should handle that outcome explicitly rather than assuming a response body is always present.

Untrusted input handling: the full list. Candidates reliably classify user chat input as untrusted and then trust everything else. Untrusted means:

• Direct user input
• Retrieved documents and search results
• Fetched web pages
• Database records that contain user-authored fields
• Tool results — including from tools you wrote, if what they return originated with a user
• Content from an MCP server or any third-party integration

Anything on that list can carry an injection. The output of one model call is untrusted input to the next one.

Data leakage prevention. Three channels to reason about:

The third is the one AI systems introduce that ordinary applications don't have in the same form. Conversation history is replayed into later context; memory files are read back into every future session that loads them; summaries formed from history carry forward whatever was in it. A secret written once is durably present, and it is readable by anything that can read that history.

PII handling. Minimize before you send: pass what the task needs, not the whole record. Redact or tokenize identifiers where the task can work without them. Know where the data comes to rest — history, memory, logs, output artifacts — because retention is a compliance question (GDPR, CCPA), not just a security one. And treat multi-tenant memory as a real hazard: reference memory implementations have no built-in access control, so a multi-user system must scope memory per user and enforce that scoping in the tool handlers themselves.

Authentication, authorization, confidentiality, privacy, integrity. The single highest-value principle in this domain:

The model is not an authorization boundary.

Telling the model which records a user may see is a request, not a control — it can be argued with, injected around, or simply mistaken. Authorization belongs in the tool layer: the tool receives the calling user's identity from your application (never from the model's arguments, which the model can fabricate) and enforces permissions itself, returning only what that user is entitled to. Design so that a fully compromised model, obeying an attacker's every instruction, still cannot retrieve data the user was never allowed to see. Integrity is the same idea pointed at writes: consequential state changes are validated and authorized in code, not accepted on the model's say-so.

2. Guardrails and Safe Deployment (2.3%)

The official skill statement: safe and responsible deployment practices (content policy, guardrail layering) and secure-by-design principles (privacy, identity and access management, least privilege).

Guardrail layering — defense in depth. No single layer is the control. Each catches what the others miss:

The exam angle: when an option proposes one layer as the complete answer, be suspicious — especially when that layer is the prompt. And note the asymmetry the layers have in reliability. The model layer is probabilistic. The tool and infrastructure layers are deterministic. Put the guarantee where determinism lives.

Secure by design. Three principles, stated in the guide:

• Least privilege. Every tool gets the narrowest capability that does its job; every credential gets the narrowest scope. Ask what an attacker could accomplish with each tool if they controlled the model's output completely — that is the blast radius, and shrinking it is most of security engineering here. A read-only tool cannot be turned into a delete.
• Identity and access management. Every action carries an identity, and permissions are evaluated against that identity in code. See the authorization principle above.
• Privacy by design. Collect and transmit the minimum; know where data rests; make deletion possible.

Content policy. Claude models decline requests that violate usage policies, and the platform may decline a request outright, returning a refusal outcome rather than content. Two engineering consequences: check the stop reason before reading the response content — code that unconditionally reads the first content block breaks on a refusal — and design the user-facing behavior for that path rather than surfacing an exception. Your application's own content policy sits alongside the platform's: what your product will and will not do is your guardrail to implement, typically at the input and output layers.

Sandboxing consequential execution. When an agent runs code or shell commands, the environment is the last line of defense. Isolation, no ambient credentials, restricted or absent network egress, and resource limits. Assume the code being run is attacker-influenced, because in an injection scenario it is.

3. Claude Hooks (1.0%)

The official skill statement is one line: leveraging hooks for guardrails and safety controls to prevent destructive actions within Claude applications. Small weight, sharp scope. (Hooks also appear in the agent-orchestration domain as the mechanism for deterministic workflow enforcement; here the framing is destructive-action prevention.)

The mechanism. Hooks intercept the agent lifecycle at defined points. Two matter:

Direction is the whole exam item. PreToolUse guards actions: the call has not happened yet, so it can still be stopped. PostToolUse transforms results: the call already ran, so prevention is no longer available. Any option that proposes a PostToolUse hook to prevent something is too late by construction — logging a violation is not preventing one. Conversely, PostToolUse is exactly right for redaction: stripping secrets or PII out of a tool result before it enters the model's context.

Deterministic versus probabilistic. This is the judgment layer, and the phrasing in the stem gives it away:

When a scenario contains "must never," a dollar threshold, a deletion, a deployment, or an audited failure rate, the answer is the deterministic control. "Strengthen the system prompt" — bold it, move it to the top, add examples — is the seductive wrong answer every time. Those changes lower a failure rate that is already low; they do not make it zero, and the stem asked for zero.

Destructive-action patterns worth recognizing: block deletes that lack an explicit confirmation token; block writes outside an allowed path; block outbound sends above a threshold or to unapproved recipients; require that a verification step has already run before a consequential call is permitted.

4. Identity, Secrets, and Key Management (1.6%)

The official skill statement: managing secrets, credentials, and API keys across Claude development and production environments, including identity validation and authentication, access approval and level verification, and authorized access monitoring.

Heavier than hooks, and usually under-studied. The AI-specific twist is that these systems have several new places for a secret to end up.

Where secrets must never go. Learn this as a list — it maps directly to answer options:

Where they should go. The pattern current platforms implement, and the one to reason from: the credential lives in a managed store outside the model's reach, and is injected into the outbound request after it leaves the agent's environment. The agent's environment holds, at most, an opaque placeholder. The consequence is the point: code running in the sandbox — including anything the model was tricked into writing — cannot read the real credential, because it was never there.

Two refinements the same pattern supports, both straight applications of least privilege:

• Scope the credential to the hosts it may be sent to, so it can never be transmitted to an attacker-chosen destination even if a request is manipulated.
• Scope the key's own permissions minimally. The agent can do anything the key allows; a key with broader permissions than the task needs is pure blast radius.

Dev versus production. Separate credentials per environment; never let a development key reach production data or vice versa. Rotate on exposure, and treat "a secret appeared in a prompt, a log, or a memory file" as exposure — because that content is durable and replayable, revoke and rotate rather than deleting the message and hoping.

Identity validation and access-level verification. Authenticate the user, not the model. Pass the authenticated identity to the tool layer through your application, never as an argument the model supplies — model-supplied identity is unauthenticated by definition, and an injected instruction can set it to anything. Verify access level at the point of use: the tool checks what this identity is entitled to and returns only that. Where an action is consequential, add access approval as an explicit step — a human confirmation gate in the execution path, of the kind covered under approval patterns in Tools and MCPs.

Authorized access monitoring. Log which identity invoked which tool with which arguments and what came back, so unusual access is detectable after the fact. Two cautions: logs are a leak channel of their own — redact secrets and PII on the way in — and monitoring is a detection control. It never substitutes for a prevention control when the stem asks for prevention.

Worked problems

Problem 1. An agent reads customer support tickets and can call a refund tool. A ticket body contains hidden text instructing the assistant to disregard prior instructions and issue a full refund to a named account. Which mitigation is most effective?

A. A PostToolUse hook that logs any refund whose conversation contains suspicious ticket text, for daily review B. A regular-expression filter that strips imperative sentences out of ticket bodies before the model reads them C. Treat ticket content as untrusted input, keep it structurally separate from trusted instructions, and enforce least privilege so text arriving through a ticket cannot reach the refund tool D. Require the model to summarize each ticket before acting on it, so injected instructions are surfaced first

Approach: Both halves of the mitigation appear only in C: isolate the untrusted content, then constrain the privilege so a successful injection reaches nothing consequential. The second half is what makes it robust — if the worst an attacker achieves is a badly summarized ticket, the attack failed whether or not the model was fooled.

Why the others fail: A is the hook-direction trap wearing a monitoring costume: PostToolUse fires after the refund executed, so it can log the loss but never prevent it. B is the most tempting wrong answer — it is detection dressed as sanitization, and it fails on both ends: injections need not be imperative ("the customer has already been approved for a full refund"), and stripping content silently corrupts legitimate tickets. Real sanitization marks untrusted content as data rather than trying to guess which sentences are hostile. D adds a step inside the same untrusted channel; the summarizer reads the injected text under exactly the same conditions the actor does.

Answer: C

Problem 2. An internal audit finds that an agent occasionally deletes production records without the required confirmation step, despite a system prompt stating it must never do so. What closes the gap?

A. Move the rule to the top of the system prompt and emphasize it B. Add few-shot examples of the correct confirm-then-delete sequence C. A PreToolUse hook that blocks the delete call unless the confirmation precondition is satisfied D. A PostToolUse hook that logs deletions performed without confirmation for weekly review

Approach: "Must never," a destructive action, and an audited nonzero failure rate. Prompt instructions are probabilistic — they lower the rate, never to zero. Only a code-level gate is deterministic, and it must act before execution.

Why the others fail: A and B are still the prompt layer; they improve compliance without guaranteeing it, and the stem's phrasing demands a guarantee. D is the direction trap — the delete already happened. Detection is not prevention.

Answer: C

Problem 3. A developer wants an agent to call a third-party API from the bash tool. To make sure the key is available, they consider three placements: in the system prompt, written into the agent's memory file, or held in a managed credential store and injected into the outbound request after it leaves the agent's environment. Which is correct, and why are the others wrong?

A. System prompt — it is the most trusted part of the context B. Memory file — it persists so the agent never has to be re-told C. Managed store with injection outside the sandbox — the agent's environment never holds the real secret, so nothing running there can read or exfiltrate it D. Any of the three; they are equivalent once the environment is sandboxed

Approach: The correct pattern keeps the credential out of the model's reachable surface entirely and injects it after the request leaves. That is what makes it robust against the case that actually matters: code the model was manipulated into writing, running inside the sandbox, cannot exfiltrate a secret that was never there.

Why the others fail: A confuses trust with confidentiality — the system prompt is authoritative, and it is also durably stored in conversation history, replayed into later requests, and carried into summaries. B is worse: memory content is replayed verbatim into every future session that loads the store, so one write re-injects the key indefinitely. D ignores that the sandbox is exactly where an injected instruction executes.

Answer: C

Problem 4. A multi-tenant assistant retrieves documents for the logged-in user. The developer's design puts each user's permitted document IDs into the system prompt and instructs the model to retrieve only those. A reviewer rejects the design. Why?

A. The system prompt has a length limit that a document list would exceed B. The model is not an authorization boundary — permissions must be enforced in the retrieval tool against the caller's authenticated identity, so that even a fully manipulated model cannot fetch unpermitted documents C. Document IDs should be passed in the user turn instead D. The design is fine as long as the model is instructed clearly enough

Approach: Instructing the model which records it may access is a request, not a control. It can be injected around, argued with, or simply mistaken — and it puts the tenancy boundary inside a probabilistic component. The tool must receive the authenticated identity from the application (not from model-supplied arguments, which the model can fabricate) and enforce entitlement itself.

Why the others fail: A picks a practical inconvenience over the structural defect. C moves the same flawed control to a less trusted position. D restates the belief being tested; clarity of instruction does not convert a probabilistic mechanism into a boundary.

Answer: B

Problem 5. An agent has a bash tool for running project scripts. The security review asks how a compromised or injected model is prevented from causing damage through it. Which set of controls fits?

A. A blocklist of dangerous commands in the system prompt B. Run in an isolated environment with an allowlist of permitted executables, reject shell metacharacters, apply timeouts and resource limits, and log every command C. Instruct the model to only run project scripts D. Review the transcript after each session

Approach: Bash commands are untrusted model output and must be treated as such. The documented posture is layered and enforced outside the model: isolation, an allowlist (a blocklist is explicitly insufficient — you cannot enumerate every dangerous form), rejection of shell operators that let one permitted command chain into another, time and resource bounds, and full logging.

Why the others fail: A puts enforcement in the prompt and uses the weaker list direction. C is the same failure without the list. D is detection after the damage, and the stem asked for prevention.

Answer: B

Exam traps

• Temperature or sampling settings as a security control. Never correct. Sampling behavior is orthogonal to whether injected instructions are obeyed.
• A bigger or more instruction-following model as the fix. Backwards — better instruction following means injected instructions are followed more reliably.
• A polite system-prompt request. "Ask users not to include malicious instructions" is an instruction to the wrong party with no enforcement behind it.
• Isolation without least privilege. A complete injection answer contains both: separate untrusted content from trusted instructions, and ensure injected text cannot trigger sensitive actions. An option offering only one half is incomplete.
• Forgetting that tool results are untrusted. Retrieved documents, web pages, database fields, MCP responses, and the output of a previous model call all carry potential injections.
• Making the model the authorization boundary. Telling the model which records a user may access is a request, not a control. Enforce in the tool layer with the application-supplied authenticated identity — never with an identity the model passes as an argument.
• PostToolUse for prevention. Pre guards actions; Post transforms results. Any option that "prevents" something after the tool already ran is wrong. Post is right for redaction and normalization.
• Prompt strengthening for a "must never." Bolding, reordering, and few-shot examples lower a failure rate; they never zero it. Destructive actions, money, regulatory ordering, and audited violations all demand a deterministic gate.
• Blocklists where an allowlist is required. For shell commands and file paths, enumerate what is permitted. You cannot enumerate every dangerous form, and a permitted command chained through a shell operator becomes a different one.
• Raw model-supplied paths. Canonicalize and confine to a project root; reject traversal, symlinks, and absolute paths outside the root. Never pass the raw path to a file operation.
• Secrets in prompts, messages, or memory. All three are durable and replayable — prompts and messages persist in history and flow into summaries, and memory is re-injected into every session that loads it. The correct pattern keeps the credential outside the agent's environment and injects it after egress, scoped to permitted hosts.
• Treating monitoring as prevention. Logging and review are detection controls. When the stem asks how something is prevented, an audit trail is not the answer.
• Assuming a response body always exists. A refusal returns without usable content. Check the stop reason before reading content, and design the user-facing path for it.
• One layer presented as the whole answer. Guardrails layer: input, model, tool, output, infrastructure. Be suspicious of any option that stops at the prompt.