craig-osterhout · Oct 20, 2026 · Oct 20, 2026 · Oct 21, 2026
diff --git a/content/get-started/tutorials/admin-set-up.md b/content/get-started/tutorials/admin-set-up.md
@@ -84,5 +84,5 @@ Continue with these guides when you're ready to expand the deployment:
   for additional policies and deployment controls
 - [Set up SSO and provisioning](/manuals/security/authentication/single-sign-on/_index.md)
   for centralized identity management
-- [Govern Docker Sandboxes](/manuals/ai/sandboxes/governance/_index.md) for
-  organization-wide agent policies
+- [Govern Docker Sandboxes](/manuals/ai/sandboxes/governance/organization/_index.md)
+  for organization-wide agent policies
diff --git a/content/get-started/tutorials/run-an-agent.md b/content/get-started/tutorials/run-an-agent.md
@@ -94,7 +94,7 @@ The first time you run a sandbox, `sbx` asks you to choose a default network
 policy. This policy controls which external services your sandboxes can reach.
 Select **Balanced** to permit common development services and block other
 destinations by default. You can change these rules later with
-[`sbx policy`](/manuals/ai/sandboxes/governance/access-controls/local.md).
+[`sbx policy`](/manuals/ai/sandboxes/governance/local/network-rules.md).
 
 The built-in integrations start coding agents in their full-autonomy mode. For
 example, Codex bypasses approvals, Claude Code skips permission prompts, and

diff --git a/content/guides/firecrawl-sandbox-kit.md b/content/guides/firecrawl-sandbox-kit.md
@@ -170,10 +170,10 @@ API, including structured extraction with a schema, see the
 
 Without organization governance, your default network policy and kit-defined
 rules determine which domains the sandbox can access. Under organization
-governance, organization policy controls which domains can be allowed; local
-and kit-defined allow rules are inactive, while deny rules can still restrict
+governance, organization policy controls which domains can be allowed; local and
+kit-defined allow rules are inactive, while deny rules can still restrict
 access. See
-[Network policy precedence](/manuals/ai/sandboxes/governance/concepts.md#precedence).
+[How organization policy relates to local and kit rules](/manuals/ai/sandboxes/governance/organization/policies/_index.md#how-organization-policy-relates-to-local-and-kit-rules).
 
 The Firecrawl kit requests access to PyPI during installation and
 `api.firecrawl.dev` at runtime. Its credential declaration tells the proxy to

@@ -27,7 +27,7 @@ Organization owners and members with a custom role that includes the
 > Use activity logs for an admin audit trail of your organization and
 > repositories, including AI Governance policy and settings changes. For
 > enforcement events, such as policy decisions and sandbox sessions, see
-> [AI Governance Audit Logs](/manuals/ai/sandboxes/governance/audit/_index.md).
+> [AI Governance Audit Logs](/manuals/ai/sandboxes/governance/organization/audit/_index.md).
 
 ## Access activity logs
 
@@ -234,7 +234,7 @@ The following table lists Offload events that cover lease start and end.
 The following table lists governance events that cover the AI Governance
 admin audit trail, such as policy and settings changes. For enforcement
 events, such as policy decisions and sandbox sessions, see
-[AI Governance Audit Logs](/manuals/ai/sandboxes/governance/audit/_index.md).
+[AI Governance Audit Logs](/manuals/ai/sandboxes/governance/organization/audit/_index.md).
 
 | Event | Description |
 |:------|:------------|
@@ -249,7 +249,7 @@ events, such as policy decisions and sandbox sessions, see
 
 - [Roles and permissions](/manuals/security/roles-and-permissions/_index.md) for
   the **View activity logs** permission and custom roles
-- [AI Governance Audit Logs](/manuals/ai/sandboxes/governance/audit/_index.md) for
+- [AI Governance Audit Logs](/manuals/ai/sandboxes/governance/organization/audit/_index.md) for
   enforcement events such as policy decisions and sandbox sessions
 - [Audit logs API](/reference/api/hub/latest/#tag-audit-logs) to query events
   programmatically
diff --git a/content/manuals/agentic-platform/policies.md b/content/manuals/agentic-platform/policies.md
@@ -49,8 +49,11 @@ removed, and review the allow rules in the remaining policies and kit.
 If the combined allow list contains any rules, destinations outside that list
 are blocked. This default behavior isn't an explicit deny rule: adding an
 allow rule in another policy permits the matching destinations. If the
-combined allow list is empty or absent, the sandbox can reach any destination
-except those blocked by deny rules.
+combined allow list is empty or absent, your account's default network mode
+applies. The default is deny all, so the sandbox can't reach any destination
+until an allow rule permits it. Accounts created before deny all became the
+default have an explicit allow all default instead, so their sandboxes can
+reach any destination except those blocked by deny rules.
 
 ## Policy rules
 

@@ -18,7 +18,7 @@ work. Cloud compute uses a
 Model-provider charges are separate.
 
 Organization admins can
-[centrally manage sandbox network, filesystem, and MCP policies](governance/access-controls/organization.md),
+[centrally manage sandbox network, filesystem, and MCP policies](governance/organization/_index.md),
 for local sandboxes across developer machines.
 Available on a separate paid subscription.
 

@@ -77,8 +77,9 @@ $ DOCKER_SANDBOXES_ENABLE_VIRTIOFS_CACHE=0 sbx run <agent>
 
 All outbound TCP traffic from the sandbox routes through a proxy on your host.
 Agents use a forward proxy for HTTP and HTTPS; other TCP traffic is forwarded
-transparently. Both paths enforce
-[network access policies](governance/access-controls/network.md). The forward
+transparently. Both paths enforce network policy, the rules that decide which
+destinations a sandbox can reach. For how those rules are set, see
+[Governance](governance/_index.md). The forward
 proxy also handles [credential injection](configuration/credentials.md). See
 [Network isolation](security/isolation.md#network-isolation) for how this
 works and [Default security posture](security/defaults.md) for what is

@@ -465,9 +465,10 @@ $ sbx secret set-custom \
 ```
 
 A `--host` value can also use wildcards, with the same syntax as
-[network rules](../governance/concepts.md#network-rules): `*` matches a
-single label (`*.example.com` covers `api.example.com`) and `**` matches any
-number (`**.example.com` covers `api.example.com` and `v2.api.example.com`).
+[network rule hostname patterns](../governance/reference/network-rules.md#hostname-patterns):
+`*` matches a single label (`*.example.com` covers `api.example.com`) and `**`
+matches any number (`**.example.com` covers `api.example.com` and
+`v2.api.example.com`).
 
 ### Resolve custom secrets dynamically
 

@@ -628,7 +628,8 @@ $ sbx daemon restart
 This shared list applies to sandbox and daemon traffic unless a scope-specific
 list replaces it. A value of `*` bypasses the upstream proxy for all destinations.
 Proxy exclusions don't grant network access: sandbox requests must still pass
-[network policy](../governance/access-controls/network.md).
+network policy. For how network policy is set, see
+[Governance](../governance/_index.md).
 
 #### no_proxy.sandbox {.wrap-anywhere}
 

@@ -22,9 +22,9 @@ originating inside a cloud sandbox. For cloud sandbox egress controls, see
 
 An upstream proxy is the corporate or network proxy that Docker Sandboxes
 forwards outbound traffic through on its way to the internet. This is separate
-from the [network policy](../governance/access-controls/network.md), which decides
-_which_ destinations are allowed. The upstream proxy decides _how_ allowed
-traffic reaches them.
+from network policy, which decides _which_ destinations are allowed. The
+upstream proxy decides _how_ allowed traffic reaches them. For how network
+policy is set, see [Governance](../governance/_index.md).
 
 Docker Sandboxes sends two kinds of outbound traffic, and you can proxy them
 independently:

@@ -164,8 +164,9 @@ A response confirms that Claude Code can reach the API and authenticate with
 your stored key. If authentication fails, check that you stored the key and
 approved the kit's request to use it. See
 [Credential bindings](/manuals/ai/sandboxes/configuration/credentials.md#credential-bindings).
-Network requests must also meet the sandbox's
-[network policy](/manuals/ai/sandboxes/governance/concepts.md#precedence).
+Network requests must also meet the sandbox's network policy, which combines
+the mixin's network rules with the developer's own. For more details, see
+[How rules combine](/manuals/ai/sandboxes/governance/local/_index.md#how-rules-combine).
 
 Run `claude` without arguments to start an interactive session. Follow its
 first-run prompts. Exit Claude Code and the shell to return to your host.

@@ -18,9 +18,9 @@ Model-provider charges are separate from sandbox compute.
 
 Organization governance for local sandboxes includes centrally managed network,
 filesystem, and MCP policies,
-[sign-in enforcement](governance/monitor-and-enforce/sign-in-enforcement.md),
-and [audit logs](governance/audit/). These
-[organization governance features](governance/) require a separate paid
+[sign-in enforcement](governance/organization/sign-in-enforcement.md),
+and [audit logs](governance/organization/audit/_index.md). These
+[organization governance features](governance/organization/_index.md) require a separate paid
 subscription —
 [contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
 to get started.
@@ -34,7 +34,7 @@ Signing in gives each sandbox a verified identity, which lets Docker:
   containers, install packages, and push code. Your Docker identity is the
   anchor.
 - **Enable team features.** Team-scale features like
-  [organization governance](governance/), shared environments, and audit logs
+  [organization governance](governance/organization/_index.md), shared environments, and audit logs
   need a concept of "who," and adding that later would be worse for everyone.
 - **Authenticate against Docker infrastructure.** Sandboxes pull images, run
   daemons, and talk to Docker services. A Docker account authenticates those
@@ -50,8 +50,9 @@ governance is active, only organization allow rules grant access: local allow
 rules set with `sbx policy` are no longer evaluated, while local deny rules
 still apply on top.
 
-See [Organization policies](governance/access-controls/organization.md). This
-feature requires a separate paid subscription —
+See
+[How organization policy relates to local and kit rules](governance/organization/policies/_index.md#how-organization-policy-relates-to-local-and-kit-rules).
+This feature requires a separate paid subscription —
 [contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
 to get started.
 
@@ -112,7 +113,7 @@ the sandbox, to pick up the new value.
 ## Why do agents run without approval prompts?
 
 The sandbox itself is the safety boundary. Because agents run inside an
-isolated microVM with [network policies](governance/access-controls/network.md),
+isolated microVM with [network isolation](security/isolation.md#network-isolation),
 [credential isolation](security/isolation.md#credential-isolation), and no access to your host
 system outside explicitly shared paths, the usual reasons for approval prompts
 (preventing destructive commands, network access, file modifications) are

@@ -72,8 +72,9 @@ Initialize the global network policy for your sandboxes:
 
 **Balanced** is a good starting point — it permits traffic to common
 development services while blocking everything else. You can adjust individual
-rules later. See [Local policy](governance/access-controls/local.md) for a full
-description of each option.
+rules later. See
+[Start from a preset](governance/local/_index.md#start-from-a-preset) for a
+full description of each option.
 
 Replace `claude` with the agent you want to use — see [Agents](agents/) for the
 full list.
@@ -140,7 +141,7 @@ $ sbx policy allow network registry.npmjs.org
 With **Locked Down**, even your model provider API is blocked unless you
 explicitly allow it. With **Balanced**, common development services are
 permitted by default. See
-[local policy](governance/access-controls/local.md) for the full rule set
+[local policy](governance/local/_index.md) for the full rule set
 and how to customize it.
 
 ## Clean up

@@ -3,74 +3,77 @@ title: Governance
 weight: 120
 description: Control what sandboxes can access, from local developer rules to org-wide enforcement.
 keywords: docker sandboxes, governance, policy, network access, filesystem access, mcp policy, organization policy
+aliases:
+  - /ai/sandboxes/governance/access-controls/
+  - /ai/sandboxes/governance/monitor-and-enforce/
 ---
 
-The governance described here applies to local sandboxes. Cloud sandboxes
-use separate network policy configuration. See
-[Cloud network policy](../cloud/network-policy.md) for cloud controls.
-
-Sandbox governance covers the policy system that controls what sandboxes can
-access over the network, on the filesystem, and through MCP. For MCP setup and
-server registration, see [MCP gateway](../mcp-gateway.md). Governance operates
-at two layers:
-
-**Local policy** is configured per machine using the `sbx policy` CLI. It
-lets individual developers customize which domains their sandboxes can reach.
-See [Local policy](access-controls/local.md).
-
-**Organization policy** is configured centrally in Docker Home. Network and
-filesystem policies can also be managed via the
-[Governance API](/reference/api/ai-governance/). Controls defined at the org
-level apply uniformly across every local sandbox in the organization. Organization
-governance can also include MCP policies for sandbox MCP activity. When
-organization governance is active, only organization allow rules grant access:
-local `sbx policy` allow rules are no longer evaluated, while local deny rules
-still apply on top. See
-[Organization policies](access-controls/organization.md).
-
-Alongside this access-control policy, admins can require developers to sign in
-as members of their organization before using sandboxes at all.
-[Sign-in enforcement](monitor-and-enforce/sign-in-enforcement.md) is deployed
-through endpoint management and ensures developers can't bypass organization
-policy by using a personal account.
+Agents in sandboxes work on their own. They install packages, call APIs, and
+use tools without asking you first. Governance lets an agent work freely within
+limits you set. It has two parts: local policy, which applies to one machine,
+and organization governance, which applies across an organization and also
+records what sandboxes did in audit logs.
 
 > [!NOTE]
-> Organization governance is available on a separate paid subscription.
-> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
-> to request access.
-
-## Learn more
-
-Start with [Policy concepts](concepts.md) for the resource model, rule syntax,
-MCP policy basics, evaluation, and precedence.
-
-### Access controls
-
-- [Local policy](access-controls/local.md): configure network rules on your
-  machine with the `sbx policy` CLI.
-- [Organization policies](access-controls/organization.md): centrally manage
-  sandbox policies across your organization.
-- [Network access policies](access-controls/network.md): control outbound network
-  access from sandboxes, by host or by HTTP method and path.
-- [Filesystem access policies](access-controls/filesystem.md): control which
-  host paths sandboxes can mount as workspaces.
-- [MCP access policies](access-controls/mcp.md): control MCP server registration,
-  tool calls, resources, prompts, and approval gates.
-
-### Monitor and enforce
-
-- [Monitoring policies](monitor-and-enforce/monitoring.md): inspect active
-  rules and monitor sandbox network traffic with `sbx policy ls` and
-  `sbx policy log`.
-- [Audit logs](audit/): view, configure, export, and collect governance audit
-  records.
-- [Sign-in enforcement](monitor-and-enforce/sign-in-enforcement.md): require
-  developers to sign in as organization members, enforced through endpoint
-  management.
-
-### Reference
-
-- [AI Governance API](/reference/api/ai-governance/): manage network and
-  filesystem org policies programmatically.
-- [MCP policy reference](reference/mcp-policy.md): look up Docker MCP policy
-  actions, resources, attributes, context fields, and approval behavior.
+> This section covers sandboxes that run on your machine. Cloud sandboxes use
+> the same kinds of allow and deny rules, but they don't use local policy or
+> organization policy. They use
+> [cloud network policy](../cloud/network-policy.md), which is stored in your
+> Docker account and managed with `sbx --cloud policy` or in the Docker Agentic
+> Platform [Console](/manuals/agentic-platform/policies.md).
+
+## Who sets the rules
+
+The two parts of governance differ in who sets the rules and who the rules
+apply to.
+
+### You, with local policy and kits
+
+[Local policy](local/_index.md) is the policy you set on your machine with the
+`sbx policy` CLI. You start from a preset, then allow or block the network
+destinations your sandboxes need. Local policy is available to everyone on their
+machine.
+
+The kits your sandboxes use, including the built-in agent kits, can add network
+rules too, such as the API endpoints an agent needs. Kit rules work like the
+rules you add yourself.
+
+### Your organization, with organization governance
+
+With [organization governance](organization/_index.md), administrators set
+policies for the members of their organization who hold an AI Governance
+license. Organization policies control network access, the host paths
+sandboxes can mount, and MCP activity. Organization governance requires an
+[AI Governance plan](/manuals/subscription-billing/plans/ai-governance.md).
+
+## How governance works
+
+Governance works through rules. A rule allows or denies one kind of access,
+such as a network destination, and a policy is a set of rules. When a sandbox
+tries to reach a network destination, the request is checked against your
+rules. With organization policy, the same check also applies when a sandbox
+mounts a host path or uses an MCP server.
+
+The rules are enforced outside the sandbox, so an agent running inside it
+can't change or bypass them. For where network rules are enforced as a request
+leaves the sandbox, see [Networking](../architecture.md#networking).
+
+Local policy and organization policy both follow this model. For how each one
+works, see [How local policy works](local/_index.md#how-local-policy-works)
+and
+[How organization governance works](organization/_index.md#how-organization-governance-works).
+
+Local policy, kit rules, and organization policy combine differently depending
+on whether an organization policy is enforced for you. For more details, see
+[How organization policy relates to local and kit rules](organization/policies/_index.md#how-organization-policy-relates-to-local-and-kit-rules).
+
+## Get started
+
+If you're a developer, start with
+[Try out local policy](local/try-it-out.md), an example that allows and blocks
+destinations for one sandbox.
+
+If you're an administrator, start with
+[Get started with organization governance](organization/get-started.md) to set
+up licenses, sign-in enforcement, policies, and audit logs for your
+organization.