​

Security Model

1. Governance decides. Every tool call goes through one dispatch point where a policy allows, asks for, or denies it before it runs.
2. The sandbox contains. Code the agent runs with execute runs in a separate container, never on your host.

​

Recommended setup

agent_config = {
    "governance_config": {
        "enabled": True,
        "profile": "interactive-dev",  # or "strict-production" with your own rules
        "sandbox_config": {"provider": "docker"},
    },
}

​

What the Docker sandbox enforces

• No network unless your policy allows it (turning it on asks for approval in the development profiles).
• A read-only root filesystem, an unprivileged user, all Linux capabilities dropped, no privilege escalation, and memory, CPU, and process limits.
• A size-limited working directory in memory, removed with the container.
• Only the environment you set; your process’s variables and credentials never reach it.
• Host paths that would hand over your machine are never mounted, whatever the policy says: the Docker socket, system directories, and credential directories such as ~/.ssh or ~/.aws.
• One container per run, removed when the run ends, including when it is cancelled.

​

Trust boundaries

​

Built-in protections

• A governed agent only delegates to governed subagents.
• A project’s AGENTS.md instructions are guidance only: they cannot grant a permission or change the policy, and one inside the agent’s workspace, over the size limit, or refused by the injection guardrail is not used (AGENTS.md).
• A policy file inside the agent’s workspace, or inside a directory mounted read-write into the sandbox, is refused, so the agent cannot edit its own policy.
• Files the sandbox produces come back to the workspace only through governed, bounded copies (no links, hidden paths, oversized or non-text files).
• Every run’s trace records each command, its policy decision, and each file copy, and its header lists security_warnings for configurations with less protection than you might assume (see Observability).

​

What is not protected

• Anything your policy allows. An allow rule for a dangerous capability is honoured.
• Your own tools and host skill scripts run with your privileges.
• Data leaving through an allowed channel (an MCP tool, a tool of yours, a sandbox with the network on). There is no data-flow tracking.
• The host kernel, when the sandbox uses plain Docker rather than gVisor.
• Governance off. Without it, no policy applies and the sandbox is unused.