Skip to main content

​
Why isolation matters

Agents execute arbitrary code, install packages, read files, and make HTTP requests. Without proper isolation, one session can:
  • Access credentials or data from another user’s session
  • Consume resources that starve other agents
  • Leave behind state that affects the next session
  • Compromise the host system or other workloads
Traditional containers share a kernel. If an agent finds a kernel exploit, it can escape and access other containers on the same host. For production AI agents handling sensitive data and credentials, that’s not acceptable.

​
Firecracker microVMs

Superserve runs every session in its own Firecracker microVM - the same technology AWS Lambda uses for isolation.

Dedicated kernel

Each session gets its own Linux kernel. Kernel exploits are contained to that single VM.

Full root access

The agent can install packages, modify system files, and execute any code. Nothing it does can touch other sessions.

Resource limits

CPU, memory, and disk are allocated per-session. One agent can’t starve another.

Sub-second starts

Pre-provisioned VMs mean your agent starts almost instantly, not in minutes.

​
How it works

When you run superserve run my-agent, Superserve:
  1. Spawns a new Firecracker microVM with a fresh kernel
  2. Mounts the persistent /workspace filesystem specific to that session
  3. Injects environment variables and credentials (via the credential proxy)
  4. Starts your agent process inside the VM
  5. Routes all I/O through the streaming API
When the session ends, the VM is destroyed. The next session gets a completely fresh environment.

​
What’s isolated

Each session starts with a clean root filesystem. Your agent can create files, install packages, modify /etc/hosts, or rewrite system configs - none of it affects other sessions.The /workspace directory is the only state that persists. Everything else is ephemeral.
# Inside one session
$ echo "malicious" > /etc/passwd
$ cat /etc/passwd
malicious

# Inside another session (even for the same agent)
$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...
Each microVM has its own network namespace. The agent can bind to any port, make outbound requests, or run servers - none of it is visible to other sessions.All outbound HTTP requests route through Superserve’s managed proxy, which:
  • Injects API keys from secrets (see Credentials)
  • Logs every request for the audit trail
# This works - every session has its own network stack
import http.server
server = http.server.HTTPServer(('0.0.0.0', 8080), handler)
server.serve_forever()
Your agent runs as PID 1 inside the microVM. It can spawn child processes, fork, exec, or use multiprocessing without interfering with other sessions.
import subprocess
# This installs a package inside this session only
subprocess.run(["pip", "install", "requests"])
The next session won’t have requests installed unless it’s in your requirements.txt.
Each session gets allocated CPU and memory limits. One agent can’t consume resources and starve others.If your agent hits a memory limit or runs an infinite loop, it only affects that session. Other sessions continue running normally.

​
Isolation vs. persistence

Superserve combines two seemingly contradictory goals:
  1. Isolation - Every session starts with a clean slate
  2. Persistence - Sessions remember context and files across turns
The solution: the /workspace filesystem is the only state that persists between sessions.
  • When you resume a session, you get a fresh microVM with a clean kernel and filesystem
  • The platform mounts the same /workspace directory from the previous session
  • Your agent’s conversation history is preserved (if your framework supports it)
This gives you the security benefits of ephemeral environments with the UX of persistent state. See Persistence for details.

​
Security model

Superserve’s isolation is designed for multi-tenant production environments where sessions from different users run on shared infrastructure.

​
What Firecracker prevents

  • Cross-session access: One session cannot read files, memory, or network traffic from another session
  • Host access: The agent cannot escape the microVM and access the host OS or other workloads
  • Resource exhaustion: CPU and memory limits prevent one session from affecting others

​
What you still need to handle

  • Input validation: Your agent should validate and sanitize user input before executing code or making API calls
  • Prompt injection: The isolation doesn’t protect against prompt attacks - use a robust system prompt and framework best practices
  • External API security: If your agent calls external APIs, ensure those APIs have proper authentication and authorization

​
Isolation in the SDK

Every run() or stream() call creates a new isolated session unless you explicitly pass a sessionId: 
import Superserve from "@superserve/sdk"

const client = new Superserve({ apiKey: "your-api-key" })

// Each of these runs in its own isolated microVM
const r1 = await client.run("my-agent", { message: "Hello" })
const r2 = await client.run("my-agent", { message: "Hello" })

// These run in the SAME microVM (same session)
const session = await client.createSession("my-agent")
const s1 = await session.run("Hello")
const s2 = await session.run("What did I just say?") // Agent remembers
See Sessions for session lifecycle details.

​
Performance

Firecracker microVMs are designed for high-density, multi-tenant workloads:
  • Sub-second cold starts: Pre-provisioned VMs mean your agent starts in milliseconds, not minutes
  • Low overhead: Firecracker adds ~5MB of memory overhead per VM
  • Efficient snapshotting: The platform can snapshot and restore VMs for even faster starts
For most agents, the isolation overhead is imperceptible compared to LLM inference time.

Persistence

How /workspace survives across sessions

Credentials

How secrets are injected without exposing them

Sessions

Multi-turn conversations and session lifecycle

Deploy

How your code runs inside the microVM

Build docs developers (and LLMs) love

Get started for freeTalk to us