Security Model

Threat Model

Assets

• User data and prompts
• LLM API keys and credentials
• Generated code and its execution
• Conversation history
• System infrastructure

Threat Actors

1. Malicious Users: Attempting to escape sandbox, access other users’ data
2. Compromised LLM: Generating malicious code or exfiltrating data
3. External Attackers: Exploiting API vulnerabilities, DoS attacks
4. Insider Threats: Privileged access abuse

Threat Scenarios

Defense in Depth

Layer 1: Network Security

• TLS 1.3 for all communications
• mTLS for internal service communication
• Network segmentation and VPC isolation

Layer 2: API Security

• Authentication required for all endpoints
• Rate limiting per user/API key
• Request size limits and timeout enforcement
• Schema validation for all inputs

Layer 3: Execution Security

• Container-based isolation: gVisor or similar for system-level isolation
• Capability dropping: Remove all unnecessary Linux capabilities
• Read-only root filesystem: Prevent persistence in containers
• No privilege escalation: Explicitly disable SETUID/SUDO

Layer 4: Application Security

• Input sanitization using allowlists
• Output encoding to prevent injection
• Prepared statements for database queries
• Constant-time comparison for secrets

Layer 5: Data Security

• Encryption at rest for sensitive data
• Encryption in transit (TLS 1.3)
• Secrets management via external vault (HashiCorp Vault, AWS Secrets Manager)
• Automatic secret rotation

Sandbox Design

Option A: Container Runtime (gVisor)

┌─────────────────────────────────────┐
│          gVisor Sandbox             │
│  ┌───────────────────────────────┐  │
│  │     User Application          │  │
│  │   (untrusted code runs here)  │  │
│  └───────────────────────────────┘  │
│  ┌───────────────────────────────┐  │
│  │    Sentry (seccomp-bpf)       │  │
│  │    Intercepts syscalls        │  │
│  └───────────────────────────────┘  │
│  ┌───────────────────────────────┐  │
│  │    Gofer (9P file server)     │  │
│  │    Filesystem isolation       │  │
│  └───────────────────────────────┘  │
└─────────────────────────────────────┘

Pros:

• Strong isolation with user-space kernel
• Compatible with existing container tooling
• Can run any Linux binary

Cons:

• Higher overhead than native
• Requires privileged daemon

Option B: WebAssembly (Wasmtime)

┌─────────────────────────────────────┐
│        Wasmtime Runtime             │
│  ┌───────────────────────────────┐  │
│  │     WASM Module               │  │
│  │   (compiled guest code)       │  │
│  │                               │  │
│  │   • Linear memory isolation   │  │
│  │   • Capability-based security │  │
│  │   • No direct syscalls        │  │
│  └───────────────────────────────┘  │
└─────────────────────────────────────┘

Pros:

• Near-native performance
• True capability-based security
• Smaller attack surface
• Fast startup

Cons:

• Requires code to be compiled to WASM
• Limited standard library support
• Language ecosystem constraints

Recommendation

Hybrid approach:

• Use WASM for user-defined tools (fast, safe)
• Use gVisor containers for general code execution (flexibility)
• Allow operator to configure which to use per tool

Audit Logging

Log Requirements

All logs must include:

• Timestamp (UTC, nanosecond precision)
• Request ID (for correlation)
• User/API key identifier (hashed)
• Action type
• Resource accessed
• Success/failure status
• Source IP (if applicable)

Log Categories

#![allow(unused)]
fn main() {
enum AuditEvent {
    Authentication { method: String, success: bool },
    PromptSubmitted { model: String, tokens_in: u32 },
    ToolExecuted { 
        tool_name: String, 
        sandbox_type: SandboxType,
        execution_time_ms: u64,
        success: bool 
    },
    CodeGenerated { language: String, size_bytes: usize },
    ResponseReturned { tokens_out: u32 },
    Error { error_type: String, message: String },
}
}

Log Storage

• Structured logging (JSON)
• Append-only, tamper-evident storage
• Separate from application data
• Retention policy: 90 days hot, 1 year cold

Secrets Management

Principles

1. Never log secrets
2. Never pass to sandbox
3. Rotate automatically
4. Access audit trail

Implementation

• Integration with HashiCorp Vault or cloud-native secret managers
• Short-lived tokens (max 1 hour)
• Automatic injection into LLM requests (not sandboxed code)
• Secrets never stored in conversation history

Security Checklist

Before production deployment:

• Penetration testing completed
• Security audit of sandbox escape vectors
• Dependency vulnerability scan (cargo audit)
• Secrets rotation procedures documented
• Incident response plan in place
• Security monitoring alerts configured
• Data retention policies implemented
• GDPR/privacy compliance review