docker · dvdksn · Apr 4, 2026
@@ -1,75 +1,16 @@
 ---
 title: Policies
 weight: 30
-description: Configure network access and filesystem rules for sandboxes.
+description: Configure network access rules for sandboxes.
 ---
 
 {{< summary-bar feature_name="Docker Sandboxes sbx" >}}
 
 Sandboxes are [network-isolated](isolation.md) from your host and from each
-other. A policy system controls what a sandbox can access — which external
-hosts it can reach over the network, and which host paths it can mount as
-workspaces.
+other. A policy system controls what a sandbox can access over the network.
 
-Policies can be set at two levels:
-
-- **Organization policies** {{< badge color=blue text="Limited Access" >}} — configured by admins in the
-  [Docker Admin Console](https://app.docker.com/admin) under AI governance
-  settings. These apply to all sandboxes across the organization.
-- **Local policies** — configured by individual users with the `sbx policy`
-  command. These apply to all sandboxes on the local machine.
-
-If your organization has enabled governance, organization policies replace
-local rules — local `sbx policy` rules are not evaluated unless an admin
-also turns on the **User defined** setting. See [Precedence](#precedence)
-for details.
-
-## Organization policies {tier="Limited Access"}
-
-> [!NOTE]
-> Organization governance is a Limited Access feature. Contact your Docker
-> account team to request access.
-
-Organization admins can centrally manage policies through the
-[Docker Admin Console](https://app.docker.com/admin). Navigate to your
-organization settings and enable **Manage AI governance**.
-
-Once enabled, the policies defined in the Admin Console apply to all
-sandboxes across the organization.
-
-### Local extensions to organization policy
-
-When organization governance is active, local rules are ignored by default.
-Admins can optionally let users extend the organization policy by turning on
-the **User defined** setting in AI governance settings. When turned on,
-local `sbx policy` rules are evaluated alongside organization rules, letting
-users add hosts to the allowlist from their own machine using
-`sbx policy allow network`.
-
-Local extensions can expand access for domains the organization hasn't
-explicitly denied, but can't override organization-level deny rules. This
-applies to exact matches and wildcard matches alike — if the organization
-denies `*.example.com`, a local allow for `api.example.com` has no effect
-because the org-level wildcard deny covers it.
-
-For example, given an organization policy that allows `api.anthropic.com`
-and denies `*.corp.internal`:
-
-- `sbx policy allow network api.example.com` — works, because the
-  organization hasn't denied `api.example.com`
-- `sbx policy allow network build.corp.internal` — no effect, because the
-  organization denies `*.corp.internal`
-
-#### Blocked values in user-defined rules
-
-To prevent overly broad rules from undermining the organization's policy,
-certain catch-all values are blocked in user-defined rules:
-
-- Domain patterns: `*`, `**`, `*.com`, `**.com`, `*.*`, `**.**`
-- CIDR ranges: `0.0.0.0/0`, `::/0`
-
-Scoped wildcards like `*.example.com` are still allowed. If you attempt to
-use a blocked value, `sbx policy` returns an error immediately.
+Use the `sbx policy` command to configure network access rules. Rules apply
+to all sandboxes on the machine.
 
 ## Network policies
 
@@ -100,11 +41,6 @@ Choose a default network policy:
 You can change your effective policy at any time using `sbx policy allow` and
 `sbx policy deny`, or start over by running `sbx policy reset`.
 
-> [!NOTE]
-> If your organization manages AI governance policies, organization rules
-> take precedence over the policy you select here. See
-> [Organization policies](#organization-policies).
-
 ### Non-interactive environments
 
 In non-interactive environments such as CI pipelines or headless servers, the
@@ -126,10 +62,7 @@ allows it. The **Balanced** policy ships with a baseline allowlist covering AI p
 APIs, package managers, code hosts, container registries, and common cloud
 services. Run `sbx policy ls` to see the active rules for your installation.
 
-Organization admins can modify or remove these defaults when configuring
-[organization policies](#organization-policies).
-
-### Managing local rules
+### Managing rules
 
 Use [`sbx policy allow`](/reference/cli/sbx/policy/allow/) and
 [`sbx policy deny`](/reference/cli/sbx/policy/deny/) to add network access
@@ -194,16 +127,6 @@ $ sbx policy allow network "**"
 This lets agents install packages and call any external API without additional
 configuration. You can still deny specific hosts with `sbx policy deny`.
 
-### Org-level rules {tier="Limited Access"}
-
-Define network allow and deny rules in the Admin Console under
-**AI governance > Network access**. Each rule takes a network target (domain,
-wildcard, or CIDR range) and an action (allow or deny). You can add multiple
-entries at once, one per line.
-
-Organization-level rules use the same [wildcard syntax](#wildcard-syntax) as
-local rules.
-
 ### Wildcard syntax
 
 Rules support exact domains (`example.com`), wildcard subdomains
@@ -263,62 +186,19 @@ $ sbx policy log my-sandbox
 Use `--limit N` to show only the last `N` entries, `--json` for
 machine-readable output, or `--type network` to filter by policy type.
 
-## Filesystem policies
-
-Filesystem policies control which host paths a sandbox can mount as
-workspaces. By default, sandboxes can mount any directory the user has
-access to.
-
-### Org-level restrictions {tier="Limited Access"}
-
-Admins can restrict which paths are mountable by defining filesystem allow
-and deny rules in the Admin Console under **AI governance > Filesystem access**.
-Each rule takes a path pattern and an action (allow or deny).
-
-> [!CAUTION]
-> Use `**` (double wildcard) rather than `*` (single wildcard) when writing
-> path patterns to match path segments recursively. A single `*` only matches
-> within a single path segment. For example, `~/**` matches all paths under the
-> user's home directory, whereas `~/*` matches only paths directly under `~`.
-
 ## Precedence
 
-Within any layer, deny rules beat allow rules — if a domain matches both,
-it's blocked regardless of specificity.
-
 All outbound traffic is blocked by default unless an explicit rule allows it.
-How rules are evaluated depends on whether organization governance is active.
-
-Without organization governance, local rules (`sbx policy`) are the only
-rules evaluated against this default-deny baseline.
-
-With organization governance, local rules are not evaluated. Only
-organization rules (Docker Admin Console) determine what is allowed or
-denied. Organization-level denials can't be overridden locally.
+If a domain matches both an allow and a deny rule, the deny rule wins
+regardless of specificity.
 
-If the admin turns on the **User defined** setting, local rules are also
-evaluated alongside organization rules. Local rules can expand access for
-domains the organization hasn't explicitly denied, but can't override
-organization-level denials.
-
-The same model applies to filesystem policies: organization-level rules take
-precedence over local behavior.
-
-To unblock a domain, identify where the deny rule comes from. For local rules,
-remove it with `sbx policy rm`. For organization-level rules, contact your
-organization admin.
+To unblock a domain, find the deny rule with `sbx policy ls` and remove it
+with `sbx policy rm`.
 
 ## Troubleshooting
 
 ### Policy changes not taking effect
 
 If policy changes aren't taking effect, run `sbx policy reset` to wipe the
 local policy store and restart the daemon. On next start, you are prompted to
-choose a new network policy, and the latest organization policies are pulled if
-governance is enabled.
-
-### Sandbox cannot mount workspace
-
-If a sandbox fails to mount with a `mount policy denied` error, verify that
-the filesystem allow rule uses `**` rather than `*`. A single `*` doesn't
-match across directory separators.
+choose a new network policy.