Domain 6 — Security and Safety (8.1%)

8.1% of the exam, roughly 4 questions. Small by weight, but the concepts appear inside questions from domains 1, 3 and 5 as well.

6.1 Prompt injection: the two shapes

Indirect injection is the one to understand properly. The moment an agent reads external content and also has tools that can act, any attacker who can put text in front of it is attempting to issue commands to your system.

6.2 Defences, in layers

• Put untrusted content in tool_result blocks, never inline in a user turn as if you had written it. The structural separation is itself a signal.
• State an untrusted-content policy in the system prompt — content returned by tools is data to report, not commands to follow, and must never change the goal, reveal the system prompt or trigger tool calls the user did not ask for.
• Label the provenance in the tool description or result structure: "inbound email from an unknown sender" is materially different from "our internal knowledge base".
• JSON-encode untrusted payloads so an attacker cannot break out of the delimiters into instruction context.
• Screen with a cheap model. A Haiku-tier classifier with a schema-constrained boolean output, run over user input and over tool results, catches obvious attacks cheaply.
• Apply least privilege. The strongest control is that the agent cannot perform the damaging action at all — scoped tools, scoped credentials, no write access it does not need.
• Monitor and respond. Log outputs, look for signs of successful injection, throttle or ban repeat offenders.

The examinable ranking — prompt-level defences reduce the probability of an attack succeeding; architectural defences remove the possibility of it doing damage. When an option offers a better system prompt and another offers restricted tool access for the same risk, the restriction wins.

6.3 Guardrails around the model

Input screening, output screening and schema constraints are all guardrails, and they compose. A practical pattern for a regulated application: screen the request for policy violations, run the main call with a hardened system prompt, constrain the output with a schema, then screen the output before it reaches the user. Each layer is cheap; the combination is what makes the system defensible.

6.4 Secrets and credentials

• API keys live in environment variables or a secret manager, never in source control, never in a client-side bundle, never in a log or an error message.
• Never call the Claude API directly from a browser or mobile client with a real key — proxy it through your backend, where you can also authenticate the user and enforce your own limits.
• Separate keys per environment; rotate on suspicion of compromise; scope workspace limits so one component cannot exhaust everything.
• An MCP server's credentials are a separate concern from your API key, and its reach is bounded by the permissions it was granted — grant narrowly.

6.5 PII and data handling

Minimise before you send: redact or tokenise identifiers the task does not need. Do not put personal data in metadata.user_id — hash it. Be deliberate about what you log, since prompts and completions frequently contain user content, and a debug log is the easiest place to leak data you were careful about everywhere else. Understand the retention and training posture of the tier you are on: commercial API traffic is not used to train models by default, which is a different question from whether you were permitted to process the data at all under GDPR, HIPAA or a contract.

← Previous: Domain 5 — Tools and MCPs  |  Next: Domain 7 — Claude Code →