# Defense In Depth

> Skill — Defense in Depth

- Skill: `sairam0424/defense-in-depth` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sairam0424/defense-in-depth`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sairam0424/defense-in-depth/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sairam0424 (https://skillmd.com/u/sairam0424)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sairam0424/defense-in-depth

---


# Skill — Defense in Depth

## When this skill activates

Any task that introduces or modifies code handling external input, enforcing
business rules, managing environment-specific behavior, or adding observability.
Activate whenever you are building anything that crosses a trust boundary or
touches validation logic at any layer of the stack.

## Mandatory actions when this skill is active

Four independent validation layers must be applied. Each layer is autonomous:
failure or absence in one layer does NOT exempt the others.

### Layer 1 — Entry Point Validation

Apply at the API boundary (route handler, CLI argument parser, event handler):

- Schema validation using a strict schema library (Zod, Joi, Pydantic, etc.)
- Type coercion with explicit rules (string-to-number only where defined)
- Reject invalid input immediately with a 400-level response
- Never pass unvalidated input deeper into the system
- Strip unknown fields; never allow arbitrary pass-through

### Layer 2 — Business Logic Guards

Apply inside domain/service layer functions:

- Assert domain invariants (e.g., balance >= 0, state transitions are valid)
- State machine guards: verify current state allows the requested transition
- Authorization assertions: re-check permissions at the service boundary
- Fail loudly with descriptive errors when invariants are violated
- Never rely solely on entry point validation; business logic must self-protect

### Layer 3 — Environment Guards

Apply environment-specific behavior through configuration, not conditionals:

- **Production**: strict mode, no debug endpoints exposed, minimal error detail
  in responses, all logging structured and shipped to aggregator
- **Staging**: production-like but with extended logging and feature flags
- **Test**: relaxed logging, verbose error output, mock services allowed
- Guard debug endpoints behind environment checks (never reachable in prod)
- Validate required environment variables at startup; crash early if missing

### Layer 4 — Debug Instrumentation

Apply observability that aids debugging without compromising security:

- Structured logging with consistent fields (timestamp, traceId, userId, action)
- Trace IDs propagated through all layers (generate at entry point, pass down)
- Development assertions (enabled in test/dev, compiled out or disabled in prod)
- Never log secrets, tokens, passwords, or full request bodies in production
- Include enough context to reproduce issues from logs alone

## Independence principle

Each layer must function correctly even if the others are absent. This means:

- Business logic must not assume entry point already validated
- Environment guards must not assume instrumentation is active
- Instrumentation must not assume any specific validation has occurred
- Entry point validation must not assume business logic will catch overflows

## Self-check before task completion

Before marking a task done when this skill was active:

- [ ] Did I validate at the entry point (schema, types, rejection of invalid)?
- [ ] Did I add business logic guards (invariants, state checks, auth assertions)?
- [ ] Did I implement environment guards (prod strict, test relaxed, no debug in prod)?
- [ ] Did I include debug instrumentation (structured logs, trace IDs, assertions)?
- [ ] Are all four layers independent (no layer relies on another for correctness)?
- [ ] Did I verify that secrets are never exposed in any logging layer?