ISOLATED EXECUTION

FireAgent

Run autonomous workloads
without compromising
system integrity.

The Problem

Agents execute code, run shell commands, access files, and make network requests. When an agent runs in-process with your application, every action is a security boundary — but most frameworks treat execution as an implementation detail rather than a security primitive.

One bad tool call can read your secrets, delete your data, or reach your network. The model didn't intend it — it was injected, confused, or just wrong. The execution layer is the last line of defense.

FireAgent treats execution as a security primitive: every agent action runs in its own isolated environment with an explicit resource policy.

$ fireagent run --sandbox

⚡ sandbox created sandbox-abc123
⚡ execution policy read-only-fs
⚡ network blocked
⚡ timeout 30s
⚡ memory limit 256MB

✓ agent completed sandbox-abc123
artifacts 3
duration 4.2s
sandbox destroyed

What FireAgent Isolates

Filesystem

Read-only or ephemeral filesystems per sandbox. The agent cannot touch data it wasn't given.

Network

Blocked by default. Allow-listed endpoints only, enforced at the sandbox boundary.

Processes

No escape routes: sandboxed processes cannot see or signal the parent system.

Resources

CPU, memory, and time budgets per action. Exhaustion is contained, not fatal.

System calls

Policy-filtered syscalls so only the operations the task needs are available.

Artifacts

Only explicitly returned files survive the sandbox. Everything else is destroyed.

How It Fits

Decide what happens. Block what shouldn't. Isolate what does.

FireAgent is the last layer of the SpaceSwordAI execution stack. Sokka routes and controls the agent loop. Haiku Guard inspects every request and tool call before execution. FireAgent executes the approved action in isolation — so even a missed injection can't reach the host.

Defense in depth, in order: control → protect → isolate.

ROUTE + CONTROL
Sokka
↓
PROTECT
Haiku Guard
↓
ISOLATE
FireAgent

Compare: funcroute

funcroute and FireAgent sit at opposite ends of the request. funcroute decides which model sees a request at the edge. FireAgent decides what the agent may touch when it acts. Different layers, same philosophy: keep the model out of the system.

funcroute
  before the model: pick the right one
FireAgent
  after the model: contain the action

Limitations

FireAgent provides strong isolation boundaries but cannot eliminate all risk from untrusted agent code. Side-channel attacks, resource exhaustion, and kernel-level exploits exist outside its threat model. Production deployments should combine FireAgent with standard infrastructure security practices — and with Sokka control and Haiku Guard classification.