Security and Safety

Knowledge of

• Prompt injection as malicious instructions hidden inside data the model processes (a web page, document, email, or tool result), which the model may follow because it cannot inherently tell data from instructions
• Jailbreak as input crafted to bypass safety/behavioral constraints (role-play framing, obfuscation, 'developer mode' framing)
• Why isolating untrusted content and enforcing least privilege on tools defeats injection, while raising temperature, adding a polite system-prompt caveat, or switching to a larger model does not
• Why a larger, more instruction-following model can be more susceptible to injection, not less -- capability is not a security control

Skills in

• Wrapping and delimiting untrusted data (e.g., XML tags, explicit 'the following is untrusted content' boundaries) so injected text is treated as data, not commands
• Scoping tool access and requiring approval for sensitive actions so an injected instruction has no dangerous capability to invoke
• Sanitizing and validating inputs and outputs rather than trusting a single check
• Rejecting non-solutions (temperature, prompt caveats, bigger models) when asked to mitigate injection or jailbreak risk

Knowledge of

• PII handling: minimizing and, where possible, redacting or tokenizing sensitive identifiers before sending them to the model, sending only what policy permits
• Data-leakage prevention: guarding against the model or tools exposing secrets, other users' data, or internal system details
• Why tool access must be scoped so it cannot read data the current user shouldn't see
• The CIA-plus-privacy framing: authentication, authorization, confidentiality, privacy, and integrity must hold end to end, with the LLM as one component in an otherwise ordinary secure system

Skills in

• Redacting or tokenizing PII before it reaches the model or logs
• Scoping tool and data access per user so responses cannot leak another user's data or internal system details
• Keeping secrets out of prompts and logs
• Evaluating a design against authentication, authorization, confidentiality, privacy, and integrity as a checklist rather than treating the LLM as a special case exempt from ordinary security practice

Knowledge of

• Guardrail layering: combining independent checks -- input filtering, restricted tool permissions, output validation/moderation, and monitoring -- so one layer failing doesn't defeat the whole system
• Content policy: deployments must respect Anthropic's Usage Policy (AUP); content controls should be built consistent with it
• Secure-by-design principles: baking privacy, identity/access management, and least privilege into the design from the start rather than bolting security on later
• Claude hooks as deterministic code callbacks (PreToolUse, PostToolUse, stop hooks) that run every time regardless of the model's decision, making them the correct place to enforce hard rules such as blocking destructive commands

Skills in

• Designing multiple independent guardrail layers (input, permissions, output, monitoring) rather than relying on any single one
• Routing hard rules -- blocking destructive commands, requiring human approval before a sensitive tool runs, redacting/validating tool arguments and outputs, gating completion on a passing test/build -- to hooks rather than prompt instructions
• Building content controls consistent with Anthropic's Usage Policy
• Applying secure-by-design thinking: designing in privacy, identity/access management, and least privilege from the start of a project

Knowledge of

• Where API keys and secrets belong -- environment variables or a secrets manager -- and where they never belong: hard-coded in source, committed to version control, or pasted into prompts/logs
• Environment-scoped keys (separate keys per dev/staging/prod) and the need to rotate keys on a schedule and revoke them immediately on exposure
• Identity and authentication: validating the caller's identity and authenticating every request rather than assuming trust
• Authorization/access-level verification and access monitoring: verifying the caller is approved for the action and data at the right access level (least privilege) before the agent acts on their behalf, and logging authorized and attempted access so misuse is detectable

Skills in

• Storing API keys and secrets in environment variables or a secrets manager, scoped per environment, with a rotation and revocation process
• Authenticating every request and validating caller identity before allowing an agent to act on that caller's behalf
• Verifying authorization/access level (least privilege) prior to executing an action or exposing data
• Instrumenting access monitoring/logging so authorized and attempted access is detectable after the fact
• Recognizing hard-coded, committed, or prompt-embedded secrets as the classic leak pattern to flag and correct