Building Sandboxed Runtime Execution for AI Agents

Large Language Models (LLMs) have evolved from simple conversational interfaces to fully agentic systems capable of generating and executing code, running shell commands, and managing local database operations. While these abilities represent a massive paradigm shift in engineering productivity, they introduce significant security liabilities. If an agent scans a public webpage, parses support emails, or reads a customer-submitted PDF, it can easily ingest a prompt injection attack. A prompt injection could instruct the agent to run destructive shell commands, scrape environment files, or connect to rogue external endpoints.

To address these vulnerabilities, remii forces every command, script execution, and filesystem interaction to occur within isolated cloud container sandboxes. These environments are completely decoupled from physical host servers, internal networks, and sensitive corporate data silos.

### The Problem with Local Execution

Many early agent frameworks relied on executing Python or bash scripts directly on the user's local machine or inside the main backend web container. This architecture violates the principle of least privilege. An LLM cannot guarantee that the code it generates is safe. Hallucinations or injected prompts can result in commands like `rm -rf /` or scripts that silently exfiltrate `~/.aws/credentials`.

Even in containerized environments like Docker, simply running code inside the same container that hosts the agent logic allows the LLM to access the agent's API keys, database connection strings, and system memory.

### Isolated Namespace Architecture

When remii initiates a task (e.g., executing a Python data analysis script), our task orchestrator makes an API call to spin up a lightweight, ephemeral Linux microVM. This microVM is configured with strict network and process namespaces:

- **No Host Network Access**: The sandbox can make outgoing internet calls to fetch APIs or scrape public domains (as necessary for web research tasks), but it is placed on an isolated Virtual Private Cloud (VPC) subnet. It cannot access the local hosting subnets or any internal microservices. - **Process Isolation**: The container uses Linux namespaces (pid, net, ipc, mnt, uts) to prevent scripts from seeing or affecting host processes. An agent running a malicious script cannot view the orchestration daemon running the microVM. - **Ephemeral Storage**: Files created or modified during the execution exist only within the container memory and a temporary scratch disk. Upon completion of the execution queue, the container is destroyed, leaving no persistent remnants behind. Any state changes are strictly passed back to the agent via stdout/stderr streams.

### Constrained System Privileges and Limits

Running code inside standard root containers is a common anti-pattern. If a script executes as root, it can modify container configurations, install kernel modules, or attempt container escape techniques. remii sandbox containers run under a non-privileged system user account (e.g., 'agentuser') with strict resource limitations enforced by cgroups:

1. **CPU and Memory Limits**: Each sandbox is capped at 0.5 vCPU and 512MB RAM. This prevents CPU exhaust attacks (like crypto miners) or memory-leak loops from affecting the cluster's stability. 2. **Strict Hard Timeout Limits**: Any script execution that takes more than 120 seconds is forcibly terminated by a parent daemon to avoid hung processes and infinite `while(true)` loops. 3. **Read-Only Root Filesystem**: The root filesystem is mounted as read-only. The agent can only write to specific temporary directories like `/tmp/workspace`. 4. **Syscall Filtering**: We use seccomp-bpf profiles to block dangerous system calls. The sandbox cannot execute `ptrace`, `mount`, or manipulate network interfaces.

### Network Egress Filtering

While the sandbox needs internet access to perform useful work, we implement egress filtering to prevent data exfiltration. Using eBPF (Extended Berkeley Packet Filter) rules at the network layer, we monitor all outgoing traffic from the sandboxes. - **Domain Whitelisting**: For specific enterprise tasks, the sandbox is restricted to communicating only with approved API domains (e.g., api.github.com, slack.com). - **Traffic Anomalies**: If a sandbox attempts to open thousands of connections or stream large volumes of data to an unknown IP address, the network layer drops the packets and alerts the orchestrator to terminate the session.

### Secure File Transfer

Agents often need to analyze files or generate reports. How do we pass files securely between the host and the sandbox? remii uses a brokered storage approach. The host orchestrator uploads the necessary context files to an encrypted, temporary S3 bucket with a presigned URL that expires in 5 minutes. The sandbox downloads the files using this URL. When the execution finishes, the sandbox uploads the results (like a generated PDF) back to a separate output bucket. The sandbox never mounts the host filesystem directly.

### Conclusion

By enforcing isolated, low-privilege, and short-lived execution sandboxes with strict network boundaries, we ensure that the AI worker remains safe to use. If an attacker succeeds in injecting a malicious command, the damage is restricted to a disposable sandbox container that is destroyed milliseconds later. As AI agents become more deeply integrated into our workflows, building these secure-by-default execution environments is not just a best practice—it is an absolute necessity for enterprise adoption.