Layered Guardrails & Defense in Depth
CoreDesign layered guardrails and safety controls for production Claude systems · Difficulty 2/5
Explanation
Making a Claude system safe in production means engineering safety into the system around the model with layered, defense-in-depth controls -- not delegating it to a single prompt. No individual layer is assumed to be perfect; the layers are independent so that one failure does not become catastrophic.
The Five Layers
| Layer | Control |
|---|---|
| Input | Validate and sanitize input; separate trusted instructions from untrusted data; classify/filter disallowed requests |
| Permissions | Least privilege on tools and data; scope what the agent can do |
| Deterministic controls | Hooks and permission rules that fire in code -- e.g., a PreToolUse hook that blocks a destructive action every time, regardless of what the model "decides" |
| Output | Validate and constrain output; check for policy violations and data leakage before it leaves |
| Monitoring | Log and alert on anomalous or unsafe behavior |
Why Layering Matters
Each layer covers a different failure surface. Input filtering can miss a novel injection pattern; if it does, least-privilege permissions limit what a compromised turn can actually do; if a policy-violating tool call still gets attempted, a deterministic hook blocks it outright; if something slips through anyway, output validation and monitoring catch it before or after the fact. Removing any one layer does not collapse the whole system -- that is the point of defense in depth.
Common exam traps
- "Put the safety rule in the system prompt." Prompts guide behavior probabilistically; for a hard limit, use a deterministic hook/permission control instead.
- Relying on one layer. Guardrails are layered -- input filtering *and* least privilege *and* output validation *and* monitoring, not any single one of these alone.
Key Takeaways
- Guardrails are layered: input, permissions, deterministic controls, output, and monitoring
- No single layer is assumed to be perfect -- layers are independent so one failure isn't catastrophic
- A PreToolUse hook is a deterministic control that blocks a destructive action every time
- Exam trap: a single strong system prompt is not a substitute for layered controls
Glossary Terms
An Agent SDK lifecycle hook that intercepts tool calls before execution. Can inspect, modify, or block the call. Used for access control, parameter sanitization, rate limiting, and audit logging. Runs synchronously before the tool executes.
Shell scripts or commands configured in .claude/settings.json that run at defined lifecycle points: PreToolUse (before tool execution), PostToolUse (after tool execution), Stop (before ending), SubagentStop (when subagent finishes). Used for code quality gates, notifications, logging, and safety checks.
A security principle applied to agent tool design: give each agent and subagent only the minimum tools required to complete its specific task. Reduces blast radius if an agent is compromised or makes an error. Implemented via AgentDefinition tool lists and skill allowed-tools.
Related Concepts