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 release note will retire it. Every keyed answer in this space 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 sit in the same class.
Exam context: Mitigations sit on the input path: a harmlessness screen 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 standing distractor.
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 touches your interface and the payload arrives through a channel your users already trust. The controls that hold sit on the tool surface and 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 have moved past wrapping everything in XML tags, and the placement rule is keyed. Its inverse is keyed 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 break out into an instruction context.
Exam context: The reason is the answer. Distractors offer delimiters that an attacker can close, or claim the encoding is about parsing convenience rather than about denying a break-out.
See also: 7.1 AI Application Security
Harmlessness Screen
A lightweight model call that classifies content before the main call runs, with the verdict constrained by structured outputs 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, 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 composes 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 tool surface 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 the reach.
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 tool surface, and the reason removal beats denial. Its adjacent distractor 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 that breaks an assumed-blanket ZDR posture. 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 holds 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, usually with wider access and longer retention, so redaction belongs at the write.
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 steer it has borrowed 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 keyed 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 door. 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. Retrieve-every-row-then-filter is a defect wearing a control's clothes: 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. 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. A log records after the fact and a dashboard alerts a human who may be asleep; both are worth having and neither is what the word is doing in an exam item.
See also: 7.2 Guardrails and Safe Deployment
Guardrail Layering
Running independent checks at different points so a payload that defeats one still meets another that cannot see the same 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 favourite 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" survives 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 attach. 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 amount of engineering discharges the obligation, and the distractor is there precisely because it is technically sound. The exam tests whether you notice that a scenario has landed 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: The availability instinct is inverted here. Proceeding converts the check into a suggestion that any dependency failure removes, and whoever can cause the failure gets the unguarded path for free. Retrying is fine; ending the retry chain at the model 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. The mode-level expression of failing closed, and the right shape for a headless agent with nobody to prompt.
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, then confirming both that Claude ignores them and that your screening and confirmation steps catch the rest.
Exam context: Part of the control set rather than operations beside it. 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 an under-instrumented one.
See also: 7.2 Guardrails and Safe Deployment
Hook
Your own code, wired 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 telling. It is a check the model does not participate in. That distinction is the whole sub-skill.
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 lives here. A PostToolUse hook that logs every removal is a real control for accountability and a fully-stated, plausible distractor, 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, and 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 keyed fact in the sub-skill. A gate 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 wins 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 September 2026, defer is honoured only in a non-interactive -p run, which exits with the call preserved 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: Over-claiming its reach fails in both directions. A hook deny binds 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 documented as being for decisions requiring judgement rather than deterministic rules, with agent hooks still experimental.
Exam context: Wiring a prompt or agent hook to a destructive path hands 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 reach, 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, alongside disableAllHooks, for which the answer is managed settings, since only those keep managed hooks running when a lower-scope file turns them off.
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 hygiene: 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 blunt about its rank: it limits the lifetime of a leaked credential and is no substitute for secret hygiene. Because it cannot be changed after creation, it is not something you can apply to a key already in the wild.
See also: 7.4 Identity, Secrets, and Key Management
Workload Identity Federation
The structural alternative to a distributed key: the workload exchanges an identity token from an IdP you already trust at POST /v1/oauth/token for a short-lived Claude token, which the SDK refreshes automatically. There is no sk-ant-api... string to mint, distribute or rotate.
Exam context: The documented caveat is the examinable half. The trust chain is only as strong as the identity provider's configuration, and a long-lived secret one hop upstream still undermines it. The federation rule carries the least-privilege decisions: its match conditions decide which workloads may mint a token, and its oauth_scope is a ceiling, 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 no-key-on-a-client rule: a genuine, attested installation of a registered iOS or macOS app can call the Claude API with no back end, on tokens scoped to your workspace that expire after one hour and authorise only Messages API calls.
Exam context: An attestation mechanism for native apps, not a licence to put a key in a web page. A browser bundle remains the wrong architecture, and the backend boundary is still what buys 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: kill the credential, 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 for good.
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 bracket: 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 surface, 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: A revocation and audit surface rather than a provisioning one: you create API keys in the Claude Console, and the Admin API can only read, rename and change the status of existing keys. It is also where the offboarding trap lives: 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