defense-in-depth

---
name: defense-in-depth
description: Use when building secure AI pipelines or hardening LLM integrations. Defense-in-depth implements 8 validation layers from edge to storage with no single point of failure.
license: MIT
---

# Defense in Depth for AI Systems

## Overview

Defense in depth applies multiple security layers so that if one fails, others still protect the system. For AI applications, this means validating at every boundary: edge, gateway, input, authorization, data, LLM, output, and observability.

**Core Principle:** No single security control should be the only thing protecting sensitive operations.

## The 8-Layer Security Architecture

```
┌─────────────────────────────────────────────────────────────────────────┐
│  Layer 0: EDGE           │  WAF, Rate Limiting, DDoS, Bot Detection    │
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 1: GATEWAY        │  JWT Verify, Extract Claims, Build Context  │
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 2: INPUT          │  Schema Validation, PII Detection, Injection│
│                          │  + Tavily Prompt Injection Firewall (opt.)  │
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 3: AUTHORIZATION  │  RBAC/ABAC, Tenant Check, Resource Access   │
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 4: DATA ACCESS    │  Parameterized Queries, Tenant Filter       │
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 5: LLM            │  Prompt Building (no IDs), Context Separation│
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 6: OUTPUT         │  Schema Validation, Guardrails, Hallucination│
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 7: STORAGE        │  Attribution, Audit Trail, Encryption       │
├─────────────────────────────────────────────────────────────────────────┤
│  Layer 8: OBSERVABILITY  │  Logging (sanitized), Tracing, Metrics      │
└─────────────────────────────────────────────────────────────────────────┘
```

## Layer Details

### Layer 0: Edge Protection

**Purpose:** Stop attacks before they reach your application.

- WAF rules for OWASP Top 10
- Rate limiting per user/IP
- DDoS protection
- Bot detection
- Geo-blocking if required

### Layer 1: Gateway / Authentication

**Purpose:** Verify identity and build request context.

```python
@dataclass(frozen=True)
class RequestContext:
    """Immutable context that flows through the system"""
    # Identity
    user_id: UUID
    tenant_id: UUID
    session_id: str
    permissions: frozenset[str]

    # Tracing
    request_id: str
    trace_id: str

    # Metadata
    timestamp: datetime
    client_ip: str
```

### Layer 2: Input Validation

**Purpose:** Reject bad input early.

- **Schema validation:** Pydantic/Zod for structure
- **Content validation:** PII detection, malware scan
- **Injection defense:** SQL, XSS, prompt injection patterns
- **External scanning (optional):** Tavily prompt injection firewall for web-sourced content — pre-filters RAG inputs before they reach the LLM layer

### Layer 3: Authorization

**Purpose:** Verify permission for the specific action and resource.

```python
async def authorize(ctx: RequestContext, action: str, resource: Resource) -> bool:
    # 1. Check permission exists
    if action not in ctx.permissions:
        raise Forbidden("Missing permission")

    # 2. Check tenant ownership
    if resource.tenant_id != ctx.tenant_id:
        raise Forbidden("Cross-tenant access denied")

    # 3. Check resource-level access
    if not await check_resource_access(ctx.user_id, resource):
        raise Forbidden("No access to resource")

    return True
```

### Layer 4: Data Access

**Purpose:** Ensure all queries are tenant-scoped.

```python
class TenantScopedRepository:
    def __init__(self, ctx: RequestContext):
        self.ctx = ctx
        self._base_filter = {"tenant_id": ctx.tenant_id}

    async def find(self, query: dict) -> list[Model]:
        # ALWAYS merge tenant filter
        safe_query = {**self._base_filter, **query}
        return await self.db.find(safe_query)
```

### Layer 5: LLM Orchestration

**Purpose:** Build prompts with content only, no identifiers.

- Identifiers flow AROUND the LLM, not THROUGH it
- Prompts contain only content text
- No user_id, tenant_id, document_id in prompt text
- See `llm-safety-patterns` skill for details

### Layer 6: Output Validation

**Purpose:** Validate LLM output before use.

- Schema validation (JSON structure)
- Content guardrails (toxicity, PII generation)
- Hallucination detection (grounding check)
- Code injection prevention

### Layer 7: Attribution & Storage

**Purpose:** Reattach context and store with proper attribution.

- Attribution is deterministic, not LLM-generated
- Context from Layer 1 is attached to results
- Source references from Layer 4 are attached
- Audit trail recorded

### Layer 8: Observability

**Purpose:** Monitor without leaking sensitive data.

- Structured logging with sanitization
- Distributed tracing (Langfuse)
- Metrics (latency, errors, costs)
- Alerts for anomalies

## Implementation Checklist

Before deploying any AI feature, verify:

- [ ] Layer 0: Rate limiting configured
- [ ] Layer 1: JWT validation active, RequestContext created
- [ ] Layer 2: Pydantic models validate all input
- [ ] Layer 3: Authorization check on every endpoint
- [ ] Layer 4: All queries include tenant_id filter
- [ ] Layer 5: No IDs in LLM prompts (run audit)
- [ ] Layer 6: Output schema validation active
- [ ] Layer 7: Attribution uses context, not LLM output
- [ ] Layer 8: Logging sanitized, tracing enabled

## Industry Sources

| Pattern | Source | Application |
|---------|--------|-------------|
| Defense in Depth | NIST | Multiple validation layers |
| Zero Trust | Google BeyondCorp | Every request verified |
| Least Privilege | AWS IAM | Minimal permissions |
| Complete Mediation | Saltzer & Schroeder | Every access checked |

## Integration with OrchestKit

This skill integrates with:
- `llm-safety-patterns` - Layer 5 details
- `security-checklist` - OWASP validations
- `observability-monitoring` - Layer 8 details

---

## Related Skills

- `owasp-top-10` - OWASP Top 10 vulnerabilities that Layer 0-2 defend against
- `auth-patterns` - Detailed authentication/authorization for Layers 1 and 3
- `input-validation` - Input validation and sanitization patterns for Layer 2
- `security-scanning` - Automated security scanning for ongoing defense validation

## Key Decisions

| Decision | Choice | Rationale |
|----------|--------|-----------|
| Context object | Immutable dataclass | Prevents accidental mutation, ensures consistent identity flow |
| Tenant isolation | Query-level filtering | Defense in depth - application layer + database constraints |
| LLM prompt security | No identifiers in prompts | IDs flow around LLM, not through it - prevents prompt injection leaks |
| Audit logging | Sanitized structured logs | Compliance requirements while preventing PII exposure |

---

**Version:** 1.0.0 (December 2025)

## Capability Details

### 8-layer-architecture
**Keywords:** defense in depth, security layers, validation layers, multi-layer
**Solves:**
- How do I secure my AI application end-to-end?
- What validation layers do I need?
- How do I implement defense in depth?

### request-context
**Keywords:** request context, immutable context, context object, user context
**Solves:**
- How do I pass user identity through the system?
- How do I create an immutable request context?
- What should be in the request context?

### tenant-isolation
**Keywords:** multi-tenant, tenant isolation, tenant filter, cross-tenant
**Solves:**
- How do I ensure tenant isolation?
- How do I prevent cross-tenant data access?
- How do I filter queries by tenant?

### audit-logging
**Keywords:** audit log, audit trail, logging, compliance
**Solves:**
- What should I log for compliance?
- How do I create audit trails?
- How do I log without leaking PII?