docs: fix stale Admin Console nav references in AI sandboxes

content/manuals/ai/sandboxes/_index.md

@@ -18,9 +18,9 @@ system.
 > [organization governance](governance/) requires a separate paid subscription.
 
 Organization admins can
-[centrally manage sandbox network and filesystem policies](governance/org.md)
-from the Docker Admin Console, so the same rules apply uniformly across every
-developer's machine. Available on a separate paid subscription.
+[centrally manage sandbox network and filesystem policies](governance/org.md),
+so the same rules apply uniformly across every developer's machine. Available
+on a separate paid subscription.
 
 ## Get started
 

content/manuals/ai/sandboxes/faq.md

@@ -40,8 +40,8 @@ Your Docker account email is only used for authentication, not marketing.
 
 ## Can I enforce sandbox policies across my organization?
 
-Yes. Admins can centrally manage network and filesystem policies from the
-Docker Admin Console. Rules defined there apply to every sandbox in the
+Yes. Admins can centrally manage network and filesystem policies. These
+rules apply to every sandbox in the
 organization. When organization governance is active, it replaces local rules
 set with `sbx policy` — local rules are no longer evaluated.
 

content/manuals/ai/sandboxes/governance/_index.md

@@ -13,7 +13,7 @@ only one applies at a time:
 lets individual developers customize which domains their sandboxes can reach.
 See [Local policy](local.md).
 
-**Organization policy** is configured centrally in the Docker Admin Console or
+**Organization policy** is configured centrally in Docker Home or
 via the [Governance API](/reference/api/ai-governance/). Rules defined at the org level apply
 uniformly across every sandbox in the organization. When organization
 governance is active, it replaces local policy entirely: local `sbx policy`
@@ -37,7 +37,7 @@ personal account.
 - [Local policy](local.md): configure network and filesystem rules on your
   machine with the `sbx policy` CLI
 - [Organization policy](org.md): centrally manage sandbox policies across
-  your organization from the Admin Console
+  your organization
 - [Sign-in enforcement](sign-in-enforcement.md): require developers to sign in
   as organization members, enforced through endpoint management
 - [Monitoring](monitoring.md): inspect active rules and monitor sandbox

content/manuals/ai/sandboxes/governance/concepts.md

@@ -15,7 +15,7 @@ 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
+- **Organization**: configured in Docker Home or via the
   [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).

content/manuals/ai/sandboxes/governance/local.md

@@ -175,8 +175,7 @@ They're hidden from `sbx policy ls` by default; run `sbx policy ls
 column.
 
 Organization policy can't be supplemented from your machine. To change what
-your sandboxes can access, ask your admin to update the organization policy in
-the Admin Console.
+your sandboxes can access, ask your admin to update the organization policy.
 
 ### A domain is still blocked after adding an allow rule
 
@@ -186,5 +185,5 @@ ls` to check whether org governance is active; if the output starts with a
 `Policy rules` header listing a `Governance  Managed by <org>` line, it is. Add
 `--include-inactive` to confirm your rule shows an `inactive` status. If so, the
 block can only be
-lifted by updating the org policy in the Admin Console or via the
+lifted by updating the org policy in Docker Home or via the
 [API](/reference/api/ai-governance/).

content/manuals/ai/sandboxes/governance/org.md

@@ -3,19 +3,19 @@ title: Organization policy
 linkTitle: Org policy
 weight: 20
 description: Centrally manage sandbox network and filesystem policies for your organization.
-keywords: docker sandboxes, governance, organization policy, AI governance, admin console, network access, filesystem access
+keywords: docker sandboxes, governance, organization policy, AI governance, Docker Home, network access, filesystem access
 aliases:
   - /ai/sandboxes/security/governance/
 ---
 
 [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 **Admin Console** apply to sandboxes across the organization,
+rules 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.
 
-Admins can manage organization policies through the Admin Console UI or
+Admins can manage organization policies through the Docker Home UI or
 programmatically using the [Governance API](/reference/api/ai-governance/).
 
 By default, only organization
@@ -33,16 +33,17 @@ with the **Governance** permissions and assign it to a user or team.
 
 ## Create a policy
 
-Manage policies under **Admin Console**, a section in the left-hand navigation
+Manage policies from the **AI Platform** 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. Sign in to [Docker Home](https://app.docker.com) and select your
    organization.
-1. Select **AI Platform**, then the governance section you want.
-1. Select **Network access** or **Filesystem access**, then **Create policy**.
+1. In the left-hand navigation, expand **AI Platform** and select
+   **Network access** or **Filesystem access**.
+1. Select **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
@@ -98,7 +99,7 @@ Team scoping targets your organization's existing
 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.
+- Manually, in Docker Home.
 - 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
@@ -171,21 +172,21 @@ wildcards match.
 ## Precedence
 
 When organization governance is active, local rules are not evaluated. Only
-organization rules set in the Admin Console determine what is allowed or denied,
+organization rules 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
+Docker Home or via the [API](/reference/api/ai-governance/). Without
 organization governance, remove the local rule with `sbx policy rm`.
 
 ## Troubleshooting
 
 ### Policy changes not taking effect
 
-After updating organization policies in the Admin Console, changes take up
+After updating organization policies, changes take up
 to 5 minutes to propagate to developer machines. To apply changes
 immediately, users can run `sbx policy reset`, which stops the daemon and
 forces it to pull the latest organization policies on the next `sbx`
@@ -215,5 +216,5 @@ and create a new one.
 ### Sandbox cannot mount workspace
 
 If a sandbox fails to mount with a `mount policy denied` error, verify that
-the filesystem allow rule in the Admin Console uses `**` rather than `*`. A
+the filesystem allow rule uses `**` rather than `*`. A
 single `*` doesn't match across directory separators.

content/manuals/ai/sandboxes/governance/sign-in-enforcement.md

@@ -262,7 +262,7 @@ For access, contact ACME IT Security:
 ## Related pages
 
 - [Organization policy](org.md): centrally manage sandbox network and
-  filesystem rules from the Docker Admin Console
+  filesystem rules
 - [Governance overview](_index.md): how local and organization governance fit
   together
 - [Enforce sign-in for Docker Desktop](/manuals/enterprise/security/enforce-sign-in/_index.md):

content/manuals/ai/sandboxes/security/defaults.md

@@ -18,8 +18,8 @@ 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](../governance/).
+centrally across your organization. Org-level rules take precedence over local
+rules. See [Governance](../governance/).
 
 ## Workspace defaults
 

content/manuals/ai/sandboxes/usage.md

@@ -371,8 +371,8 @@ needs:
   configurations, MCP servers, base images, and per-project policies. Every
   developer pulls them down with their workspace.
 - [Organization governance](governance/org.md) lets admins define
-  network and filesystem rules in the Docker Admin Console. The rules apply
-  across every developer's sandboxes and take precedence over local policy.
+  network and filesystem rules that apply across every developer's sandboxes
+  and take precedence over local policy.
   Available on a separate paid subscription.
 
 Customization gives developers shared starting points. Governance gives