---
name: defense-in-depth
description: Defense in depth: add layered validation/guardrails across a data path (auth, validation, invariants, rate limits, idempotency). Triggers: defense in depth, guardrails, harden, 分层校验, 多道防线, 安全加固.
---

# Defense in Depth（分层校验 / 多道防线）

## When to Use
- Auth/data path changes (permissions, roles, ownership checks)
- Risky inputs (user input, external APIs, files, SQL, commands)
- Operations that must be safe under retries/concurrency
- Incidents where we fixed symptoms but not the root class of bugs

## Inputs（required）
- Data path: entrypoints → core logic → side effects (DB/files/network)
- Threat model: what could go wrong? who can trigger it?
- Constraints: latency budgets, backward compatibility, rollout plan
- Verification: how to prove guardrails work (tests, logs, metrics)

## Procedure（default）
1. **Map the Path**
   - Identify trust boundaries and validation points
   - List invariants that must always hold

2. **Layer Guardrails**
   - AuthN/AuthZ checks at boundaries (least privilege)
   - Input validation + normalization (reject early)
   - Business invariants (defensive checks with clear errors)
   - Idempotency / dedup / retry-safety
   - Rate limits / resource bounds (timeouts, size limits)
   - Observability (structured logs, metrics, alerts)

3. **Failure Modes**
   - Define what happens on invalid input, partial failures, timeouts
   - Ensure errors are actionable and do not leak sensitive info

4. **Verify**
   - Add tests for each guardrail and key edge cases
   - Propose minimal manual verification steps if tests are missing

## Output Contract（stable）
- Path map: trust boundaries + invariants
- Guardrails: what to add at each layer (with rationale)
- Risks: what remains and why
- Verification: exact tests/commands and expected signals

## Guardrails
- Avoid “one big check”; prefer multiple small, well-scoped checks
- Prefer explicit errors over silent fallback
- Security checks must not be bypassable via alternate code paths