Prompt Injection
Text that reaches the context as data and is read as instruction. Claude receives one context: system prompt, turns, tool definitions and tool results. All of it is text, so nothing structural separates your commands from a supplied document's sentences.
Exam context: A property of how these systems work, not a defect awaiting a patch. No software update will remove it. Every right answer on this topic is structural: separation, least privilege, a deterministic gate, or a check on the outbound path.
See also: 7.1 AI Application Security
Direct Prompt Injection
The threat model where the user of your application is the adversary, crafting input intended to bypass your guardrails. Jailbreaks belong to the same class.
Exam context: Mitigations act on the input path: a harmlessness screen (a check for harmful content) before the main call, input validation, a system prompt stating boundaries and how to refuse, and a policy for repeat offenders. Offering these for a payload that arrived inside fetched content is the usual wrong option.
See also: 7.1 AI Application Security
Indirect Prompt Injection
The threat model where the user is trusted and the adversary is whoever influenced content Claude reads on their behalf: an inbound email body, a fetched page, OCR text, a tool result.
Exam context: The class that matters in agentic applications, because the attacker never uses your interface and the payload arrives through a channel your users already trust. The controls that work act on the tools the agent can call and on the outbound path.
See also: 7.1 AI Application Security
tool_result Block
The content block third-party text belongs in. Claude is trained to treat instructions appearing inside tool results with appropriate scepticism, which is why current guidance puts untrusted content there and never in a system prompt or a plain user text block.
Exam context: Current docs go further than wrapping everything in XML tags, and the placement rule is tested. Its inverse is tested just as often: your own instructions must not go inside a tool result, or Claude may ignore them or flag them as an injection attempt.
See also: 7.1 AI Application Security
JSON-Encoded Untrusted Content
Serialising a third-party string rather than concatenating it into free-form text. Escaping supplies unambiguous delimiters, so an attacker cannot close a quote or a tag to escape the data and be read as an instruction.
Exam context: The exam tests the reason. Wrong options offer delimiters that an attacker can close, or claim the encoding is about parsing convenience rather than about stopping an escape from the data.
See also: 7.1 AI Application Security
Harmlessness Screen
A lightweight model call that classifies content before the main call runs. Structured outputs constrain its verdict to a parseable value rather than prose. The docs name Claude Haiku 5.5 for it. Its safety classifiers can decline the screen itself, so the docs treat a stop_reason: "refusal" on the screening call as a harmful verdict.
Exam context: A check with an enforcement point, a place where the check can stop the content, because the application decides whether the content reaches the model. But it is still a model, so it is probabilistic and it misses. That is why it is used together with deterministic controls rather than replacing them.
See also: 7.1 AI Application Security
Least Privilege
Cutting what a successful injection could reach: the smallest set of tools and the narrowest credential scope that still does the job.
Exam context: Three moves, not interchangeable. Remove the tool, so there is no decision left to influence. Scope the tool, so matching calls are denied in every permission mode. Narrow the credential, so the query never had that access.
See also: 7.1 AI Application Security, 7.2 Guardrails and Safe Deployment
Bare-Name Deny Rule
A deny entry naming a tool with no pattern, such as disallowed_tools=["Bash"]. It removes the tool definition from the request, so Claude does not see the tool and cannot attempt it.
Exam context: The strongest form of least privilege over a set of tools, and the reason removal is stronger than denial. The tempting wrong answer next to it is an allow list, which does not constrain bypassPermissions.
See also: 7.2 Guardrails and Safe Deployment
Scoped Deny Rule
A deny entry carrying a pattern, such as disallowed_tools=["Bash(rm *)"]. The tool stays available and matching calls are denied in every permission mode, bypassPermissions included.
Exam context: An enforceable boundary rather than a preference, which is what separates it from a system-prompt sentence describing the same restriction.
See also: 7.2 Guardrails and Safe Deployment
Permission Evaluation Order
The published sequence a tool call runs through: hooks, then deny rules, then ask rules, then the permission mode, then allow rules, then the canUseTool callback.
Exam context: Knowing the order is what tells you whether your check runs at all. A call approved at any earlier step skips canUseTool entirely. So a security check written there is silently bypassed for that tool. For a check that must run on every call, use a PreToolUse hook.
See also: 7.1 AI Application Security, 7.3 Claude Hooks
Prompt Leak
The escape of anything in the context through the response: the system prompt, internal identifiers, another tenant's rows, a retrieved document the caller was never entitled to see.
Exam context: The documented ordering is monitoring first, then output screening and post-processing, and leak-resistant prompt engineering last, because it adds complexity to the model's main task. The durable fix is not putting the value in the context at all. Prefilling the assistant turn is not supported on Claude 4.6 and later, so it is unavailable as a control.
See also: 7.1 AI Application Security
Zero Data Retention
An arrangement under which Anthropic does not store customer prompts or responses at rest after the API response is returned.
Exam context: Enabled per organisation by arrangement, never extending automatically to a sibling organisation on the same account. It excludes Console usage, Managed Agents sessions, consumer plans and features such as code execution, and it does not override retention of a trust-and-safety-flagged session for up to two years.
See also: 7.1 AI Application Security
Covered Models
Models that require 30-day retention and are therefore not available under a zero data retention arrangement.
Exam context: The exception to the assumption that ZDR covers every model. Retained data is never used for model training without express permission, which is a separate promise from retention itself.
See also: 7.1 AI Application Security
PII Minimisation
Keeping data the task does not need out of the context window: redacting or tokenising where a raw value adds nothing. A summariser rarely needs a full account number to do its job.
Exam context: The control that works is the one that stops the data existing in that place. Your own request-and-response log is a complete second copy of everything the model saw. It usually has wider access and longer retention. So redact the data when you write it to the log.
See also: 7.1 AI Application Security
Confused Deputy
An agent holding a credential broader than the person it acts for, so any text that can influence it can use the wider authority.
Exam context: A record-lookup tool authenticated with a service account that can read every tenant's data is an authorisation defect, not a prompting one. The right fix authorises per the end user's entitlements at the point of use, which makes the model's persuadability irrelevant.
See also: 7.1 AI Application Security
Authorisation
What a caller may do, resolved per action rather than once at the point of entry. Distinct from authentication, which establishes who the caller is, and from integrity, which covers whether the data and the action are what they claim to be.
Exam context: Multi-tenant isolation follows from authorisation, never from a system-prompt sentence naming the tenant. Retrieving every row and then filtering is a defect that looks like a control: the data reached the context, so one persuaded response leaks it.
See also: 7.1 AI Application Security, 7.4 Identity, Secrets, and Key Management
Guardrail
A check with an enforcement point, a place where it can stop or change what happens next. Three questions settle whether something qualifies: what does it inspect, where does the code run, and what happens when it fires.
Exam context: If the answer to the third is that the model reads something and decides, it is a behaviour shaper: it influences behaviour but enforces nothing. A log records afterwards and a dashboard alerts a human who may be asleep; both are worth having and neither is what the word means in an exam question.
See also: 7.2 Guardrails and Safe Deployment
Guardrail Layering
Running independent checks at different points so a payload that passes one check still meets another check that fails in a different way. The four layers are input checks, the system prompt and training, tool-level controls, and output checks.
Exam context: Layers are not interchangeable, because each fails differently: a stricter output check cannot see what an input screen would have caught before the draft was written. The most common wrong answer throughout the sub-skill is a safety strategy made of one layer.
See also: 7.2 Guardrails and Safe Deployment
Behaviour Shaper
A control that influences what the model does without enforcing anything: a system-prompt rule, a contributor-guide section, a stated policy on untrusted content.
Exam context: Genuinely worth having, and genuinely recommended. Still the wrong answer when the question asks which control stops something, because two options can describe the same check and differ entirely in what they do when they fire.
See also: 7.2 Guardrails and Safe Deployment
Usage Policy
Anthropic's governing content policy, in three parts: Universal Usage Standards, High-risk Use Case Requirements, and Additional Use Case Guidelines. "Acceptable Use Policy" remains only as the URL slug and an alias.
Exam context: The third part names consumer-facing chatbots and agents, products serving minors, agentic use cases and software listed in Anthropic's directories, so a team shipping an agent is reading about its own product rather than somebody else's. Its chatbot rule applies whether or not a High-risk AI Recommendation is involved: every consumer-facing chatbot or AI agent that communicates directly with external users must tell them they are interacting with AI rather than a human, at a minimum at the beginning of each chat session or in the product interface.
See also: 7.2 Guardrails and Safe Deployment
High-risk AI Recommendation
The Usage Policy's term for a recommendation in one of eleven High-risk Areas: legal, medical, finance, credit, insurance, housing, employment, education and credentials, healthcare access, public benefits and services, and legal status and adjudication. Two controls apply. A qualified person with the authority to change the recommendation must meaningfully review it before it is delivered as advice or used to implement a decision. The person who receives the advice, or who is the subject of the decision, must be clearly told that AI was used to produce it.
Exam context: No engineering work fulfils the obligation, and the wrong option is there precisely because it is technically sound. The exam tests whether you notice that a scenario is inside a High-risk Area at all.
See also: 7.2 Guardrails and Safe Deployment
Fail Closed
Refusing or holding a consequential action when the check that guards it cannot run: a classifier that times out, an inconclusive validation, an approval service that does not answer.
Exam context: Here, do the opposite of what you would do to keep a service available. If the action proceeds, the check becomes a suggestion that any dependency failure removes. Then whoever can cause the failure can run the action without the check and with no extra effort. Retrying is fine. Making the model the final fallback when the retries fail is not.
See also: 7.2 Guardrails and Safe Deployment
dontAsk
The Agent SDK permission mode that denies any call that would otherwise prompt, rather than prompting for it. Calls your allow rules pre-approve, and calls that need no approval in default mode, still run. A permission mode that fails closed, and the right choice for a headless agent, one that runs with nobody present to answer prompts.
Exam context: Its Claude Code counterpart is fail-closed matching: in Manual mode (config value default), unmatched commands require approval by default. As of September 2026, Manual is not the starting mode for interactive sessions, which start in auto mode from v2.1.283. Both are named instances of the same principle rather than separate facts.
See also: 7.2 Guardrails and Safe Deployment
Red-Teaming
Testing your own agent before deployment with documents and tool outputs that deliberately carry injection attempts. You then confirm both that Claude ignores them and that your screening and confirmation steps catch the rest.
Exam context: Part of the set of controls, not a separate operations task. The docs treat analysis of outputs as an input to refining prompts, validation and filtering, so a well-built deployment with no observation is a wrong answer, not merely one with too little monitoring.
See also: 7.2 Guardrails and Safe Deployment
Hook
Your own code, connected to a named point in the agent's lifecycle, that inspects what is about to happen and can allow, modify or block it. The documented framing: hooks give deterministic control, so certain actions always happen rather than relying on the model to choose to run them.
Exam context: When a team has told the model three times not to do something and it has done it anyway, the fix is not a fourth instruction. It is a check the model does not participate in. That distinction is all that this sub-skill covers.
See also: 7.3 Claude Hooks
PreToolUse
The pre-execution inspection point: the hook event that fires before a requested tool call runs, receiving the tool name and its input.
Exam context: Prevention happens at this point. A PostToolUse hook that logs every removal is a real control for accountability and a complete, plausible wrong option, and it runs after the destructive call has already executed.
See also: 7.3 Claude Hooks
Exit Code 2
The blocking signal from a command hook. The reason printed on stderr reaches Claude. Exit 0 means no objection, which is not approval. Any other non-zero exit with plain-text or empty stdout is a non-blocking error that lets the action proceed, unless the hook sets onFailure: "block".
Exam context: The fact that the exam tests in this sub-skill. A hook that exits 1 on failure has quietly disabled itself and will keep reporting a hook error while the tool call runs. On blocking-capable events, exit 2 takes precedence even over a printed permissionDecision of allow.
See also: 7.3 Claude Hooks
permissionDecision
The JSON alternative to an exit code: hookSpecificOutput carrying allow, deny, ask or defer, with a permissionDecisionReason. As of October 2026, defer is honoured only in a non-interactive -p run. There, honouring defer ends the turn and keeps the call in the transcript, so the calling application can resume it later. Where several hooks return different decisions, the precedence is deny, then defer, then ask, then allow.
Exam context: Claiming too much for it is wrong in both directions. A hook deny applies even in bypassPermissions mode, because hooks run first; a hook returning allow does not clear a matching deny or ask rule. Hooks tighten restrictions, they do not loosen them.
See also: 7.3 Claude Hooks
Command Hook
The hook type that runs a shell command you wrote, reading the event's JSON on stdin. One of five types, of which command, http and mcp_tool run code you control. The prompt type is a single-turn model evaluation and the agent type is multi-turn verification with tool access. Both are documented as being for decisions requiring judgement rather than deterministic rules. Agent hooks are still experimental.
Exam context: Connecting a prompt or agent hook to a destructive action gives the decision back to a model, which is exactly the discretion the sub-skill exists to remove. Where the rule is a boundary, use command.
See also: 7.3 Claude Hooks
Sandbox
OS-level enforcement that blocks every process from reaching a path. The answer where a rule cannot apply, because path-based deny rules do not apply to a subprocess that opens files itself.
Exam context: One of the honest limits a single hook cannot cover. Another is disableAllHooks, for which the answer is managed settings. Only managed settings keep managed hooks running when a lower-scope file disables them.
See also: 7.3 Claude Hooks
Static API Key
An sk-ant-api... secret sent as a bearer token in the Authorization header, which every client SDK reads from ANTHROPIC_API_KEY. As of September 2026 the x-api-key header is legacy but still supported. Each key is a personal key, a service account key or a legacy workspace key. Documented good practice: store it in a secrets manager, rotate periodically, and disable or delete any key suspected of having leaked.
Exam context: Anything shipped to a client is public, so the key never belongs in a bundle, a binary, source control, a log line or the prompt. Minification and encoding are transformations the code reverses on every start. Obfuscation is not secrecy.
See also: 7.4 Identity, Secrets, and Key Management
Key Expiration
A lifetime chosen when a key is created, from presets of 3 hours, 1 day, 7 days or 30 days, a custom duration, or Never. It is set at creation and cannot be changed afterwards; an expired key returns 401 authentication_error and cannot be reactivated.
Exam context: The docs are clear about its limits: it limits the lifetime of a leaked credential and is no substitute for secret hygiene (careful handling of secrets). Because it cannot be changed after creation, it is not something you can apply to a key that is already in use.
See also: 7.4 Identity, Secrets, and Key Management
Workload Identity Federation
The structural alternative to a distributed key. At POST /v1/oauth/token, the workload exchanges an identity token from an identity provider (IdP) you already trust for a short-lived Claude token. The SDK refreshes that token automatically. There is no sk-ant-api... string to create, distribute or rotate.
Exam context: The exam tests the documented caveat. The trust chain is only as strong as the identity provider's configuration, and a long-lived secret one step earlier in the chain still undermines it. The federation rule carries the least-privilege decisions: its match conditions decide which workloads may create a token, and its oauth_scope sets the maximum access, so a workload that only calls Claude gets workspace:inference rather than workspace:developer.
See also: 7.4 Identity, Secrets, and Key Management
App Attest
The dated exception to the rule that a client never holds a key. A genuine, attested installation of a registered iOS or macOS app can call the Claude API with no back end. It uses tokens that are scoped to your workspace, expire after one hour and authorise only Messages API calls.
Exam context: An attestation mechanism for native apps, not permission to put a key in a web page. A browser bundle remains the wrong architecture, and the backend boundary is still what gives you user authentication, per-request authorisation and per-user quota.
See also: 7.4 Identity, Secrets, and Key Management
Exposure Playbook
The order to run when a key leaks: stop the credential from working, remove it from wherever it leaked, fix the design that put it there, then review the access logs.
Exam context: The sequence is the examinable part, because every wrong answer is a real step performed in the wrong order. One test settles it. If the exposed credential is still valid when the answer ends, the answer is wrong. Programmatically, step one is an Admin API status update: inactive disables the key reversibly, and archived deletes it permanently.
See also: 7.4 Identity, Secrets, and Key Management
Level Verification
Re-checking entitlement per action at the point of use, rather than inheriting the answer a session got when it opened. Where an agent acts on somebody's behalf, its tool calls carry that person's authority rather than a service account's.
Exam context: A session that authenticated an hour ago tells you nothing about whether this particular elevated operation is permitted. Approval flows belong in the same group: who may authorise the action, and how the decision is recorded.
See also: 7.4 Identity, Secrets, and Key Management
Attribution
The property that makes an anomaly investigable: every line of spend resolving to a named caller. Usage and cost reporting runs per key and per workspace, so keys scoped by project or environment supply the identity an alert needs.
Exam context: A key with no attribution cannot be investigated. If three services share one credential, an anomalous spike names none of them, and the first fix is a distinct key per service rather than a better alert. Throttling caps the bill without supplying an identity that was never issued.
See also: 7.4 Identity, Secrets, and Key Management
Admin API
The organisation-management API, taking an Admin API key, an org:admin OAuth token, or a personal or service account key that is not scoped to one workspace. It lists keys with their status, workspace and expires_at, and changes a key's status to inactive or archived.
Exam context: An API for revoking and auditing keys rather than for creating them: you create API keys in the Claude Console, and the Admin API can only read, rename and change the status of existing keys. The offboarding trap also applies here. Removing a leaver archives their personal keys, while service account keys and legacy workspace keys keep working. So a production service belongs on a service account key.
See also: 7.4 Identity, Secrets, and Key Management