Sandbox policy, without running a sandbox

A sandbox policy is a SandboxConfig that says how an action may run, its CPU and memory limits, whether it reaches the network and whether the disk is read-only, separately from the question of whether it may run at all.

Last updated: 14 Oct, 2026 · Agent Governance Toolkit 4.1.0

Every gate so far decided whether a tool runs. A sandbox decides how: it boxes the action into a container with hard limits, so even an allowed action cannot exhaust the machine or reach the network. Building that policy is pure local Python. Running it is not, and this lesson is honest about the line between the two.

Describing how an action may run

Syntax: SandboxConfig takes keyword limits and every one has a default. A small, locked-down policy sets a low memory cap, half a CPU, no network, and a read-only filesystem.

import warnings; warnings.simplefilter("ignore")
from agent_sandbox import SandboxConfig

# a policy for HOW an action may run: limited cpu and memory, no network, read-only disk
config = SandboxConfig(memory_mb=256, cpu_limit=0.5, network_enabled=False,
                       read_only_fs=True, timeout_seconds=30)

Reading the policy back

The config is a plain object you can inspect before anything runs. Printing the fields confirms the limits the sandbox would apply.

for field in ["cpu_limit", "memory_mb", "network_enabled", "read_only_fs", "timeout_seconds"]:
    print(f"{field:16} = {getattr(config, field)}")

cpu_limit        = 0.5
memory_mb        = 256
network_enabled  = False
read_only_fs     = True
timeout_seconds  = 30

Whether a sandbox can run here

Running the action for real needs a sandbox provider, and the Docker provider needs a Docker daemon and the docker package. On a machine without them, the provider reports that it is unavailable rather than pretending to run anything.

from agent_sandbox import DockerSandboxProvider

provider = DockerSandboxProvider()
print("Docker available:", provider.is_available())

Docker available: False

The execution line, not run here

With a daemon present you would open a session and run the action inside it. This is the shape of that call. It is not run in this lesson, because there is no Docker daemon here, and without one create_session raises RuntimeError: Docker daemon is not available rather than returning a fake result.

# needs a running Docker daemon; not available here, so this line is not run
session = provider.create_session("support-agent", config=config)
# session.run(...) would execute the action inside the container

What is real here and what is not

• The policy is real and runs. SandboxConfig builds, holds its limits, and can be inspected and passed around with no container.
• The execution is not run here. It needs Docker, and the provider says so through is_available() rather than failing halfway.
• No sandbox output is invented. Where a real run would print a result, this lesson shows the call and stops, because faking it would teach the wrong thing.

Policy versus execution

Where a sandbox policy fits

• An agent that runs generated code, where the code must be capped on CPU, memory and network even when it is allowed to run.
• A tool that touches the filesystem, pinned to a read-only disk so it cannot write outside a known directory.
• A deployment with a real container runtime, where this same config is handed to a provider that can enforce it.

Related

• Previous: Both policy engines behind one gate
• Next: Circuit breakers and an error budget
• Go deeper: AI Security