---
title: "Sandboxing"
description: "Sandboxing workflow execution"
---

Sandboxes isolate agent execution from the host machine. When an agent runs a shell command, edits a file, or searches code, it does so inside a sandbox — preventing unintended side effects on the host and providing a reproducible environment for each run.

Fabro supports three sandbox providers: `local` (no isolation), `docker` (container-level), and `daytona` (cloud VM). See [Environments](/execution/environments) for full provider-specific configuration.

Operators can enable or disable which providers the server may launch with
`[server.sandbox.providers.<provider>]` in `settings.toml`. Missing entries default to
`enabled = true`; setting `enabled = false` rejects new runs whose effective provider is disabled.
Dry-run Docker/Daytona runs execute locally, so they are governed by the `local` provider policy.

The API can also list Fabro-managed sandboxes directly from configured providers:

```http
GET /api/v1/sandboxes
GET /api/v1/sandboxes/{id}
```

Provider-backed inventory is useful when you need to inspect Docker or Daytona resources independent of a single run projection. Listing is fail-soft: available provider results are returned with provider errors in response metadata.

## Network access control

For cloud sandboxes (Daytona), you can control outbound network access with `[environments.<slug>.network]`. Three modes are available: `"allow_all"` (default), `"block"`, and `"cidr_allow_list"` with an `allow = ["..."]` CIDR list.

Server defaults in `settings.toml` apply when a run config doesn't specify `network`. Individual run configs can override the server default.

See [Environments — Network access](/execution/environments#network-access) for syntax examples and the full reference.