From 3c6439cb03e3fc26d21ff0b55373f79c26e467b2 Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Wed, 3 Jun 2026 11:25:34 +0200
Subject: [PATCH 1/8] sbx: document team-scoped governance policies

Add docs for scoping organization governance policies to specific teams.
Explains org-wide vs team-scoped policies and how a user's effective
policies combine: additive allows, absolute denies, and org-wide deny
rules acting as guardrails that team-scoped policies can't override.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 .../ai/sandboxes/governance/concepts.md       | 73 +++++++++++++------
 .../manuals/ai/sandboxes/governance/org.md    | 43 ++++++++++-
 2 files changed, 91 insertions(+), 25 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/concepts.md b/content/manuals/ai/sandboxes/governance/concepts.md
index d72f5577c104..abdeeed86539 100644
--- a/content/manuals/ai/sandboxes/governance/concepts.md
+++ b/content/manuals/ai/sandboxes/governance/concepts.md
@@ -11,18 +11,17 @@ Docker sandbox governance is built around two resource types: **policies** and
 **rules**.
 
 A **policy** is a named collection of rules that controls sandbox access.
-Policies exist at different levels:
+Policies exist at two levels:
 
 - **Local**: configured per machine using the `sbx policy` CLI. Applies to
   sandboxes on that machine only.
 - **Organization**: configured in the Docker Admin Console or via the
-  [Governance API](/reference/api/ai-governance/). Applies uniformly across every sandbox in the
-  organization.
-- **Team**: applies to sandboxes used by a specific team within an
-  organization. Coming soon.
+  [Governance API](/reference/api/ai-governance/). Applies to sandboxes across
+  the organization. An organization can have several policies, each applying
+  either org-wide or to specific teams. See [Policy scope](#policy-scope).
 
-When multiple levels are active, organization policies take precedence over
-local policies. See [Precedence](#precedence).
+When organization governance is active, organization policies replace local
+policies entirely. See [Precedence](#precedence).
 
 A **rule** is the unit of access control within a policy. Each rule has:
 
@@ -34,6 +33,27 @@ A **rule** is the unit of access control within a policy. Each rule has:
 Rules are grouped by domain: all rules in a policy must share the same domain,
 either `network` or `filesystem`.
 
+## Policy scope
+
+Each organization policy applies either across the whole organization or only
+to specific teams. The policy's scope determines which members it applies to:
+
+- **Org-wide**: with no teams assigned, the policy applies to every member of
+  the organization.
+- **Team-scoped**: with one or more teams assigned, the policy applies only to
+  members of those teams.
+
+Teams are the same [teams](/manuals/admin/organization/manage/manage-a-team.md)
+you manage for your organization. A team-scoped policy references the teams it
+applies to, and Docker matches those teams against each user's team membership.
+Because assignment follows team membership, you can govern an organization with
+thousands of users without configuring policies per user.
+
+An organization can mix org-wide and team-scoped policies. A user's effective
+policy set is every org-wide policy plus every team-scoped policy for a team
+the user belongs to. See [Rule evaluation](#rule-evaluation) for how those
+policies combine.
+
 ## Rule syntax
 
 ### Network rules
@@ -43,12 +63,12 @@ hostnames, CIDR ranges, or ports.
 
 **Hostname patterns**
 
-| Pattern | Example | Matches |
-| ------- | ------- | ------- |
-| Exact hostname | `example.com` | `example.com` only, not subdomains |
-| Single-level wildcard | `*.example.com` | One subdomain level: `api.example.com` |
-| Multi-level wildcard | `**.example.com` | Any depth: `api.example.com`, `v2.api.example.com` |
-| Hostname with port | `example.com:443` | `example.com` on port 443 only |
+| Pattern               | Example           | Matches                                            |
+| --------------------- | ----------------- | -------------------------------------------------- |
+| Exact hostname        | `example.com`     | `example.com` only, not subdomains                 |
+| Single-level wildcard | `*.example.com`   | One subdomain level: `api.example.com`             |
+| Multi-level wildcard  | `**.example.com`  | Any depth: `api.example.com`, `v2.api.example.com` |
+| Hostname with port    | `example.com:443` | `example.com` on port 443 only                     |
 
 `example.com` and `*.example.com` don't cover each other. Specify both if you
 need to match the root domain and its subdomains.
@@ -63,11 +83,11 @@ Both IPv4 and IPv6 notation are supported: `10.0.0.0/8`, `192.168.1.0/24`,
 Filesystem rules use the actions `read` and `write`. Resources are host paths
 that sandboxes can mount as workspaces.
 
-| Pattern | Example | Matches |
-| ------- | ------- | ------- |
-| Exact path | `/data` | `/data` only |
-| Segment wildcard | `/data/*` | `/data/project`, one path segment only, not subdirectories |
-| Recursive wildcard | `/data/**` | `/data/project`, `/data/project/src`, any depth |
+| Pattern            | Example    | Matches                                                    |
+| ------------------ | ---------- | ---------------------------------------------------------- |
+| Exact path         | `/data`    | `/data` only                                               |
+| Segment wildcard   | `/data/*`  | `/data/project`, one path segment only, not subdirectories |
+| Recursive wildcard | `/data/**` | `/data/project`, `/data/project/src`, any depth            |
 
 Use `**` when you intend to match a directory tree recursively. A single `*`
 only matches within one path segment and won't cross directory boundaries.
@@ -76,8 +96,10 @@ matches only direct children of `~`.
 
 ## Rule evaluation
 
-All rules in a policy are evaluated against every request. The outcome follows
-two principles:
+When organization governance is active, the rules from all of a user's
+effective policies (every org-wide policy plus every matching team-scoped
+policy) are combined and evaluated together against each request. Evaluation
+follows two principles:
 
 **Deny wins.** If any rule matches with `decision: deny`, the request is
 denied regardless of any matching allow rules.
@@ -85,6 +107,11 @@ denied regardless of any matching allow rules.
 **Default deny.** Outbound traffic is blocked unless an explicit allow rule
 matches.
 
+Because rules combine across policies, allows are additive (a request is
+allowed if any effective policy allows it) and denies are absolute (a request
+is blocked if any effective policy denies it). A deny rule in an org-wide
+policy therefore acts as a guardrail that no team-scoped policy can override.
+
 These principles apply within whichever policy is active. When organization
 governance is active, only organization rules are evaluated; local rules have
 no effect.
@@ -101,5 +128,7 @@ whether your organization has governance enabled:
   developer machines, and local and kit-defined rules are not evaluated. They
   still appear in `sbx policy ls`, but with an `inactive` status.
 
-Within the active policy, deny rules beat allow rules regardless of specificity
-or order.
+When organization governance is active, all of a user's effective
+organization policies combine into a single rule set, where deny rules beat
+allow rules regardless of which policy they come from, their specificity, or
+their order. See [Rule evaluation](#rule-evaluation).
diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
index b934c8ecc90c..bc44ac261298 100644
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ b/content/manuals/ai/sandboxes/governance/org.md
@@ -54,11 +54,48 @@ access**. Each rule takes a path pattern and an action (allow or deny).
 For path pattern syntax including the difference between `*` and `**`, see
 [Policy concepts](concepts.md#filesystem-rules).
 
+## Scope policies to teams
+
+An organization can have more than one policy, and each policy applies either
+to the whole organization or to specific teams. Use scoping to give different
+parts of the organization different rules: for example, a permissive policy for
+a security research team alongside a stricter default for everyone else.
+
+When you create or edit a policy in the Admin Console, the **Scope** setting
+controls who it applies to:
+
+- Leave the team list empty to make the policy org-wide. It applies to every
+  member of the organization.
+- Add one or more teams to scope the policy to those teams. It applies only to
+  members of the listed teams.
+
+Teams are the same [teams](/manuals/admin/organization/manage/manage-a-team.md)
+you manage for your organization, so assignment follows existing team
+membership. This lets you manage policies for an organization with thousands of
+users without configuring anything per user. When team membership changes in
+your identity provider, the policies a user receives change with it.
+
+### How org-wide and team-scoped policies combine
+
+A user receives every org-wide policy plus every team-scoped policy for a team
+they belong to. The rules from all of these policies are combined and evaluated
+together:
+
+- **Allows are additive.** A request is allowed if any of the user's effective
+  policies allow it.
+- **Denies are absolute.** A request is blocked if any of the user's effective
+  policies deny it.
+
+Because deny always wins, a deny rule in an org-wide policy acts as a guardrail
+that team-scoped policies can't override. Use org-wide policies for rules that
+must apply everywhere, and team-scoped policies to grant additional access to
+specific teams.
+
 ## Precedence
 
-Within the active policy, deny rules beat allow rules. If a domain matches both,
-it's blocked regardless of specificity. Outbound traffic is blocked unless a
-rule allows it.
+Deny rules beat allow rules. If a resource matches both an allow and a deny, in
+the same policy or across a user's effective policies, it's blocked regardless
+of specificity. Outbound traffic is blocked unless a rule allows it.
 
 When organization governance is active, local rules are not evaluated. Only
 organization rules set in the Admin Console determine what is allowed or

From d249426f60cf61ed2b1d0f57ac49e8e40f86fd7d Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Wed, 3 Jun 2026 11:51:14 +0200
Subject: [PATCH 2/8] sbx: add setup steps and team integration for org
 policies

Add a Create a policy section with the Admin Console steps (name, Scope
toggle, rules) and document team scoping setup: prerequisites (teams via
manual management or SSO group mapping) and a worked guardrail example.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 .../manuals/ai/sandboxes/governance/org.md    | 80 +++++++++++++------
 1 file changed, 55 insertions(+), 25 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
index bc44ac261298..00ce91d3423c 100644
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ b/content/manuals/ai/sandboxes/governance/org.md
@@ -11,10 +11,10 @@ aliases:
 [Local policies](local.md) give individual developers control over what their
 sandboxes can access. Organization policy moves that control to the admin level:
 rules defined in the [Docker Admin Console](https://app.docker.com/admin) apply
-uniformly to every sandbox in the organization. When organization governance is
-active, it replaces local `sbx policy` rules entirely — local rules are no
-longer evaluated and can't be used to supplement or override the organization
-policy.
+to sandboxes across the organization, either to every member or to specific
+teams. When organization governance is active, it replaces local `sbx policy`
+rules entirely — local rules are no longer evaluated and can't be used to
+supplement or override the organization policy.
 
 Admins can manage organization policies through the Admin Console UI or
 programmatically using the [Governance API](/reference/api/ai-governance/).
@@ -25,13 +25,31 @@ programmatically using the [Governance API](/reference/api/ai-governance/).
 > [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
 > to request access.
 
+## Create a policy
+
+Manage policies in the [Docker Admin Console](https://app.docker.com/admin)
+under **AI governance**. Network and filesystem policies are managed
+separately, under **Network access** and **Filesystem access**.
+
+To create a policy:
+
+1. Under **AI governance**, select **Network access** or **Filesystem access**.
+2. Select **Create policy** and enter a **Policy name**.
+3. Set the **Scope** to **Organization** or **Teams**. If you select **Teams**,
+   choose the teams the policy applies to. See
+   [Scope policies to teams](#scope-policies-to-teams).
+4. Select **Add rule** to add each rule. For rule syntax, see
+   [Policy concepts](concepts.md#rule-syntax).
+
+Existing policies are listed with their name, scope, rule count, and last
+update. Use the action menu (⋮) to edit or delete a policy.
+
 ## Network policies
 
 ### Configuring org-level network rules
 
-Define network allow and deny rules in the Admin Console under
-**AI governance > Network access**. Each rule takes a network target and an
-action (allow or deny). You can add multiple entries at once, one per line.
+A network rule takes a network target and an action (allow or deny). You can
+add multiple entries at once, one per line.
 
 For the full syntax reference (exact hostnames, wildcard subdomains, port
 suffixes, and CIDR ranges), see [Policy concepts](concepts.md#network-rules).
@@ -47,9 +65,8 @@ Filesystem policies control which host paths a sandbox can mount as
 workspaces. By default, sandboxes can mount any directory the user has
 access to.
 
-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).
+Admins can restrict which paths are mountable with filesystem allow and deny
+rules. Each rule takes a path pattern and an action (allow or deny).
 
 For path pattern syntax including the difference between `*` and `**`, see
 [Policy concepts](concepts.md#filesystem-rules).
@@ -61,19 +78,26 @@ to the whole organization or to specific teams. Use scoping to give different
 parts of the organization different rules: for example, a permissive policy for
 a security research team alongside a stricter default for everyone else.
 
-When you create or edit a policy in the Admin Console, the **Scope** setting
-controls who it applies to:
+A policy's [**Scope**](#create-a-policy) controls who it applies to. Set it to
+**Organization** to apply the policy to every member, or to **Teams** to apply
+it only to members of the teams you select.
+
+### Before you start
 
-- Leave the team list empty to make the policy org-wide. It applies to every
-  member of the organization.
-- Add one or more teams to scope the policy to those teams. It applies only to
-  members of the listed teams.
+Team scoping targets your organization's existing
+[teams](/manuals/admin/organization/manage/manage-a-team.md), so a team must
+exist before you can scope a policy to it. Create teams and manage their members
+in one of two ways:
 
-Teams are the same [teams](/manuals/admin/organization/manage/manage-a-team.md)
-you manage for your organization, so assignment follows existing team
-membership. This lets you manage policies for an organization with thousands of
-users without configuring anything per user. When team membership changes in
-your identity provider, the policies a user receives change with it.
+- Manually, in the Admin Console.
+- Automatically, by syncing them from your identity provider with
+  [SSO group mapping](/manuals/enterprise/security/single-sign-on/manage.md), so
+  that team membership follows your IdP groups.
+
+Because policy assignment follows team membership, you can govern an
+organization with thousands of users without per-user configuration. When a
+user's team membership changes — whether you edit it directly or it syncs from
+your IdP — the policies they receive change with it.
 
 ### How org-wide and team-scoped policies combine
 
@@ -86,10 +110,16 @@ together:
 - **Denies are absolute.** A request is blocked if any of the user's effective
   policies deny it.
 
-Because deny always wins, a deny rule in an org-wide policy acts as a guardrail
-that team-scoped policies can't override. Use org-wide policies for rules that
-must apply everywhere, and team-scoped policies to grant additional access to
-specific teams.
+Because deny always wins, a deny rule in an **Organization**-scoped policy acts
+as a guardrail that **Teams**-scoped policies can't override. Keep rules that
+must apply everywhere in an organization-scoped policy, and use team-scoped
+policies to grant extra access to specific teams.
+
+For example, an organization-scoped policy can deny a category of domains for
+everyone, while a team-scoped policy grants a research team access to additional
+package mirrors. Research-team members receive both policies: they get the extra
+access, but the organization-wide deny still applies and can't be undone by the
+team policy.
 
 ## Precedence
 

From c7fa99d3afd336f24a3c3c654863d2c3da2d9efe Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Wed, 3 Jun 2026 11:55:39 +0200
Subject: [PATCH 3/8] sbx: drop bold from conceptual list labels per style
 guide

Address PR review feedback: bold is reserved for UI elements, so the
additive/absolute and org-wide/team-scoped list labels use plain text.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 content/manuals/ai/sandboxes/governance/concepts.md |  6 +++---
 content/manuals/ai/sandboxes/governance/org.md      | 12 ++++++------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/concepts.md b/content/manuals/ai/sandboxes/governance/concepts.md
index abdeeed86539..0cdbe199057f 100644
--- a/content/manuals/ai/sandboxes/governance/concepts.md
+++ b/content/manuals/ai/sandboxes/governance/concepts.md
@@ -38,9 +38,9 @@ either `network` or `filesystem`.
 Each organization policy applies either across the whole organization or only
 to specific teams. The policy's scope determines which members it applies to:
 
-- **Org-wide**: with no teams assigned, the policy applies to every member of
-  the organization.
-- **Team-scoped**: with one or more teams assigned, the policy applies only to
+- Org-wide: with no teams assigned, the policy applies to every member of the
+  organization.
+- Team-scoped: with one or more teams assigned, the policy applies only to
   members of those teams.
 
 Teams are the same [teams](/manuals/admin/organization/manage/manage-a-team.md)
diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
index 00ce91d3423c..556e83422aac 100644
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ b/content/manuals/ai/sandboxes/governance/org.md
@@ -105,15 +105,15 @@ A user receives every org-wide policy plus every team-scoped policy for a team
 they belong to. The rules from all of these policies are combined and evaluated
 together:
 
-- **Allows are additive.** A request is allowed if any of the user's effective
+- Allows are additive: a request is allowed if any of the user's effective
   policies allow it.
-- **Denies are absolute.** A request is blocked if any of the user's effective
+- Denies are absolute: a request is blocked if any of the user's effective
   policies deny it.
 
-Because deny always wins, a deny rule in an **Organization**-scoped policy acts
-as a guardrail that **Teams**-scoped policies can't override. Keep rules that
-must apply everywhere in an organization-scoped policy, and use team-scoped
-policies to grant extra access to specific teams.
+Because deny always wins, a deny rule in an organization-scoped policy acts as a
+guardrail that team-scoped policies can't override. Keep rules that must apply
+everywhere in an organization-scoped policy, and use team-scoped policies to
+grant extra access to specific teams.
 
 For example, an organization-scoped policy can deny a category of domains for
 everyone, while a team-scoped policy grants a research team access to additional

From 58737db0e96e7a224b5531c28932eafb5c0bee21 Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Wed, 3 Jun 2026 12:10:48 +0200
Subject: [PATCH 4/8] sbx: tone down projecting language in team policy docs

Replace PRD-style framing ("govern an organization with thousands of
users") with a plain statement that policies are managed by team rather
than per user.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 content/manuals/ai/sandboxes/governance/concepts.md | 4 ++--
 content/manuals/ai/sandboxes/governance/org.md      | 7 +++----
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/concepts.md b/content/manuals/ai/sandboxes/governance/concepts.md
index 0cdbe199057f..e7812198fe2e 100644
--- a/content/manuals/ai/sandboxes/governance/concepts.md
+++ b/content/manuals/ai/sandboxes/governance/concepts.md
@@ -46,8 +46,8 @@ to specific teams. The policy's scope determines which members it applies to:
 Teams are the same [teams](/manuals/admin/organization/manage/manage-a-team.md)
 you manage for your organization. A team-scoped policy references the teams it
 applies to, and Docker matches those teams against each user's team membership.
-Because assignment follows team membership, you can govern an organization with
-thousands of users without configuring policies per user.
+Because assignment follows team membership, you manage policies by team rather
+than per user.
 
 An organization can mix org-wide and team-scoped policies. A user's effective
 policy set is every org-wide policy plus every team-scoped policy for a team
diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
index 556e83422aac..fc74387eed5b 100644
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ b/content/manuals/ai/sandboxes/governance/org.md
@@ -94,10 +94,9 @@ in one of two ways:
   [SSO group mapping](/manuals/enterprise/security/single-sign-on/manage.md), so
   that team membership follows your IdP groups.
 
-Because policy assignment follows team membership, you can govern an
-organization with thousands of users without per-user configuration. When a
-user's team membership changes — whether you edit it directly or it syncs from
-your IdP — the policies they receive change with it.
+Policy assignment follows team membership, so you manage policies by team rather
+than per user. When a user's team membership changes — whether you edit it
+directly or it syncs from your IdP — the policies they receive change with it.
 
 ### How org-wide and team-scoped policies combine
 

From 35a3208c2c08e9d9a1c410241b69b5272854e5e7 Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Wed, 3 Jun 2026 12:22:36 +0200
Subject: [PATCH 5/8] sbx: align team/group-mapping framing with source docs

Link the dedicated group mapping page instead of the SSO overview, and
match its wording: group mapping synchronizes IdP groups with the teams
in your organization, creating teams as needed and keeping membership in
step with your IdP groups.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 content/manuals/ai/sandboxes/governance/org.md | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
index fc74387eed5b..85fe5de4cf17 100644
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ b/content/manuals/ai/sandboxes/governance/org.md
@@ -90,9 +90,11 @@ exist before you can scope a policy to it. Create teams and manage their members
 in one of two ways:
 
 - Manually, in the Admin Console.
-- Automatically, by syncing them from your identity provider with
-  [SSO group mapping](/manuals/enterprise/security/single-sign-on/manage.md), so
-  that team membership follows your IdP groups.
+- Automatically, by using
+  [group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md)
+  to synchronize your identity provider's groups with the teams in your
+  organization. Group mapping creates teams that don't already exist and keeps
+  their membership in step with your IdP groups.
 
 Policy assignment follows team membership, so you manage policies by team rather
 than per user. When a user's team membership changes — whether you edit it

From 9e6b34f1c1292e793dd0b48fef1bd78942f1b33e Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Wed, 3 Jun 2026 12:45:34 +0200
Subject: [PATCH 6/8] sbx: consolidate policy evaluation into a single source
 of truth

Remove the repeated explanations of how effective policies combine. The
concepts page now owns the model: Policy scope defines "effective
policies" once, Rule evaluation owns the deny-wins/additive mechanics, and
Precedence points to it instead of restating. The org page states the
practical upshot once and links to the model, keeping the worked example.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 .../ai/sandboxes/governance/concepts.md       | 60 ++++++++-----------
 .../manuals/ai/sandboxes/governance/org.md    | 53 +++++++---------
 2 files changed, 47 insertions(+), 66 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/concepts.md b/content/manuals/ai/sandboxes/governance/concepts.md
index e7812198fe2e..398f3bda56e9 100644
--- a/content/manuals/ai/sandboxes/governance/concepts.md
+++ b/content/manuals/ai/sandboxes/governance/concepts.md
@@ -36,7 +36,7 @@ either `network` or `filesystem`.
 ## Policy scope
 
 Each organization policy applies either across the whole organization or only
-to specific teams. The policy's scope determines which members it applies to:
+to specific teams:
 
 - Org-wide: with no teams assigned, the policy applies to every member of the
   organization.
@@ -44,15 +44,12 @@ to specific teams. The policy's scope determines which members it applies to:
   members of those teams.
 
 Teams are the same [teams](/manuals/admin/organization/manage/manage-a-team.md)
-you manage for your organization. A team-scoped policy references the teams it
-applies to, and Docker matches those teams against each user's team membership.
-Because assignment follows team membership, you manage policies by team rather
-than per user.
-
-An organization can mix org-wide and team-scoped policies. A user's effective
-policy set is every org-wide policy plus every team-scoped policy for a team
-the user belongs to. See [Rule evaluation](#rule-evaluation) for how those
-policies combine.
+you manage for your organization; Docker matches a policy's teams against each
+user's team membership. Because an organization can mix org-wide and team-scoped
+policies, a single user is often subject to several at once. The policies that
+apply to a given user are their _effective policies_: every org-wide policy,
+plus every team-scoped policy for a team they belong to. See
+[Rule evaluation](#rule-evaluation) for how a user's effective policies combine.
 
 ## Rule syntax
 
@@ -97,38 +94,33 @@ matches only direct children of `~`.
 ## Rule evaluation
 
 When organization governance is active, the rules from all of a user's
-effective policies (every org-wide policy plus every matching team-scoped
-policy) are combined and evaluated together against each request. Evaluation
-follows two principles:
-
-**Deny wins.** If any rule matches with `decision: deny`, the request is
-denied regardless of any matching allow rules.
+[effective policies](#policy-scope) are combined and evaluated together against
+each request, following two principles:
 
-**Default deny.** Outbound traffic is blocked unless an explicit allow rule
-matches.
+- Deny wins: if any rule matches with `decision: deny`, the request is denied,
+  regardless of any matching allow rules.
+- Default deny: outbound traffic is blocked unless an explicit allow rule
+  matches.
 
-Because rules combine across policies, allows are additive (a request is
-allowed if any effective policy allows it) and denies are absolute (a request
-is blocked if any effective policy denies it). A deny rule in an org-wide
-policy therefore acts as a guardrail that no team-scoped policy can override.
+Because every effective policy feeds the same evaluation, allows are additive (a
+request is allowed if any effective policy allows it) and denies are absolute (a
+request is blocked if any effective policy denies it). A deny rule in an
+org-wide policy therefore applies to everyone and can't be overridden by a
+team-scoped policy, which makes org-wide deny rules useful as guardrails.
 
-These principles apply within whichever policy is active. When organization
-governance is active, only organization rules are evaluated; local rules have
-no effect.
+Local rules take no part in this evaluation; see [Precedence](#precedence).
 
 ## Precedence
 
 Local and organization policies don't combine. Which one applies depends on
 whether your organization has governance enabled:
 
-- **No organization governance**: local rules and any
+- No organization governance: local rules and any
   [kit-defined network rules](../customize/kits.md#control-network-access)
   determine what sandboxes can access.
-- **Organization governance active**: organization rules apply across all
-  developer machines, and local and kit-defined rules are not evaluated. They
-  still appear in `sbx policy ls`, but with an `inactive` status.
-
-When organization governance is active, all of a user's effective
-organization policies combine into a single rule set, where deny rules beat
-allow rules regardless of which policy they come from, their specificity, or
-their order. See [Rule evaluation](#rule-evaluation).
+- Organization governance active: organization rules apply across all developer
+  machines, and local and kit-defined rules are not evaluated. They still appear
+  in `sbx policy ls`, but with an `inactive` status.
+
+When organization governance is active, a user's organization policies are
+evaluated together, as described in [Rule evaluation](#rule-evaluation).
diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
index 85fe5de4cf17..41d7e73a291e 100644
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ b/content/manuals/ai/sandboxes/governance/org.md
@@ -74,9 +74,8 @@ For path pattern syntax including the difference between `*` and `**`, see
 ## Scope policies to teams
 
 An organization can have more than one policy, and each policy applies either
-to the whole organization or to specific teams. Use scoping to give different
-parts of the organization different rules: for example, a permissive policy for
-a security research team alongside a stricter default for everyone else.
+to the whole organization or to specific teams. Scoping lets you apply different
+rules to different parts of the organization.
 
 A policy's [**Scope**](#create-a-policy) controls who it applies to. Set it to
 **Organization** to apply the policy to every member, or to **Teams** to apply
@@ -96,43 +95,33 @@ in one of two ways:
   organization. Group mapping creates teams that don't already exist and keeps
   their membership in step with your IdP groups.
 
-Policy assignment follows team membership, so you manage policies by team rather
-than per user. When a user's team membership changes — whether you edit it
-directly or it syncs from your IdP — the policies they receive change with it.
+Because policies apply by team, a user's policies update automatically as their
+team membership changes, including changes synced from your IdP.
 
 ### How org-wide and team-scoped policies combine
 
-A user receives every org-wide policy plus every team-scoped policy for a team
-they belong to. The rules from all of these policies are combined and evaluated
-together:
+A user is governed by all of their
+[effective policies](concepts.md#policy-scope) at once — every org-wide policy,
+plus the team-scoped policies for the teams they belong to. The rules combine
+into a single evaluation in which deny always wins, so a team-scoped policy can
+grant access on top of the org-wide policies but can't loosen a restriction they
+impose. For the full evaluation model, see
+[Rule evaluation](concepts.md#rule-evaluation).
 
-- Allows are additive: a request is allowed if any of the user's effective
-  policies allow it.
-- Denies are absolute: a request is blocked if any of the user's effective
-  policies deny it.
-
-Because deny always wins, a deny rule in an organization-scoped policy acts as a
-guardrail that team-scoped policies can't override. Keep rules that must apply
-everywhere in an organization-scoped policy, and use team-scoped policies to
-grant extra access to specific teams.
-
-For example, an organization-scoped policy can deny a category of domains for
-everyone, while a team-scoped policy grants a research team access to additional
-package mirrors. Research-team members receive both policies: they get the extra
-access, but the organization-wide deny still applies and can't be undone by the
-team policy.
+This makes org-wide policies the natural home for guardrails that must hold
+everywhere. For example, an org-wide policy can deny a category of domains for
+all members, while a team-scoped policy grants a research team access to extra
+package mirrors. Research-team members get the extra access, but the org-wide
+deny still applies.
 
 ## Precedence
 
-Deny rules beat allow rules. If a resource matches both an allow and a deny, in
-the same policy or across a user's effective policies, it's blocked regardless
-of specificity. Outbound traffic is blocked unless a rule allows it.
-
 When organization governance is active, local rules are not evaluated. Only
-organization rules set in the Admin Console determine what is allowed or
-denied, and they can't be supplemented or overridden from a developer's machine.
-The same model applies to filesystem policies: organization rules replace local
-behavior entirely.
+organization rules set in the Admin Console determine what is allowed or denied,
+and they can't be supplemented or overridden from a developer's machine. The
+same applies to filesystem policies: organization rules replace local behavior
+entirely. For how a user's organization policies are evaluated together, see
+[Policy concepts](concepts.md#rule-evaluation).
 
 To unblock a domain when organization governance is active, update the rule in
 the Admin Console or via the [API](/reference/api/ai-governance/). Without

From 5fa4f8f4496d159990d55a3da222db48ff5155de Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Wed, 3 Jun 2026 12:57:59 +0200
Subject: [PATCH 7/8] sbx: fix Admin Console navigation for policy creation

Replace the incorrect app.docker.com/admin link (the real AI governance
URLs are org-scoped and can't be linked directly) with the standard
navigation: sign in to Docker Home, select the org, then Admin Console >
AI governance > Network access / Filesystem access.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 .../manuals/ai/sandboxes/governance/org.md    | 22 ++++++++++---------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
index 41d7e73a291e..902f6895dc7e 100644
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ b/content/manuals/ai/sandboxes/governance/org.md
@@ -10,9 +10,8 @@ aliases:
 
 [Local policies](local.md) give individual developers control over what their
 sandboxes can access. Organization policy moves that control to the admin level:
-rules defined in the [Docker Admin Console](https://app.docker.com/admin) apply
-to sandboxes across the organization, either to every member or to specific
-teams. When organization governance is active, it replaces local `sbx policy`
+rules defined in **Admin Console** apply to sandboxes across the organization,
+either to every member or to specific teams. When organization governance is active, it replaces local `sbx policy`
 rules entirely — local rules are no longer evaluated and can't be used to
 supplement or override the organization policy.
 
@@ -27,18 +26,21 @@ programmatically using the [Governance API](/reference/api/ai-governance/).
 
 ## Create a policy
 
-Manage policies in the [Docker Admin Console](https://app.docker.com/admin)
-under **AI governance**. Network and filesystem policies are managed
-separately, under **Network access** and **Filesystem access**.
+Manage policies under **Admin Console**, a section in the left-hand navigation
+of [Docker Home](https://app.docker.com). Network and filesystem policies are
+managed separately, under **Network access** and **Filesystem access**.
 
 To create a policy:
 
-1. Under **AI governance**, select **Network access** or **Filesystem access**.
-2. Select **Create policy** and enter a **Policy name**.
-3. Set the **Scope** to **Organization** or **Teams**. If you select **Teams**,
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization.
+1. Select **Admin Console**, then **AI governance**.
+1. Select **Network access** or **Filesystem access**, then **Create policy**.
+1. Enter a **Policy name**.
+1. Set the **Scope** to **Organization** or **Teams**. If you select **Teams**,
    choose the teams the policy applies to. See
    [Scope policies to teams](#scope-policies-to-teams).
-4. Select **Add rule** to add each rule. For rule syntax, see
+1. Select **Add rule** to add each rule. For rule syntax, see
    [Policy concepts](concepts.md#rule-syntax).
 
 Existing policies are listed with their name, scope, rule count, and last

From 77936b516525c962f812fcc3f9eba8ed40f1074b Mon Sep 17 00:00:00 2001
From: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Date: Thu, 4 Jun 2026 06:42:46 +0200
Subject: [PATCH 8/8] sbx: cover filesystem policies in the default-deny
 principle
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Address review feedback: the default-deny principle described outbound
network traffic only. It now covers both domains — outbound traffic needs
a network rule, and a host path needs a filesystem rule before it can be
mounted.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 content/manuals/ai/sandboxes/governance/concepts.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/content/manuals/ai/sandboxes/governance/concepts.md b/content/manuals/ai/sandboxes/governance/concepts.md
index 398f3bda56e9..8c2ccaebfc00 100644
--- a/content/manuals/ai/sandboxes/governance/concepts.md
+++ b/content/manuals/ai/sandboxes/governance/concepts.md
@@ -99,8 +99,9 @@ each request, following two principles:
 
 - Deny wins: if any rule matches with `decision: deny`, the request is denied,
   regardless of any matching allow rules.
-- Default deny: outbound traffic is blocked unless an explicit allow rule
-  matches.
+- Default deny: anything an allow rule doesn't match is blocked. Outbound
+  network traffic is blocked unless a network rule allows the destination, and a
+  host path can't be mounted unless a filesystem rule allows it.
 
 Because every effective policy feeds the same evaluation, allows are additive (a
 request is allowed if any effective policy allows it) and denies are absolute (a