Sandbox Security

The sandbox lets an LLM run arbitrary shell commands against a filesystem. That is a powerful capability and worth thinking about carefully.

Isolation model

Every sandbox is an isolated container, per-thread — the sandbox tied to thread A cannot be reached from thread B — and opened by auxilia at the start of each run of a sandbox-bound agent. No idle containers sit around beyond the provider’s own lifetime rules.

The auxilia backend never executes commands itself — it always delegates to the sandbox runtime. So the blast radius of a malicious prompt is whatever your sandbox deployment allows the container to do.

With OpenSandbox, containers are managed by OpenSandbox and have a TTL of 30 minutes, renewed each time the thread runs; after expiry they are destroyed and any state inside is lost.

With Daytona, sandboxes run in Daytona’s infrastructure, auto-stop after the configured idle period and are started again on the next run. Deleting them is up to you in the Daytona dashboard.

With Cloud Run sandboxes:

Sandboxed code sees the gateway image’s filesystem read-only, with a private writable overlay per sandbox
Sandboxes have no outbound network access unless the gateway is deployed with ALLOW_EGRESS=true and the sandbox’s Allow network egress is on
The gateway requires a shared bearer secret on every request and fails closed if the secret is unset
If a GCS bucket is set, the writable overlay is snapshotted to GCS at the end of each turn — treat that bucket as containing whatever agents write

Credentials

The API key or gateway secret you enter for a sandbox is encrypted at rest (AES-GCM, like MCP API keys) and never returned by the API — only a last-characters hint for admins. Put the OpenSandbox controller on a private network (VPC, internal DNS) and only let the auxilia backend reach it. Use server proxy routes file reads and writes through the controller rather than direct container ports, which is simpler in firewalled environments.

Volume mounts (OpenSandbox only)

You can mount host paths into every sandbox created from a sandbox row via its Volume mounts field:


/srv/shared:/workspace:ro, /tmp/auxilia:/mnt/scratch

Format: host_path:sandbox_path[:ro], comma-separated.

Each entry becomes a volume on every sandbox spun up from this row
The :ro suffix mounts read-only
Paths are resolved (~ expanded) and checked for existence on the auxilia backend host, and skipped with a warning when missing — mounts are meant for a controller running on the same host as the backend

Treat the host paths you mount as public to any agent bound to that sandbox. If you mount /srv/data read-only, every such agent can read it. If you mount /tmp/auxilia read-write, every sandbox can write to it — it is a shared scratch space. This is also how a sandbox can be given a credential file (a service account key, a gcloud configuration) without baking it into the image: mount it read-only, and bind that sandbox only to the agents that should have it.

Timeouts

Two timeouts apply:

Per-command timeout — the sandbox’s Timeout (seconds), default 1800. If a single execute call doesn’t finish in this window, auxilia interrupts it and returns exit_code=124.
Container lifetime — 30 minutes on OpenSandbox (renewed on every run); the idle Auto-stop on Daytona (a stopped sandbox is woken, not lost); none on Cloud Run, where the gateway instance and GCS snapshots bound it.

Keep the per-command timeout tight. Long-running commands are rare in practice and chew up sandbox capacity.

Skills in the sandbox

The scripts/ of every skill enabled on the agent are uploaded into the sandbox at /tmp/auxilia-skills/. A skill synced from a repository is code your agents will run — review it in the repository’s own review flow, and keep the Sources tab admin-only (it is).