Sandbox Hardening

# Sandbox Hardening

Part of [Agent Skills™](https://github.com/itallstartedwithaidea/agent-skills) by [googleadsagent.ai™](https://googleadsagent.ai)

## Description

Sandbox Hardening isolates agent execution environments using container sandboxing, permission boundaries, resource limits, and network segmentation. The agent configures and validates sandboxes that prevent AI-generated code from accessing unauthorized resources, consuming unbounded compute, or affecting the host system.

An AI agent with unrestricted shell access is a security liability. Without sandboxing, a prompt injection or hallucinated command could delete files, exfiltrate data, install malware, or consume unbounded resources. Sandbox Hardening applies the principle of least privilege: the agent receives only the permissions it needs, in an isolated environment with strict resource limits and monitored network access.

This skill covers three isolation levels: process-level sandboxing (seccomp, AppArmor), container-level isolation (Docker with restricted capabilities), and VM-level isolation (microVMs like Firecracker). The appropriate level depends on the trust boundary: internal development tools use process-level, multi-tenant platforms use container-level, and untrusted code execution requires VM-level isolation.

## Use When

- Running AI-generated code in production or shared environments
- Configuring agent execution environments with least-privilege access
- Deploying multi-tenant AI platforms where users share infrastructure
- Executing untrusted code from user inputs or AI outputs
- Implementing compliance requirements for isolated execution
- Building sandboxed development environments for agents

## How It Works

```mermaid
graph TD
    A[Agent Task] --> B{Trust Level Assessment}
    B -->|Internal Dev| C[Process Sandbox]
    B -->|Multi-Tenant| D[Container Sandbox]
    B -->|Untrusted Code| E[VM Sandbox]
    C --> F[seccomp + AppArmor Profile]
    D --> G[Docker: No Root + Read-Only FS]
    E --> H[Firecracker microVM]
    F --> I[Resource Limits: CPU, Memory, Disk]
    G --> I
    H --> I
    I --> J[Network Policy: Allowlist Only]
    J --> K[Filesystem: Scoped Mount]
    K --> L[Monitoring: Syscall Audit]
    L --> M[Execution within Sandbox]
```

The sandbox is configured before the agent executes any code. Trust level determines the isolation technology, and all levels apply resource limits, network restrictions, and filesystem scoping.

## Implementation

```dockerfile
# Container sandbox: minimal, non-root, read-only
FROM node:20-slim AS sandbox
RUN groupadd -r agent && useradd -r -g agent -d /workspace agent
WORKDIR /workspace
COPY --chown=agent:agent . .
USER agent
```

```yaml
# docker-compose sandbox configuration
services:
  agent-sandbox:
    build: .
    read_only: true
    tmpfs:
      - /tmp:size=100M,noexec
    security_opt:
      - no-new-privileges:true
      - seccomp:seccomp-profile.json
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 512M
          pids: 100
        reservations:
          cpus: "0.5"
          memory: 128M
    networks:
      - sandbox-net
    dns:
      - 1.1.1.1

networks:
  sandbox-net:
    driver: bridge
    internal: false
```

```python
import resource
import os

class ProcessSandbox:
    """Process-level sandboxing for single-tenant development."""

    @staticmethod
    def apply_limits(
        max_memory_mb: int = 256,
        max_cpu_seconds: int = 30,
        max_file_size_mb: int = 10,
        max_open_files: int = 64,
        max_processes: int = 10,
    ):
        mb = 1024 * 1024
        resource.setrlimit(resource.RLIMIT_AS, (max_memory_mb * mb, max_memory_mb * mb))
        resource.setrl