defense-in-depth

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.

@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.

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.

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?