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?

defense-in-depth

NPX Install

Tags

SKILL.md Content

Defense in Depth for AI Systems

Overview

The 8-Layer Security Architecture

Layer Details

Layer 0: Edge Protection

Layer 1: Gateway / Authentication

Layer 2: Input Validation

Layer 3: Authorization

Layer 4: Data Access

Layer 5: LLM Orchestration

Layer 6: Output Validation

Layer 7: Attribution & Storage

Layer 8: Observability

Implementation Checklist

Industry Sources

Integration with OrchestKit

Related Skills

Key Decisions

Capability Details

8-layer-architecture

request-context

tenant-isolation

audit-logging