David Karlsson
553c69e1b7
## Summary Restructures the Docker AI Governance documentation under \`/ai/sandboxes/governance/\` and adds the supporting API reference. Preview links: - https://deploy-preview-25162--docsdocker.netlify.app/ai/sandboxes/governance/ - https://deploy-preview-25162--docsdocker.netlify.app/reference/api/ai-governance/ ### Information architecture The existing \`security/governance\` and \`security/policy\` pages are merged into a new top-level \`governance\` section so local-policy and org-policy sit side by side instead of being split across unrelated parents: - \`/ai/sandboxes/governance/\` — section landing; explains local + org as layered enforcement - \`/ai/sandboxes/governance/concepts/\` — resource model, rule syntax, evaluation, precedence - \`/ai/sandboxes/governance/local/\` — \`sbx policy\` CLI for individual machines - \`/ai/sandboxes/governance/org/\` — Admin Console flow (was \`security/governance.md\`) - \`/ai/sandboxes/governance/monitoring/\` — \`sbx policy ls\` / \`sbx policy log\` ### API reference \`/reference/api/ai-governance/\` renders the Governance OpenAPI spec vendored at \`content/reference/api/ai-governance/api.yaml\` from \`docker/governor-services\`. Operations, schemas, examples, and status codes are fully driven by the spec — future updates land via re-vendor, not in-repo edits. Anything wrong in the rendered reference should be fixed upstream and re-vendored here. The spec has been re-vendored to the latest upstream version, which updated the server URL to \`hub.docker.com/v2\` and added the \`/governance/\` prefix to all API paths. ### Review focus 1. The \`/ai/sandboxes/governance/\` landing — does the local + org framing match how the product is positioned? 2. \`/reference/api/ai-governance/\` — does the rendered spec match the source of truth, and is anything important missing? Generated by Claude Code --------- Co-authored-by: Louis-Arnaud <la.catoire@gmail.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2.8 KiB
title, linkTitle, weight, description, keywords
| title | linkTitle | weight | description | keywords |
|---|---|---|---|---|
| Default security posture | Defaults | 15 | What a sandbox permits and blocks before you change any settings. | docker sandboxes, security defaults, network policy, credentials, sbx |
A sandbox created with sbx run and no additional flags has the following
security posture.
Network defaults
All outbound HTTP and HTTPS traffic is blocked unless an explicit rule allows it (deny-by-default). All non-HTTP protocols (raw TCP, UDP including DNS, and ICMP) are blocked at the network layer. Traffic to private IP ranges, loopback addresses, and link-local addresses is also blocked.
Run sbx policy ls to see the active network rules for your installation.
Rules can be customized per machine with the sbx policy CLI, or managed
centrally across your organization from the Admin Console. Org-level rules
take precedence over local rules. See Governance.
Workspace defaults
Sandboxes use a direct mount by default. The agent sees and modifies your working tree directly, and changes appear on your host immediately.
The agent can read, write, and delete any file within the workspace directory, including hidden files, configuration files, build scripts, and Git hooks. See Workspace isolation for what to review after an agent session.
Credential defaults
No credentials are available to the sandbox unless you provide them using
sbx secret or environment variables. When credentials are provided, the
host-side proxy injects them into outbound HTTP headers. The agent cannot
read the raw credential values.
See Credentials for setup instructions.
Agent capabilities inside the sandbox
The agent runs with full control inside the sandbox VM:
sudoaccess (the agent runs as a non-root user with sudo privileges)- A private Docker Engine for building images and running containers
- Package installation through
apt,pip,npm, and other package managers - Full read and write access to the VM filesystem
Everything the agent installs or creates inside the VM, including packages,
Docker images, and configuration changes, persists across stop and restart
cycles. When you remove the sandbox with sbx rm, the VM and its contents
are deleted. Only workspace files remain on the host.
What is blocked by default
The following are blocked for all sandboxes and cannot be changed through policy configuration:
- Host filesystem access outside the workspace directory
- Host Docker daemon
- Host network and localhost
- Communication between sandboxes
- Raw TCP, UDP, and ICMP connections
- Traffic to private IP ranges and link-local addresses
Outbound HTTP/HTTPS to domains not in the allow list is also blocked by
default, but you can add allow rules with sbx policy allow.