home / skills / mamba-mental / agent-skill-manager / defense-in-depth

defense-in-depth skill

/skills/debugging/defense-in-depth

This skill enforces defense-in-depth by validating data at every layer to prevent bugs and ensure reliable system behavior.

npx playbooks add skill mamba-mental/agent-skill-manager --skill defense-in-depth

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.8 KB
---
name: Defense-in-Depth Validation
description: Validate at every layer data passes through to make bugs impossible
when_to_use: when invalid data causes failures deep in execution, requiring validation at multiple system layers
version: 1.1.0
languages: all
---

# Defense-in-Depth Validation

## Overview

When you fix a bug caused by invalid data, adding validation at one place feels sufficient. But that single check can be bypassed by different code paths, refactoring, or mocks.

**Core principle:** Validate at EVERY layer data passes through. Make the bug structurally impossible.

## Why Multiple Layers

Single validation: "We fixed the bug"
Multiple layers: "We made the bug impossible"

Different layers catch different cases:
- Entry validation catches most bugs
- Business logic catches edge cases
- Environment guards prevent context-specific dangers
- Debug logging helps when other layers fail

## The Four Layers

### Layer 1: Entry Point Validation
**Purpose:** Reject obviously invalid input at API boundary

```typescript
function createProject(name: string, workingDirectory: string) {
  if (!workingDirectory || workingDirectory.trim() === '') {
    throw new Error('workingDirectory cannot be empty');
  }
  if (!existsSync(workingDirectory)) {
    throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
  }
  if (!statSync(workingDirectory).isDirectory()) {
    throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
  }
  // ... proceed
}
```

### Layer 2: Business Logic Validation
**Purpose:** Ensure data makes sense for this operation

```typescript
function initializeWorkspace(projectDir: string, sessionId: string) {
  if (!projectDir) {
    throw new Error('projectDir required for workspace initialization');
  }
  // ... proceed
}
```

### Layer 3: Environment Guards
**Purpose:** Prevent dangerous operations in specific contexts

```typescript
async function gitInit(directory: string) {
  // In tests, refuse git init outside temp directories
  if (process.env.NODE_ENV === 'test') {
    const normalized = normalize(resolve(directory));
    const tmpDir = normalize(resolve(tmpdir()));

    if (!normalized.startsWith(tmpDir)) {
      throw new Error(
        `Refusing git init outside temp dir during tests: ${directory}`
      );
    }
  }
  // ... proceed
}
```

### Layer 4: Debug Instrumentation
**Purpose:** Capture context for forensics

```typescript
async function gitInit(directory: string) {
  const stack = new Error().stack;
  logger.debug('About to git init', {
    directory,
    cwd: process.cwd(),
    stack,
  });
  // ... proceed
}
```

## Applying the Pattern

When you find a bug:

1. **Trace the data flow** - Where does bad value originate? Where used?
2. **Map all checkpoints** - List every point data passes through
3. **Add validation at each layer** - Entry, business, environment, debug
4. **Test each layer** - Try to bypass layer 1, verify layer 2 catches it

## Example from Session

Bug: Empty `projectDir` caused `git init` in source code

**Data flow:**
1. Test setup → empty string
2. `Project.create(name, '')`
3. `WorkspaceManager.createWorkspace('')`
4. `git init` runs in `process.cwd()`

**Four layers added:**
- Layer 1: `Project.create()` validates not empty/exists/writable
- Layer 2: `WorkspaceManager` validates projectDir not empty
- Layer 3: `WorktreeManager` refuses git init outside tmpdir in tests
- Layer 4: Stack trace logging before git init

**Result:** All 1847 tests passed, bug impossible to reproduce

## Key Insight

All four layers were necessary. During testing, each layer caught bugs the others missed:
- Different code paths bypassed entry validation
- Mocks bypassed business logic checks
- Edge cases on different platforms needed environment guards
- Debug logging identified structural misuse

**Don't stop at one validation point.** Add checks at every layer.

Overview

This skill implements a Defense-in-Depth Validation strategy that adds validation checks at every layer data passes through to make bugs structurally impossible. It integrates entry-point validation, business logic checks, environment guards, and debug instrumentation to catch invalid state from multiple angles. The goal is to stop invalid inputs early and ensure later layers still protect against bypasses, mocks, and refactors.

How this skill works

The skill instruments key code paths with four validation layers: API/entry-point checks to reject obviously invalid input; business-logic assertions to ensure data is sensible for the operation; environment guards to prevent dangerous context-specific actions; and debug instrumentation to capture context when something unexpected occurs. When a bug is found, the skill guides tracing data flow, mapping checkpoints, and adding or tightening validations at each layer, then verifies by testing bypass attempts.

When to use it

  • When an input validation bug recurs after a single fix
  • Before performing filesystem, network, or process-changing actions
  • In tests to prevent operations that modify real resources
  • When refactoring or adding alternate code paths that may bypass checks
  • During incident forensics to capture context and repro data

Best practices

  • Validate at the API boundary but never rely on it alone
  • Add focused business-logic checks for operation-specific invariants
  • Enforce environment guards in test and CI to avoid side effects
  • Attach lightweight debug context (stack, cwd, inputs) around risky ops
  • Write tests that attempt to bypass each layer and verify remaining guards

Example use cases

  • Reject empty or non-existent working directories at the service boundary
  • Assert required workspace parameters inside workspace initialization routines
  • Refuse git init in tests unless the directory is inside a temporary path
  • Log stack and process context before running external commands for forensic traces
  • Harden CI and integration tests by layering checks so mocks cannot trigger real side effects

FAQ

Won't multiple validations duplicate work and slow the system?

Checks should be inexpensive and focused: entry checks reject obvious invalid input, business checks verify operation-specific invariants, and environment guards are conditional. Properly designed checks add negligible overhead but dramatically reduce risk.

How do I test that a layer actually prevents a bug?

Create targeted tests that intentionally bypass earlier layers (mocks, direct calls) and confirm the next layer still rejects the bad data. Include test cases for environment-specific guards and record debug logs for verification.