diff --git a/content/manuals/admin/organization/manage/manage-licenses.md b/content/manuals/admin/organization/manage/manage-licenses.md
index 295e00f9c51e..aab4a0e776e0 100644
--- a/content/manuals/admin/organization/manage/manage-licenses.md
+++ b/content/manuals/admin/organization/manage/manage-licenses.md
@@ -44,5 +44,5 @@ See these docs to explore Docker Core add-ons, or products that need licenses:
 
 - [Docker plans](/manuals/subscription/plans/_index.md) to learn about different add-ons
 - [Manage seats](/manuals/admin/organization/manage/manage-seats.md) to add more seats to your Docker Core subscription
-- [AI Governance](/manuals/ai/sandboxes/governance/org.md) to set up organization policies for your organization members
+- [AI Governance plan](/manuals/subscription/plans/ai-governance.md) to learn about AI Governance license usage and billing
 - [Docker Offload](/manuals/offload/about.md) to let your developers offload building and running containers to the cloud
diff --git a/content/manuals/ai/sandboxes/_index.md b/content/manuals/ai/sandboxes/_index.md
index 1a05b57821e4..5035dd768ad3 100644
--- a/content/manuals/ai/sandboxes/_index.md
+++ b/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),
-so the same rules apply uniformly across every developer's machine. Available
-on a separate paid subscription.
+[centrally manage sandbox network, filesystem, and MCP policies](governance/access-controls/organization.md),
+so the same controls apply uniformly across every developer's machine.
+Available on a separate paid subscription.
 
 ## Get started
 
@@ -73,6 +73,8 @@ the [usage guide](usage.md) for basic commands.
 ## Learn more
 
 - [Agents](agents/) — supported agents and per-agent configuration
+- [MCP gateway](mcp-gateway.md) — register MCP servers and connect them to
+  sandboxed agents
 - [Customize](customize/) — reusable templates and declarative kits for
   extending or tailoring sandboxes
 - [Architecture](architecture.md) — microVM isolation, workspace mounting,
diff --git a/content/manuals/ai/sandboxes/agents/_index.md b/content/manuals/ai/sandboxes/agents/_index.md
index ad8fecf38657..56c6627a2ca5 100644
--- a/content/manuals/ai/sandboxes/agents/_index.md
+++ b/content/manuals/ai/sandboxes/agents/_index.md
@@ -1,7 +1,7 @@
 ---
 title: Supported agents
 linkTitle: Agents
-weight: 30
+weight: 40
 description: AI coding agents supported by Docker Sandboxes.
 keywords: docker sandboxes, ai agents, claude code, codex, cursor, gemini
 ---
diff --git a/content/manuals/ai/sandboxes/architecture.md b/content/manuals/ai/sandboxes/architecture.md
index ef44743e1111..a04f801b4cf4 100644
--- a/content/manuals/ai/sandboxes/architecture.md
+++ b/content/manuals/ai/sandboxes/architecture.md
@@ -1,6 +1,6 @@
 ---
 title: Architecture
-weight: 40
+weight: 70
 description: Technical architecture of Docker Sandboxes; workspace mounting, storage, networking, and sandbox lifecycle.
 keywords: docker sandboxes, architecture, microVM, workspace mounting, sandbox lifecycle
 ---
@@ -52,7 +52,7 @@ $ DOCKER_SANDBOXES_ENABLE_VIRTIOFS_CACHE=0 sbx run <template>
 
 All outbound traffic from the sandbox routes through an HTTP/HTTPS proxy on
 your host. Agents are configured to use the proxy automatically. The proxy
-enforces [network access policies](governance/) and handles
+enforces [network access policies](governance/access-controls/network.md) and handles
 [credential injection](security/credentials.md). See
 [Network isolation](security/isolation.md#network-isolation) for how this
 works and [Default security posture](security/defaults.md) for what is
@@ -100,6 +100,22 @@ One limitation applies:
   `HTTP_PROXY`, `HTTPS_PROXY`, or `DOCKER_SANDBOXES_PROXY` environment variables
   explicitly.
 
+## MCP gateway
+
+Supported agents connect to a single MCP gateway endpoint for the sandbox. The
+gateway runs on the host side of the sandbox boundary and brokers access to
+registered MCP servers.
+
+Registered MCP servers can be remote endpoints, or they can be local stdio
+servers launched on the host. Local stdio servers don't run inside the sandbox
+VM. If a local stdio server is packaged as an OCI image, or if you register an
+explicit `docker` command, it uses Docker on the host.
+
+When MCP policies apply, enforcement happens on the MCP gateway path, separate
+from the HTTP/HTTPS network proxy. Server registration is checked before the
+server is stored, and governed MCP requests are checked by the gateway before
+tool calls, resource reads, prompt retrieval, or gateway meta-tool execution.
+
 ## Lifecycle
 
 `sbx run` initializes a VM with a workspace for a specified agent and starts
diff --git a/content/manuals/ai/sandboxes/customize/_index.md b/content/manuals/ai/sandboxes/customize/_index.md
index d5df8e2365ae..0656152a770c 100644
--- a/content/manuals/ai/sandboxes/customize/_index.md
+++ b/content/manuals/ai/sandboxes/customize/_index.md
@@ -3,7 +3,7 @@ title: Customizing sandboxes
 linkTitle: Customize
 description: Build reusable sandbox images, extend agents with tools and credentials, and define custom agents using templates and kits.
 keywords: sandboxes, sbx, customize, templates, kits, mixins, custom agents
-weight: 35
+weight: 60
 aliases:
   - /ai/sandboxes/agents/custom-environments/
 params:
diff --git a/content/manuals/ai/sandboxes/customize/kit-examples.md b/content/manuals/ai/sandboxes/customize/kit-examples.md
index 4f28e25d77a8..0cec9987c798 100644
--- a/content/manuals/ai/sandboxes/customize/kit-examples.md
+++ b/content/manuals/ai/sandboxes/customize/kit-examples.md
@@ -77,7 +77,7 @@ Install steps run under `sh`, not bash, so bash-only builtins such as
 (`curl … | bash`) or wrap the step in `bash -c '…'` when you need them.
 
 Downloads are subject to the sandbox's
-[deny-by-default network policy](../governance/local.md). A domain that
+[network access rules](../governance/access-controls/network.md). A domain that
 resolves from your host can still be blocked inside the sandbox — for
 example, `get.sdkman.io` returns a 403 until you allow it with
 `sbx policy allow network get.sdkman.io`. A tool may also need base
diff --git a/content/manuals/ai/sandboxes/faq.md b/content/manuals/ai/sandboxes/faq.md
index 0b0bf00728aa..57e3f1721ad7 100644
--- a/content/manuals/ai/sandboxes/faq.md
+++ b/content/manuals/ai/sandboxes/faq.md
@@ -1,6 +1,6 @@
 ---
 title: FAQ
-weight: 70
+weight: 110
 description: Frequently asked questions about Docker Sandboxes.
 keywords: docker sandboxes, sbx, faq, sign in, telemetry, clipboard, image paste, pricing, commercial use, allowlist, firewall, domains, proxy
 ---
@@ -11,9 +11,10 @@ Yes to both. The `sbx` CLI is free to use, including for commercial and
 professional work, with no per-seat fee. Install it, sign in with a free
 Docker account, and run sandboxes at no cost.
 
-The only paid component is organization governance: centrally managed network
-and filesystem policies, [sign-in enforcement](governance/sign-in-enforcement.md),
-and [audit logs](governance/audit.md). These
+The only paid component is organization governance: centrally managed network,
+filesystem, and MCP policies,
+[sign-in enforcement](governance/monitor-and-enforce/sign-in-enforcement.md),
+and [audit logs](governance/monitor-and-enforce/audit.md). These
 [organization governance features](governance/) require a separate paid
 subscription —
 [contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
@@ -29,9 +30,8 @@ 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/org.md), shared environments, and
-  audit logs need a concept of "who," and adding that later would be worse for
-  everyone.
+  [organization governance](governance/), 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
   requests.
@@ -40,13 +40,13 @@ 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. 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.
+Yes. Admins can centrally manage network, filesystem, and MCP policies. These
+controls 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.
 
-See [Organization governance](governance/org.md). This feature requires
-a separate paid subscription —
+See [Organization policies](governance/access-controls/organization.md). This
+feature requires a separate paid subscription —
 [contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
 to get started.
 
@@ -132,7 +132,7 @@ $ echo $BRAVE_API_KEY
 ## 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/),
+isolated microVM with [network policies](governance/access-controls/network.md),
 [credential isolation](security/credentials.md), and no access to your host
 system outside the workspace, the usual reasons for approval prompts (preventing
 destructive commands, network access, file modifications) are handled by the
diff --git a/content/manuals/ai/sandboxes/get-started.md b/content/manuals/ai/sandboxes/get-started.md
index 7289d445f6e2..1a64bc9ee22c 100644
--- a/content/manuals/ai/sandboxes/get-started.md
+++ b/content/manuals/ai/sandboxes/get-started.md
@@ -115,8 +115,9 @@ Use ↑/↓ to navigate, Enter to select, or press 1–3.
 
 **Balanced** is a good starting point — it permits traffic to common
 development services while blocking everything else. You can adjust individual
-rules later. See [Policies](governance/local.md) for a full description of each
-option.
+rules later. See
+[default network presets](governance/access-controls/local.md#default-preset)
+for a full description of each option.
 
 > [!NOTE]
 > See the [FAQ](faq.md) for details on why sign-in is required and what
@@ -211,11 +212,11 @@ To allow a specific host:
 $ sbx policy allow network registry.npmjs.org
 ```
 
-With **Balanced**, common development services are allowed by default. With
-**Locked Down**, everything is blocked until you allow it — including your
-model provider's API. If the agent can't reach a service it needs, the network
-policy is the first place to look. See [Policies](governance/local.md) for the
-full rule set and how to customize it.
+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
+and how to customize it.
 
 ## Clean up
 
@@ -259,5 +260,5 @@ Then explore:
   network rules into a reusable definition you launch with a single flag.
 - [Agents](agents/) — the full list of supported agents and how to configure
   each one.
-- [Governance](governance/) — centrally manage network and filesystem policies
-  across a team.
+- [Governance](governance/) — centrally manage network, filesystem, and MCP
+  policies across a team.
diff --git a/content/manuals/ai/sandboxes/governance/_index.md b/content/manuals/ai/sandboxes/governance/_index.md
index d3bf414a603d..398d34c7d5f6 100644
--- a/content/manuals/ai/sandboxes/governance/_index.md
+++ b/content/manuals/ai/sandboxes/governance/_index.md
@@ -1,29 +1,33 @@
 ---
 title: Governance
-weight: 55
+weight: 90
 description: Control what sandboxes can access, from local developer rules to org-wide enforcement.
-keywords: docker sandboxes, governance, policy, network access, filesystem access, organization policy
+keywords: docker sandboxes, governance, policy, network access, filesystem access, mcp policy, organization policy
 ---
 
 Sandbox governance covers the policy system that controls what sandboxes can
-access over the network and on the filesystem. It operates at two layers, and
-only one applies at a time:
+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, and only one applies at a time:
 
 **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](local.md).
+See [Local policy](access-controls/local.md).
 
-**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`
-rules are no longer evaluated. See [Organization policy](org.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 sandbox in the organization. Organization
+governance can also include MCP policies for sandbox MCP activity. When
+organization governance is active, it replaces local policy entirely: local
+`sbx policy` rules are no longer evaluated. 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](sign-in-enforcement.md) is deployed through endpoint
-management and ensures developers can't bypass organization policy by using a
-personal account.
+[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.
 
 > [!NOTE]
 > Organization governance is available on a separate paid subscription.
@@ -32,17 +36,36 @@ personal account.
 
 ## Learn more
 
-- [Policy concepts](concepts.md): resource model, rule syntax, evaluation,
-  and precedence
-- [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
-- [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
-  network traffic with `sbx policy ls` and `sbx policy log`
-- [Audit logs](audit.md): capture a durable, structured record of every
-  policy decision for SIEM ingestion and compliance
-- [API reference](/reference/api/ai-governance/): manage org policies
-  programmatically via the Governance API
+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.
+- [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](monitor-and-enforce/audit.md): capture a durable, structured
+  record of policy decisions for SIEM ingestion and compliance.
+- [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.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/_index.md b/content/manuals/ai/sandboxes/governance/access-controls/_index.md
new file mode 100644
index 000000000000..a2d2e1ff1f3c
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/_index.md
@@ -0,0 +1,27 @@
+---
+title: Access controls
+weight: 20
+description: Configure local and organization controls for sandbox network, filesystem, and MCP access.
+keywords: docker sandboxes, access controls, governance, network access, filesystem access, MCP access
+---
+
+Access controls are expressed as policies. Local and organization pages
+describe where policies apply. Network and filesystem pages describe the rules
+inside those policies. MCP policies use Cedar statements instead of the network
+and filesystem rule format.
+
+## Policy scope
+
+- [Local policy](local.md): configure network rules on a developer machine with
+  the `sbx policy` CLI.
+- [Organization policies](organization.md): manage centralized policies for an
+  organization or team.
+
+## Access surfaces
+
+- [Network access policies](network.md): control outbound network access from
+  sandboxes.
+- [Filesystem access policies](filesystem.md): control which host paths
+  sandboxes can mount as workspaces.
+- [MCP access policies](mcp.md): control MCP server registration, tool calls,
+  resources, prompts, and approval gates with Cedar policy.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/filesystem.md b/content/manuals/ai/sandboxes/governance/access-controls/filesystem.md
new file mode 100644
index 000000000000..76ce6408e6fb
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/filesystem.md
@@ -0,0 +1,52 @@
+---
+title: Filesystem access policies
+linkTitle: Filesystem access
+weight: 40
+description: Control which host paths Docker Sandboxes can mount as workspaces with organization filesystem policies.
+keywords: docker sandboxes, filesystem access, filesystem rules, workspace mount, organization policy, governance
+---
+
+Filesystem access policies control which host paths a sandbox can mount as a
+workspace. Each policy contains one or more rules that restrict sandbox
+workspaces to approved directories.
+
+Filesystem access is managed with [organization policies](organization.md). When
+organization governance is active, filesystem rules replace local behavior for
+workspace mounts.
+
+## Rule syntax
+
+Filesystem rules use the actions `read` and `write`. Resources are host path
+patterns.
+
+A writable workspace mount must be allowed by both a `read` rule and a `write`
+rule. A read-only workspace needs only `read`.
+
+Examples:
+
+- `~/**`
+- `/data/project/**`
+- `C:\data\project\**`
+- `\\wsl.localhost\<distro>\data\project\**`
+
+Use `**` to match a directory tree recursively. A single `*` matches only one
+path segment. For exact path matching behavior across macOS, Linux, Windows,
+and WSL, see [Filesystem rules](../concepts.md#filesystem-rules).
+
+## Organization filesystem rules
+
+Organization filesystem rules belong to policies that can apply to the whole
+organization or to selected teams. For setup steps and team scoping, see
+[Organization policies](organization.md).
+
+Filesystem policy is checked when a workspace is mounted, which happens when a
+sandbox is created. To apply a filesystem policy change to a running workflow,
+remove the sandbox and create a new one.
+
+## Troubleshooting
+
+### 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.
diff --git a/content/manuals/ai/sandboxes/governance/local.md b/content/manuals/ai/sandboxes/governance/access-controls/local.md
similarity index 88%
rename from content/manuals/ai/sandboxes/governance/local.md
rename to content/manuals/ai/sandboxes/governance/access-controls/local.md
index 10fd14f2a8c5..ed309aaed514 100644
--- a/content/manuals/ai/sandboxes/governance/local.md
+++ b/content/manuals/ai/sandboxes/governance/access-controls/local.md
@@ -1,29 +1,32 @@
 ---
 title: Local policy
 weight: 10
-description: Configure network access rules for sandboxes on your local machine.
+description: Configure local network access rules for sandboxes on your machine.
 keywords: docker sandboxes, local policy, network access, allow rules, deny rules, sbx policy
 aliases:
   - /ai/sandboxes/security/policy/
+  - /ai/sandboxes/governance/local/
 ---
 
-The `sbx policy` command manages network access rules on your local machine.
-Rules apply to all sandboxes on the machine when you use the global scope, or
-to a single sandbox when scoped by name.
+The `sbx policy` command manages the local policy on your machine. The local
+policy contains network access rules. Rules apply to all sandboxes on the
+machine when you use the global scope, or to a single sandbox when scoped by
+name.
 
-Local rules apply only when your organization doesn't enforce governance:
+Local policy applies only when your organization doesn't enforce governance:
 
-- **No org governance**: local rules fully control what sandboxes can access.
-- **Org governance active**: the organization policy replaces local policy.
+- **No org governance**: the local policy controls what sandboxes can access.
+- **Org governance active**: organization policies replace local policy.
   Local rules are inactive, and `sbx policy allow` and `sbx policy deny` have
   no effect. To list the inactive local rules, run
   `sbx policy ls --include-inactive`. See
-  [Monitoring](monitoring.md#showing-inactive-rules).
+  [Monitoring](../monitor-and-enforce/monitoring.md#showing-inactive-rules).
 
-See [Organization policy](org.md) for how organization governance works.
+See [Organization policies](organization.md) for how organization governance
+works.
 
 For domain patterns, wildcards, CIDR ranges, and filesystem path syntax, see
-[Policy concepts](concepts.md#rule-syntax).
+[Policy concepts](../concepts.md#rule-syntax).
 
 ## Default preset
 
@@ -61,7 +64,7 @@ v0.35.0, the Balanced preset also allows VS Code domains, Azure Blob Storage
 > [!NOTE]
 > If your organization manages sandbox policies centrally, organization rules
 > take precedence over the preset you select here. See
-> [Organization policy](org.md).
+> [Organization policies](organization.md).
 
 ### Non-interactive environments
 
@@ -117,7 +120,8 @@ To inspect which policies are active and where they come from, use
 `sbx policy ls`. Use `--source` to filter by origin (`local`, `org`, `kit`),
 `--decision` to filter by outcome (`allow`, `deny`), and `--wide` for
 rule-level detail including rule IDs. To inspect a single policy or rule in
-full, use `sbx policy inspect`. See [Monitoring](monitoring.md).
+full, use `sbx policy inspect`. See
+[Monitoring](../monitor-and-enforce/monitoring.md).
 
 ## Testing policy
 
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/mcp.md b/content/manuals/ai/sandboxes/governance/access-controls/mcp.md
new file mode 100644
index 000000000000..5af8c44ee72a
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/mcp.md
@@ -0,0 +1,235 @@
+---
+title: MCP access policies
+linkTitle: MCP access
+weight: 50
+description: Use Cedar-based MCP policies to control sandbox MCP server registration, tool calls, prompts, resources, and approval gates.
+keywords: docker sandboxes, MCP policy, MCP access, Cedar policy, requireApproval, AI Governance
+---
+
+MCP access policies let organization administrators control which Model
+Context Protocol (MCP) servers developers can register and what agents can do
+through Docker's MCP gateway. Use these policies to approve trusted servers,
+withdraw access to a server, require approval for tool calls, and restrict
+host-run servers. To register MCP servers and connect them to sandboxes, see
+[MCP gateway](../../mcp-gateway.md).
+
+Unlike [network access policies](network.md) and
+[filesystem access policies](filesystem.md), MCP policies are organization
+policies written in Cedar. Docker defines the `MCP` namespace, including the
+actions, resource types, attributes, and approval behavior that policies can
+match. This page focuses on representative access patterns. For Docker's exact
+policy surface, see the [MCP policy reference](../reference/mcp-policy.md). For
+Cedar syntax and language semantics, see the
+[Cedar documentation](https://docs.cedarpolicy.com/).
+
+## Govern the server lifecycle
+
+MCP policy applies at two points in a server's lifecycle. A rule for one point
+doesn't automatically govern the other.
+
+| Admin decision                             | Evaluation point                            | Match with                                                                 |
+| ------------------------------------------ | ------------------------------------------- | -------------------------------------------------------------------------- |
+| Whether a server can be registered         | When a developer runs `sbx mcp add`         | The registered name and resolved server attributes, such as `identityURL`  |
+| What agents can do through the MCP gateway | When the gateway handles a governed request | The registered server name, tool annotations, resource URI, or prompt name |
+
+Registration rules affect future registrations. They don't remove a saved
+registration or prevent an existing registration from being loaded with
+`sbx mcp load`. Use-time rules govern tool calls, resource reads, and prompt
+retrieval from servers that are already registered or loaded.
+
+Server names are chosen during registration. Registration rules can match the
+chosen name and resolved server identity together. At use time, tools,
+resources, and prompts are associated with the registered name, so rules for an
+existing server must match every name under which it was registered.
+
+Built-in gateway tools, such as `code-mode` and OAuth authorization helpers,
+are also governed at use time. They are `MCP::Primordial` resources rather than
+tools associated with a registered server. For details, see
+[Built-in gateway tools](../../mcp-gateway.md#built-in-gateway-tools).
+
+Use-time policy doesn't hide or remove existing registrations. Tool and
+resource listings can also include entries that policy denies when an agent
+tries to use them.
+
+## Choose an access posture
+
+When MCP policy enforcement is active for a user, registration and governed MCP
+requests are denied unless a matching `permit` allows them. A matching `forbid`
+overrides any `permit`, including a permit with `@requireApproval`.
+
+Use permits for an allowlist policy. For a blocklist policy that grants MCP
+activity except for explicit restrictions, start with an actionless permit:
+
+```plaintext
+permit (principal, action, resource);
+```
+
+This statement permits every MCP action that reaches Cedar evaluation. Add
+`forbid` statements for the restrictions the policy must enforce.
+
+Policy scope supplies the principal. Use organization or team scope instead of
+matching users, teams, tenants, or roles in Cedar. If MCP policy enforcement
+isn't active for a user, the gateway doesn't evaluate Cedar policy and permits
+MCP activity. MCP doesn't have a local preset equivalent to network policy.
+
+## Approve a server
+
+For an allowlist, approve both the server registration and its use-time
+capabilities. The following policy approves a remote server only when it is
+registered as `example` with the expected identity URL. It permits read-only
+tool calls, resource reads, and prompt retrieval from that registered server:
+
+```plaintext
+permit (principal, action == MCP::Action::"register", resource)
+when {
+  resource in MCP::Server::"example" &&
+  resource.identityURL == "https://mcp.example.com/mcp"
+};
+
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when {
+  resource in MCP::Server::"example" &&
+  resource.readOnly == true
+};
+
+permit (principal, action == MCP::Action::"readResource", resource)
+when { resource in MCP::Server::"example" };
+
+permit (principal, action == MCP::Action::"getPrompt", resource)
+when { resource in MCP::Server::"example" };
+```
+
+Matching both the name and identity URL establishes a canonical registration.
+It prevents a developer from registering another endpoint under the approved
+name or registering the approved endpoint under another name. Remove the
+resource or prompt permit if users don't need that capability.
+
+## Require confirmation with MCP elicitation
+
+Use `@requireApproval` to require per-request confirmation through MCP. When a
+request matches the annotated `permit`, the gateway sends an
+`elicitation/create` request to the same MCP client session that made the
+governed request. In a human-driven client, the person operating the agent sees
+the prompt and decides whether to proceed.
+
+The following policy requires confirmation for non-read-only tools on a server
+registered as `example`. Use it alongside any permits needed to register the
+server or use its other capabilities. The annotation string becomes the reason
+shown in the elicitation:
+
+```plaintext
+@requireApproval("non-read-only tool call")
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when {
+  resource in MCP::Server::"example" &&
+  resource.readOnly == false
+};
+```
+
+Tool annotations are supplied by the server and are advisory. `readOnly`
+defaults to `false` for tools that don't declare it, so this pattern requires
+confirmation for unannotated tools.
+
+The gateway handles a matching request as follows:
+
+```mermaid
+flowchart TD
+  request["Agent sends a governed MCP request"] --> evaluate["Gateway evaluates MCP policy"]
+  evaluate -->|"Normal permit"| forward["Forward request"]
+  evaluate -->|"No permit or matching forbid"| deny["Deny request"]
+  evaluate -->|"Permit with @requireApproval"| elicit["Send MCP elicitation to connected client"]
+  elicit --> confirm{"Client returns explicit confirmation?"}
+  confirm -->|"No, unsupported, or error"| deny
+  confirm -->|"Yes"| reevaluate["Re-evaluate with approval digest"]
+  reevaluate -->|"Allowed"| forward
+  reevaluate -->|"Denied or changed"| deny
+```
+
+The prompt identifies the server or gateway tool and includes the annotation
+reason. It doesn't include raw tool arguments. Each matching request requires a
+new confirmation. After confirmation, the gateway re-evaluates the request with
+a digest that binds the response to the evaluated authorization request.
+
+Use this mechanism as a confirmation guardrail for human-driven clients. It
+doesn't create administrator approval or separation of duties. An autonomous
+MCP client can respond to an in-protocol elicitation programmatically. Use
+`forbid` for operations that must never run.
+
+The request is denied if the originating client session can't handle MCP
+elicitation, the user declines, the elicitation fails, or re-evaluation doesn't
+allow the request. `sbx mcp add` can't present an elicitation, so a registration
+permit with `@requireApproval` results in a denial. Tool calls made from an
+execution context that can't relay an elicitation, including calls from inside
+`code-mode`, are also denied.
+
+## Withdraw server access
+
+To withdraw access from a server that broader rules permit, block it at
+registration and at use time. Registration policy controls future `sbx mcp add`
+operations, while use-time policy controls requests from servers that are
+already registered or loaded.
+
+Prevent future registrations of the server by matching its identity URL:
+
+```plaintext
+forbid (principal, action == MCP::Action::"register", resource)
+when { resource.identityURL == "https://mcp.example.com/mcp" };
+```
+
+Deny use-time requests for each registered name that refers to the server:
+
+```plaintext
+forbid (principal, action == MCP::Action::"invokeTool", resource)
+when { resource in MCP::Server::"example" };
+
+forbid (principal, action == MCP::Action::"readResource", resource)
+when { resource in MCP::Server::"example" };
+
+forbid (principal, action == MCP::Action::"getPrompt", resource)
+when { resource in MCP::Server::"example" };
+```
+
+The registration remains saved and can still be listed or loaded. These rules
+prevent another registration for the identity URL and deny governed use under
+the registered name. If the server was registered under other names, add
+use-time rules for those names as well.
+
+An OAuth authorization helper is a built-in gateway tool, not a child of the
+registered server. To prevent agents from starting authorization for the
+server, govern the helper separately:
+
+```plaintext
+forbid (principal, action == MCP::Action::"invokePrimordial", resource)
+when { resource in MCP::Primordial::"example-authorize" };
+```
+
+## Restrict host-run servers
+
+Local stdio servers run on the host, outside the sandbox VM. This includes
+explicit host commands and OCI-packaged stdio servers started with host Docker.
+For details about this boundary, see
+[Docker Engine isolation](../../security/isolation.md#docker-engine-isolation).
+
+In a blocklist policy that otherwise permits registration, deny both host-run
+server types:
+
+```plaintext
+forbid (principal, action == MCP::Action::"register", resource)
+when {
+  resource.type == "local-stdio" ||
+  resource.type == "container-stdio"
+};
+```
+
+`local-stdio` covers explicit commands, including commands that start a Docker
+container. `container-stdio` covers OCI-packaged stdio servers resolved from
+registry or manifest metadata.
+
+## Related information
+
+- Use [Policy concepts](../concepts.md#mcp-policies) for the MCP policy model.
+- Use the [MCP policy reference](../reference/mcp-policy.md) for exact action,
+  resource, attribute, context, and approval behavior.
+- Use [Organization policies](organization.md) to manage policy scope.
+- Use [Audit logs](../monitor-and-enforce/audit.md) to collect policy decision
+  records.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/network.md b/content/manuals/ai/sandboxes/governance/access-controls/network.md
new file mode 100644
index 000000000000..1223244da418
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/network.md
@@ -0,0 +1,60 @@
+---
+title: Network access policies
+linkTitle: Network access
+weight: 30
+description: Control outbound network access from Docker Sandboxes with local and organization policy rules.
+keywords: docker sandboxes, network access, network rules, governance, local policy, organization policy
+---
+
+Network access policies control outbound connections from sandboxes. Each
+policy contains one or more rules that allow the domains, IP ranges, and ports a
+workflow needs, or block destinations that should stay unavailable.
+
+You can configure network access in two places:
+
+- [Local policy](local.md), which applies to sandboxes on one developer machine
+  when organization governance is not active.
+- [Organization policies](organization.md), which apply centrally across an
+  organization or to selected teams.
+
+When organization governance is active, organization network rules replace
+local rules. Local rules are inactive until organization governance no longer
+applies.
+
+## Rule syntax
+
+Network rules use the actions `connect:tcp` and `connect:udp`. Resources are
+hostnames, CIDR ranges, ports, or hostnames with ports.
+
+Examples:
+
+- `api.example.com`
+- `*.example.com`
+- `**.example.com`
+- `example.com:443`
+- `10.0.0.0/8`
+
+For exact wildcard behavior and CIDR support, see
+[Network rules](../concepts.md#network-rules).
+
+## Local network rules
+
+Use `sbx policy allow network` and `sbx policy deny network` to manage local
+network rules:
+
+```console
+$ sbx policy allow network api.example.com
+$ sbx policy deny network ads.example.com
+```
+
+For presets, sandbox-scoped rules, testing, and troubleshooting, see
+[Local policy](local.md).
+
+## Organization network rules
+
+Organization network rules belong to policies that can apply to the whole
+organization or to selected teams. For setup steps and team scoping, see
+[Organization policies](organization.md).
+
+Use [Monitoring policies](../monitor-and-enforce/monitoring.md) to inspect
+which network rules are active on a developer machine.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/organization.md b/content/manuals/ai/sandboxes/governance/access-controls/organization.md
new file mode 100644
index 000000000000..589b8edd6479
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/organization.md
@@ -0,0 +1,154 @@
+---
+title: Organization policies
+linkTitle: Org policies
+weight: 20
+description: Centrally manage sandbox network, filesystem, and MCP policies for your organization.
+keywords: docker sandboxes, governance, organization policy, AI governance, Docker Home, network access, filesystem access, mcp policy
+aliases:
+  - /ai/sandboxes/security/governance/
+  - /ai/sandboxes/governance/org/
+---
+
+[Local policies](local.md) give individual developers control over what their
+sandboxes can access. Organization policy moves that control to the admin level:
+organization policies 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 Docker Home UI. For
+programmatic management of network and filesystem policies, use the
+[Governance API](/reference/api/ai-governance/).
+
+By default, only organization
+[owners](/manuals/enterprise/security/roles-and-permissions/core-roles.md) can
+view and manage AI Governance policies. To let someone other than an owner
+manage policies, create a
+[custom role](/manuals/enterprise/security/roles-and-permissions/custom-roles.md)
+with the **Governance** permissions and assign it to a user or team.
+
+> [!NOTE]
+> Sandbox organization governance is available on a separate paid
+> subscription.
+> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+> to request access.
+
+## Create a policy
+
+Manage policies from the **AI Platform** section in the left-hand navigation
+of [Docker Home](https://app.docker.com).
+
+To create a policy:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization.
+1. In the left-hand navigation, expand **AI Platform** and select
+   **Network access**, **Filesystem access**, or **MCP 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
+   [Scope policies to teams](#scope-policies-to-teams).
+1. Define the policy rules. For network and filesystem policies, select
+   **Add rule** for each rule. For MCP policies, enter Cedar statements in the
+   policy editor. For syntax and examples, use the relevant access-control page
+   in [Choose a policy type](#choose-a-policy-type).
+
+Existing policies are listed with their name, scope, rule count, and last
+update. Use the action menu (⋮) to edit or delete a policy.
+
+## Choose a policy type
+
+Organization policies are managed by access surface. Use the access-control
+pages for syntax, examples, and enforcement details:
+
+- [Network access policies](network.md): control outbound network access from
+  sandboxes.
+- [Filesystem access policies](filesystem.md): control which host paths
+  sandboxes can mount as workspaces.
+- [MCP access policies](mcp.md): control MCP server registration, tool calls,
+  resources, prompts, and approval gates with Cedar policy.
+
+When organization governance is active, local and kit-defined rules are not
+evaluated. To see which rules are active on a developer machine, use
+[Monitoring policies](../monitor-and-enforce/monitoring.md).
+
+## 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. 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
+it only to members of the teams you select.
+
+### Before you start
+
+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:
+
+- 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
+  organization. Group mapping creates teams that don't already exist and keeps
+  their membership in step with your IdP groups.
+
+Because policies apply by team, a user's policies update automatically as their
+team membership changes, including changes synced from your IdP.
+
+### How scoped policies combine
+
+A user is governed by all of their
+[effective policies](../concepts.md#policy-scope): every org-wide policy, plus
+the team-scoped policies for the teams they belong to. Use org-wide policies
+for guardrails that must apply everywhere, and team-scoped policies for access
+that only some teams need.
+
+For precedence between local and organization policies, and for how allow and
+deny rules combine, see [Policy concepts](../concepts.md).
+
+## Troubleshooting
+
+### Policy changes not taking effect
+
+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` command.
+
+> [!WARNING]
+> `sbx policy reset` deletes all locally configured policy rules. The command
+> prompts for confirmation before proceeding.
+
+#### Enforcement timing by policy type
+
+Policy types differ in when a change takes effect after it reaches the
+developer machine:
+
+- Network policy is evaluated on every outbound request. Once a policy
+  change has synced to the developer's machine (up to 5 minutes), it applies
+  immediately to subsequent requests.
+
+- Filesystem policy is only checked when a workspace is mounted — that
+  is, when a sandbox is created. Once a sandbox is running, changing the
+  filesystem policy has no effect on that sandbox. The sandbox continues to
+  access the previously allowed path until it is removed and a new one is
+  created.
+
+- MCP registration policy is evaluated when a server is registered with
+  `sbx mcp add`. Changing registration rules doesn't remove existing
+  registrations or stop an already-loaded server by itself.
+
+- MCP use-time policy is evaluated by the MCP gateway when a sandbox makes a
+  governed MCP request, such as a tool call, resource read, prompt retrieval,
+  or built-in gateway tool call. Once a policy change has synced, use-time
+  rules apply to subsequent governed MCP requests through the gateway.
+
+To apply a filesystem policy change immediately, remove the running sandbox
+and create a new one. To prevent use of an MCP server that is already registered
+or loaded, add use-time rules for the registered server name. For examples, see
+[Withdraw server access](mcp.md#withdraw-server-access).
diff --git a/content/manuals/ai/sandboxes/governance/concepts.md b/content/manuals/ai/sandboxes/governance/concepts.md
index 2b59e6b2e7aa..28095c159adc 100644
--- a/content/manuals/ai/sandboxes/governance/concepts.md
+++ b/content/manuals/ai/sandboxes/governance/concepts.md
@@ -1,8 +1,8 @@
 ---
 title: Policy concepts
-weight: 5
+weight: 10
 description: The resource model, rule syntax, and evaluation logic behind Docker sandbox governance.
-keywords: docker sandboxes, policy concepts, rule syntax, network rules, filesystem rules, precedence, rule evaluation
+keywords: docker sandboxes, policy concepts, rule syntax, network rules, filesystem rules, mcp policy, cedar policy, precedence, rule evaluation
 ---
 
 ## Resource model
@@ -15,7 +15,8 @@ Policies exist at two levels:
 
 - **Local**: configured per machine using the `sbx policy` CLI. Applies to
   sandboxes on that machine only.
-- **Organization**: configured in Docker Home or via the
+- **Organization**: configured in Docker Home. Network and filesystem policies
+  can also be managed 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).
@@ -30,8 +31,10 @@ A **rule** is the unit of access control within a policy. Each rule has:
 - **Resources**: the targets the rule matches against
 - **Decision**: `allow` or `deny`
 
-Rules are grouped by domain: all rules in a policy must share the same domain,
-either `network` or `filesystem`.
+Rules are grouped by domain. Network and filesystem rules in a policy must
+share the same domain, either `network` or `filesystem`. MCP policies use Cedar
+statements written in the `MCP` namespace instead of the network and filesystem
+rule format.
 
 ## Policy scope
 
@@ -75,6 +78,9 @@ need to match the root domain and its subdomains.
 Both IPv4 and IPv6 notation are supported: `10.0.0.0/8`, `192.168.1.0/24`,
 `2001:db8::/32`.
 
+For local and organization policy configuration, see
+[Network access policies](access-controls/network.md).
+
 ### Filesystem rules
 
 Filesystem rules use the actions `read` and `write`. Resources are host paths
@@ -115,6 +121,31 @@ Use `**` to match a directory tree recursively. A single `*` matches within one
 path segment and won't cross a path separator. For example, `~/**` matches all
 paths under the home directory, while `~/*` matches only its direct children.
 
+For organization policy configuration and enforcement details, see
+[Filesystem access policies](access-controls/filesystem.md).
+
+### MCP policies
+
+MCP policies control Model Context Protocol activity made available to a
+sandbox through Docker's [MCP gateway](../mcp-gateway.md). They are
+organization policies written in Cedar using the `MCP` namespace, rather than
+the network and filesystem rule format.
+
+MCP policy applies when a developer registers a server and when an agent uses
+the MCP gateway. Registration rules control future `sbx mcp add` operations.
+Use-time rules control tool calls, gateway meta-tools, resource reads, and
+prompt retrieval from servers that are already registered or loaded.
+
+Governed MCP activity is default deny: a request is blocked unless a matching
+`permit` allows it. A matching `forbid` overrides any `permit`, including a
+permit that requires approval. Policy scope supplies the principal, so use
+organization or team scope instead of matching users, teams, tenants, or roles
+in Cedar.
+
+For representative policies, see [MCP access policies](access-controls/mcp.md).
+For exact action, resource, context, and approval behavior, see the
+[MCP policy reference](reference/mcp-policy.md).
+
 ## Rule evaluation
 
 When organization governance is active, the rules from all of a user's
@@ -125,7 +156,8 @@ each request, following two principles:
   regardless of any matching allow rules.
 - 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.
+  host path can't be mounted unless a filesystem rule allows it. MCP activity is
+  blocked unless an MCP `permit` 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
@@ -146,7 +178,8 @@ whether your organization has governance enabled:
 - Organization governance active: organization rules apply across all developer
   machines, and local and kit-defined rules are not evaluated. `sbx policy ls`
   hides these inactive rules by default; see
-  [Monitoring](monitoring.md#showing-inactive-rules) for how to list them.
+  [Monitoring](monitor-and-enforce/monitoring.md#showing-inactive-rules) for how
+  to list them.
 
 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/monitor-and-enforce/_index.md b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/_index.md
new file mode 100644
index 000000000000..6db42c60ca4c
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/_index.md
@@ -0,0 +1,16 @@
+---
+title: Monitor and enforce
+weight: 30
+description: Inspect active sandbox governance rules, collect audit records, and enforce organization sign-in.
+keywords: docker sandboxes, governance monitoring, audit logs, sign-in enforcement, policy enforcement
+---
+
+After policies are configured, use monitoring, audit records, and sign-in
+enforcement to verify how governance behaves across developer machines.
+
+- [Monitoring policies](monitoring.md): inspect active policy rules and monitor
+  sandbox network traffic.
+- [Audit logs](audit.md): collect structured records of policy decisions for
+  SIEM ingestion and compliance.
+- [Sign-in enforcement](sign-in-enforcement.md): require users to sign in as
+  members of approved Docker organizations.
diff --git a/content/manuals/ai/sandboxes/governance/audit.md b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/audit.md
similarity index 90%
rename from content/manuals/ai/sandboxes/governance/audit.md
rename to content/manuals/ai/sandboxes/governance/monitor-and-enforce/audit.md
index ceaf67dbc0df..7434ea20d2ae 100644
--- a/content/manuals/ai/sandboxes/governance/audit.md
+++ b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/audit.md
@@ -1,9 +1,11 @@
 ---
 title: Audit logging
 linkTitle: Audit logs
-weight: 28
+weight: 20
 description: Capture a structured, durable record of every sandbox policy decision for SIEM ingestion and compliance.
-keywords: docker sandboxes, audit log, audit logging, policy decision, SIEM, compliance, jsonl, splunk, filebeat
+keywords: docker sandboxes, audit log, audit logging, policy decision, MCP policy, SIEM, compliance, jsonl, splunk, filebeat
+aliases:
+  - /ai/sandboxes/governance/audit/
 ---
 
 The sandbox daemon records a structured audit event for every policy decision
@@ -21,10 +23,11 @@ Docker doesn't collect or ingest audit data.
 
 Audit logging is active only while your organization enforces a centralized
 governance policy. The subscription alone doesn't produce records. If your
-organization hasn't configured and enforced an [organization policy](org.md),
-the daemon writes no audit logs. To confirm governance is active, run `sbx
-policy ls` — the output begins with a `Policy rules` header listing a
-`Governance  Managed by <org>` line when an organization policy is in effect.
+organization hasn't configured and enforced an
+[organization policy](../access-controls/organization.md), the daemon writes no
+audit logs. To confirm governance is active, run `sbx policy ls` — the output
+begins with a `Policy rules` header listing a `Governance  Managed by <org>`
+line when an organization policy is in effect.
 
 Audit logging complements [monitoring](monitoring.md). Monitoring with `sbx
 policy ls` and `sbx policy log` is for live, interactive debugging. Audit
@@ -40,6 +43,10 @@ The daemon writes two categories of record:
   Evaluation records share the run's `audit_session_id`, so you can correlate
   every decision back to a single daemon session.
 
+When MCP policy enforcement is active, MCP evaluations use the same evaluation
+record category. The action and resource values identify the MCP request, such
+as a tool call or resource read.
+
 A network evaluation record looks like this:
 
 ```json
@@ -84,7 +91,7 @@ Common fields include:
 | `resource_id`      | The target of the evaluation, such as a host and port.                                                       |
 | `decision`         | `AUDIT_DECISION_ALLOW` or `AUDIT_DECISION_DENY`.                                                             |
 | `deny_reason`      | Why a denied request was blocked. Present on deny decisions.                                                 |
-| `agent`            | The AI agent driving the sandbox (for example, `claude`, `codex`). Omitted when the agent is unknown.       |
+| `agent`            | The AI agent driving the sandbox (for example, `claude`, `codex`). Omitted when the agent is unknown.        |
 
 Each record is attributed to the signed-in Docker user and the organization
 whose governance policy is in effect.
diff --git a/content/manuals/ai/sandboxes/governance/monitoring.md b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/monitoring.md
similarity index 85%
rename from content/manuals/ai/sandboxes/governance/monitoring.md
rename to content/manuals/ai/sandboxes/governance/monitor-and-enforce/monitoring.md
index f4c1291d0119..39d84890e15e 100644
--- a/content/manuals/ai/sandboxes/governance/monitoring.md
+++ b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/monitoring.md
@@ -1,8 +1,10 @@
 ---
 title: Monitoring policies
-weight: 25
+weight: 10
 description: Inspect active policy rules and monitor sandbox network traffic with sbx policy ls and sbx policy log.
 keywords: docker sandboxes, policy monitoring, sbx policy ls, sbx policy log, network traffic, policy debugging
+aliases:
+  - /ai/sandboxes/governance/monitoring/
 ---
 
 `sbx policy ls` and `sbx policy log` give you a combined view of all active
@@ -27,7 +29,7 @@ The columns are:
 - `POLICY`: the policy name.
 - `SOURCE`: where the policy came from. `local` means your local configuration
   — a preset or rules you added with `sbx policy`. `kit` means a
-  [kit](../customize/kits.md#control-network-access). `org` means your
+  [kit](../../customize/kits.md#control-network-access). `org` means your
   organization.
 - `APPLIES TO`: which sandboxes the policy applies to. `all` means the policy
   is global. `sandbox:<name>` scopes it to a single sandbox; a profile name
@@ -113,7 +115,7 @@ A writable workspace mount must be allowed by both a `filesystem:read` and a
 `filesystem:write` rule; a read-only mount needs only `filesystem:read`. The
 default local policy allows read and write access to all paths, shown as the
 two `default-fs-*` rules above. For the rule syntax and path patterns, see
-[Policy concepts](concepts.md#filesystem-rules).
+[Policy concepts](../concepts.md#filesystem-rules).
 
 ## Monitoring traffic
 
@@ -135,13 +137,13 @@ my-sandbox   network  app.example.com        browser-open
 
 The `PROXY` column shows how the request left the sandbox:
 
-| Value | Description |
-| ----- | ----------- |
-| `forward` | Routed through the forward proxy. Supports [credential injection](../security/credentials.md). |
-| `forward-bypass` | Routed through the forward proxy without credential injection. |
-| `transparent` | Intercepted by the transparent proxy. Policy is enforced but credential injection is not available. |
-| `network` | Non-HTTP traffic (raw TCP, UDP, ICMP). TCP can be allowed with a policy rule; UDP and ICMP are always blocked. |
-| `browser-open` | A sandbox process requested opening a URL in the host browser. Policy is enforced before opening the URL. |
+| Value            | Description                                                                                                    |
+| ---------------- | -------------------------------------------------------------------------------------------------------------- |
+| `forward`        | Routed through the forward proxy. Supports [credential injection](../../security/credentials.md).              |
+| `forward-bypass` | Routed through the forward proxy without credential injection.                                                 |
+| `transparent`    | Intercepted by the transparent proxy. Policy is enforced but credential injection is not available.            |
+| `network`        | Non-HTTP traffic (raw TCP, UDP, ICMP). TCP can be allowed with a policy rule; UDP and ICMP are always blocked. |
+| `browser-open`   | A sandbox process requested opening a URL in the host browser. Policy is enforced before opening the URL.      |
 
 The `RULE` column identifies the policy rule that matched the request. The
 `REASON` column includes extra context when the daemon records one.
diff --git a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/sign-in-enforcement.md
similarity index 95%
rename from content/manuals/ai/sandboxes/governance/sign-in-enforcement.md
rename to content/manuals/ai/sandboxes/governance/monitor-and-enforce/sign-in-enforcement.md
index 74c72d44c008..4a964dc3d26e 100644
--- a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md
+++ b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/sign-in-enforcement.md
@@ -1,9 +1,11 @@
 ---
 title: Sign-in enforcement
 linkTitle: Sign-in enforcement
-weight: 22
+weight: 30
 description: Require Docker Sandboxes users to sign in as members of your organization, enforced through endpoint management.
 keywords: docker sandboxes, sign-in enforcement, organization enforcement, sbx login, MDM, configuration profile, registry key, allowedOrgs
+aliases:
+  - /ai/sandboxes/governance/sign-in-enforcement/
 ---
 
 Sign-in enforcement restricts Docker Sandboxes to users who are members of
@@ -13,8 +15,9 @@ membership after the user authenticates. If the check fails, credentials are
 immediately revoked and the user can't run sandboxes.
 
 Without this enforcement, a developer can sign in with a personal account and
-bypass organization [governance policies](org.md). Sign-in enforcement closes
-that gap at the endpoint, where users can't override it.
+bypass organization [governance policies](../access-controls/organization.md).
+Sign-in enforcement closes that gap at the endpoint, where users can't override
+it.
 
 > [!NOTE]
 > Sign-in enforcement is part of Docker's AI Governance offering.
@@ -261,9 +264,10 @@ For access, contact ACME IT Security:
 
 ## Related pages
 
-- [Organization policy](org.md): centrally manage sandbox network and
-  filesystem rules
-- [Governance overview](_index.md): how local and organization governance fit
+- [Organization policies](../access-controls/organization.md): centrally manage
+  sandbox network, filesystem, and MCP access controls from the Docker Admin
+  Console
+- [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):
   the equivalent control for Docker Desktop
diff --git a/content/manuals/ai/sandboxes/governance/org.md b/content/manuals/ai/sandboxes/governance/org.md
deleted file mode 100644
index 54dda20e710e..000000000000
--- a/content/manuals/ai/sandboxes/governance/org.md
+++ /dev/null
@@ -1,220 +0,0 @@
----
-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, 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 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 Docker Home UI or
-programmatically using the [Governance API](/reference/api/ai-governance/).
-
-By default, only organization
-[owners](/manuals/enterprise/security/roles-and-permissions/core-roles.md) can
-view and manage AI Governance policies. To let someone other than an owner
-manage policies, create a
-[custom role](/manuals/enterprise/security/roles-and-permissions/custom-roles.md)
-with the **Governance** permissions and assign it to a user or team.
-
-> [!NOTE]
-> Sandbox organization governance is available on a separate paid
-> subscription.
-> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
-> to request access.
-
-## Create a policy
-
-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. 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
-   [Scope policies to teams](#scope-policies-to-teams).
-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
-update. Use the action menu (⋮) to edit or delete a policy.
-
-## Network policies
-
-### Configuring org-level network rules
-
-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).
-
-When organization governance is active, local network rules are not evaluated.
-The organization policy is the only policy in effect. `sbx policy ls` hides
-these inactive local rules by default. See
-[Monitoring](monitoring.md#showing-inactive-rules) for how to list them and read
-the rule view.
-
-## 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.
-
-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 and how read and write access combine to allow a
-mount, 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. 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
-it only to members of the teams you select.
-
-### Before you start
-
-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:
-
-- 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
-  organization. Group mapping creates teams that don't already exist and keeps
-  their membership in step with your IdP groups.
-
-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 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).
-
-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.
-
-In practice, three patterns cover most layering:
-
-- Deny by default: leave a domain out of every allow rule to keep it blocked.
-- Allow when needed: add a team-scoped allow to grant an exception.
-- Explicit deny: deny a domain outright when no team should ever reach it.
-
-The examples that follow show each pattern.
-
-### Grant one team access to a blocked domain
-
-Because access is [denied by default](concepts.md#rule-evaluation), you don't
-need an explicit deny to keep a domain off-limits. Leaving it out of every allow
-rule is enough. To give a single team access to a domain no one else can reach:
-
-1. Don't add an allow rule for the domain at the organization level. Default
-   deny keeps it blocked for everyone.
-1. Create a team-scoped policy that allows the domain, and scope it to that team.
-
-Only members of that team can reach the domain. Everyone else is still blocked
-by default.
-
-### Block a domain everywhere as a guardrail
-
-Use an explicit org-wide deny when a domain must be off-limits to everyone,
-including teams that have broad allow rules. Because deny wins, an org-wide deny
-on `**.example.com` blocks `example.com` and every subdomain for all members,
-and no team-scoped allow can grant access to it.
-
-Reserve explicit deny rules for domains you want to block outright. For
-everything else, rely on default deny and add allow rules only where access is
-needed.
-
-### An exact deny doesn't cover subdomains
-
-A deny rule matches only the hostnames its pattern matches. A deny on the exact
-hostname `example.com` doesn't match `api.example.com`, so a team-scoped allow
-on `api.example.com` still grants that team access. The org-wide deny and the
-team allow apply to different hostnames, so they never conflict.
-
-To block a domain and all its subdomains, deny `**.example.com` instead. With
-that pattern, deny wins over any team-scoped allow on a subdomain. See
-[Hostname patterns](concepts.md#network-rules) for how exact hostnames and
-wildcards match.
-
-## Precedence
-
-When organization governance is active, local rules are not evaluated. Only
-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
-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, 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`
-command.
-
-> [!WARNING]
-> `sbx policy reset` deletes all locally configured policy rules. The command
-> prompts for confirmation before proceeding.
-
-#### Network versus filesystem enforcement timing
-
-Network policy and filesystem policy differ in when a change takes effect:
-
-- Network policy is evaluated on every outbound request. Once a policy
-  change has synced to the developer's machine (up to 5 minutes), it applies
-  immediately to subsequent requests.
-
-- Filesystem policy is only checked when a workspace is mounted — that
-  is, when a sandbox is created. Once a sandbox is running, changing the
-  filesystem policy has no effect on that sandbox. The sandbox continues to
-  access the previously allowed path until it is removed and a new one is
-  created.
-
-To apply a filesystem policy change immediately, remove the running sandbox
-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 uses `**` rather than `*`. A
-single `*` doesn't match across directory separators.
diff --git a/content/manuals/ai/sandboxes/governance/reference/_index.md b/content/manuals/ai/sandboxes/governance/reference/_index.md
new file mode 100644
index 000000000000..819feab16011
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/reference/_index.md
@@ -0,0 +1,15 @@
+---
+title: Reference
+weight: 40
+description: Reference material for Docker AI Governance policy APIs and policy syntax.
+keywords: docker sandboxes, governance reference, governance API, policy reference
+---
+
+Use reference material when you need API details or exact policy syntax.
+
+- [Policy concepts](../concepts.md): resource model, rule syntax, policy
+  evaluation, and precedence.
+- [AI Governance API](/reference/api/ai-governance/): HTTP API reference for
+  network and filesystem organization policies.
+- [MCP policy reference](mcp-policy.md): Docker MCP policy actions, resources,
+  attributes, context fields, and approval behavior.
diff --git a/content/manuals/ai/sandboxes/governance/api.md b/content/manuals/ai/sandboxes/governance/reference/api.md
similarity index 67%
rename from content/manuals/ai/sandboxes/governance/api.md
rename to content/manuals/ai/sandboxes/governance/reference/api.md
index dcbb778b8aee..36e6297f165b 100644
--- a/content/manuals/ai/sandboxes/governance/api.md
+++ b/content/manuals/ai/sandboxes/governance/reference/api.md
@@ -2,7 +2,8 @@
 title: AI Governance API
 linkTitle: API reference
 description: Programmatic management of Docker AI Governance policies and rules via HTTP+JSON.
-weight: 30
+keywords: docker sandboxes, AI Governance API, governance API, policy API, organization policies
+weight: 10
 build:
   render: never
 sidebar:
diff --git a/content/manuals/ai/sandboxes/governance/reference/mcp-policy.md b/content/manuals/ai/sandboxes/governance/reference/mcp-policy.md
new file mode 100644
index 000000000000..15900f4c909d
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/reference/mcp-policy.md
@@ -0,0 +1,182 @@
+---
+title: MCP policy reference
+linkTitle: MCP policy
+weight: 20
+description: Reference for Docker MCP policy actions, resources, attributes, context fields, and approval behavior.
+keywords: docker sandboxes, MCP policy, Cedar policy, MCP actions, MCP resources, requireApproval, AI Governance
+---
+
+MCP policies are organization policies written in Cedar using Docker's `MCP`
+namespace. This reference defines the Docker-specific policy surface for Model
+Context Protocol (MCP) activity made available to sandboxes through Docker's
+[MCP gateway](../../mcp-gateway.md).
+
+Use this reference with [MCP access policies](../access-controls/mcp.md) for
+common policy patterns. For the Cedar language, see the
+[Cedar documentation](https://docs.cedarpolicy.com/).
+
+## Evaluation model
+
+Cedar evaluates MCP requests against a principal, action, resource, and context.
+For Docker MCP policies, policy scope supplies the principal. Write policies
+against the action, resource, and context. Clauses that reference principal
+attributes, such as `principal in ...`, `principal.role`, or
+`principal.tenant`, don't match.
+
+Governed MCP activity is default deny. A request is blocked unless a matching
+`permit` allows it. A matching `forbid` overrides any `permit`, including a
+permit annotated with `@requireApproval`.
+
+For details about when Docker Sandboxes evaluates MCP policies for a user, see
+[Govern the server lifecycle](../access-controls/mcp.md#govern-the-server-lifecycle).
+
+An actionless `permit` matches every MCP action that reaches Cedar evaluation:
+
+```plaintext
+permit (principal, action, resource);
+```
+
+## Actions
+
+| Action              | Governs                   | Notes                                                                                                |
+| ------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------- |
+| `register`          | MCP server registration   | Remote server registration needs an explicit `permit`. Use server attributes to scope registration.  |
+| `invokeTool`        | MCP tool calls            | Most tool access policies target this action.                                                        |
+| `invokePrimordial`  | Gateway meta-tool calls   | Applies to built-in gateway tools such as `mcp-exec`, `code-mode`, and OAuth authorization helpers.  |
+| `readResource`      | MCP resource reads        | Rules match `MCP::Resource` and `resource.uri`.                                                      |
+| `getPrompt`         | MCP prompt retrieval      | Rules match `MCP::Prompt` and `resource.name`.                                                       |
+| `listTools`         | MCP tool listing          | Defined in the schema but not Cedar-gated. Tool listings can include tools denied at invocation.     |
+| `listResources`     | MCP resource listing      | Defined in the schema but not Cedar-gated. Resource listings can include resources denied by policy. |
+| `subscribeResource` | MCP resource subscription | Defined in the schema but not Cedar-gated.                                                           |
+
+## Resources
+
+Match resources with the MCP entity type and attributes for the request.
+
+| Entity            | Match with             | Notes                                                                                                                            |
+| ----------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| `MCP::Server`     | Registered server name | The server URL or source is the `resource.identityURL` attribute, not the entity ID.                                             |
+| `MCP::Tool`       | Bare tool name         | Use `resource.name`. Display prefixes aren't included. A bare-name match applies to every server exposing a tool with that name. |
+| `MCP::Resource`   | Resource URI           | Use `resource.uri`.                                                                                                              |
+| `MCP::Prompt`     | Prompt name            | Use `resource.name`.                                                                                                             |
+| `MCP::Primordial` | Gateway meta-tool name | Match a specific primordial with an entity reference.                                                                            |
+
+Examples:
+
+```plaintext
+resource in MCP::Server::"notion"
+resource.name == "move_file"
+resource.uri like "*/docs/*"
+resource in MCP::Primordial::"code-mode"
+```
+
+## Resource attributes
+
+Tool annotation attributes come from MCP tool annotations or catalog metadata
+and are advisory.
+
+| Attribute                  | Applies to        | Notes                                                                                                                                                 |
+| -------------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `resource.name`            | Tools and prompts | For tools, this is the bare tool name, not a display-prefixed name.                                                                                   |
+| `resource.uri`             | Resources         | Use with string operators such as `like`.                                                                                                             |
+| `resource.readOnly`        | Tools             | Defaults to `false` when a tool doesn't declare it.                                                                                                   |
+| `resource.destructive`     | Tools             | Defaults to `true` when a tool doesn't declare it.                                                                                                    |
+| `resource.idempotent`      | Tools             | Defaults to `false` when a tool doesn't declare it.                                                                                                   |
+| `resource.openWorld`       | Tools             | Defaults to `true` when a tool doesn't declare it.                                                                                                    |
+| `resource.category`        | Tools             | Server or catalog category copied onto the tool resource. Tools don't self-declare categories.                                                        |
+| `resource.type`            | Servers           | Use for server registration rules. `local-stdio` identifies explicit host commands, and `container-stdio` identifies OCI-packaged stdio servers.      |
+| `resource.identityURL`     | Servers           | The server URL or source. Use for server registration rules.                                                                                          |
+| `resource.requiresOAuth`   | Servers           | Use for server registration rules.                                                                                                                    |
+| `resource.requiresNetwork` | Servers           | Use for server registration rules.                                                                                                                    |
+| `resource.command`         | Servers           | Local stdio server command, such as `npx` or `docker`, when available. Empty for remote servers and registrations that don't include command details. |
+| `resource.args`            | Servers           | Local stdio server arguments when available. This is a set, so `.contains()` can match values. Empty when no command details are available.           |
+
+Use `like` for string attributes. In Cedar, `like` uses `*` as its wildcard,
+matches the full string, treats `?` as a literal character, and treats `\*` as
+a literal asterisk.
+
+Use `.contains()` only on set attributes, such as `resource.args`. On string
+attributes, use `like`.
+
+## Context fields
+
+| Field                  | Notes                                                                                             |
+| ---------------------- | ------------------------------------------------------------------------------------------------- |
+| `context.request_time` | Bound at each enforcement point. Use it for time-window rules.                                    |
+| `context.oauth_scopes` | OAuth scopes for the caller. Present as a set, even when empty.                                   |
+| `context.args`         | Tool-call arguments for `invokeTool`. Present when arguments are available as a supported object. |
+
+Guard tool-call argument rules with `context has args` and a field check:
+
+```plaintext
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when {
+  resource.name == "approve_expense" &&
+  context has args &&
+  context.args has amount &&
+  context.args.amount <= 500
+};
+```
+
+A `permit` gated on missing arguments doesn't match, so the request falls to
+default deny. A `forbid` gated on missing arguments doesn't match, so it
+doesn't block the request.
+
+Only object-shaped tool arguments are represented in `context.args`.
+Unsupported, malformed, or too deeply nested arguments are omitted.
+
+## Approval annotation
+
+Use `@requireApproval("reason")` on a `permit` statement to require in-session
+confirmation through MCP elicitation before a matching request runs:
+
+```plaintext
+@requireApproval("write tool call")
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when { resource.readOnly == false };
+```
+
+When a request matches the annotated `permit` and no `forbid` overrides it, the
+policy engine returns an approval-required outcome. The annotation string is
+shown as the elicitation reason. An approval-required outcome takes precedence
+over a normal `permit`. A matching `forbid` denies the request without an
+elicitation.
+
+For the request flow and trust model, see
+[Require confirmation with MCP elicitation](../access-controls/mcp.md#require-confirmation-with-mcp-elicitation).
+
+Approval requires a client session that can present an MCP elicitation request
+to the user. If the request can't be presented for approval, the request is
+denied. Approval is an in-session confirmation, not an out-of-band approval
+workflow. Each confirmation applies to one authorization request. After the
+client confirms, the gateway re-evaluates the request with an approval digest.
+
+`sbx mcp add` can't present an elicitation request. A registration permit with
+`@requireApproval` therefore results in a denial.
+
+Only the exact annotation name `@requireApproval` applies approval behavior.
+Other annotation names, such as `@requireConsent` or `@requireConfirmation`,
+don't require approval.
+
+## Limitations
+
+- Tool and resource listing actions aren't Cedar-gated. Listings can include
+  entries that a policy denies when the sandbox tries to use them.
+- Approval-gated requests are denied when the execution context can't relay an
+  MCP elicitation to the originating client. This includes tool calls made from
+  inside `code-mode`.
+- Registration policy is evaluated when a server is registered. It doesn't
+  remove existing registrations or stop an already-loaded server by itself.
+  Govern existing registrations with use-time rules such as `invokeTool`,
+  `readResource`, and `getPrompt`.
+- Server command and argument rules using `resource.command` or `resource.args`
+  apply only when the resolved server registration includes local stdio command
+  details. Remote servers and metadata-resolved local servers can have empty
+  values for those attributes. Use `resource.type` to match the `local-stdio`
+  and `container-stdio` server classes.
+- Principal-based rules don't take effect. Use organization and team policy
+  scope to target users.
+- Server groups aren't supported in MCP policy. Reference servers individually.
+- Tool categories aren't self-declared by MCP tools. When available,
+  `resource.category` is server or catalog metadata copied onto the tool
+  resource.
diff --git a/content/manuals/ai/sandboxes/mcp-gateway.md b/content/manuals/ai/sandboxes/mcp-gateway.md
new file mode 100644
index 000000000000..12dae44c7007
--- /dev/null
+++ b/content/manuals/ai/sandboxes/mcp-gateway.md
@@ -0,0 +1,320 @@
+---
+title: MCP gateway
+description: Register MCP servers, authorize OAuth-backed servers, and connect MCP tools to Docker Sandboxes.
+keywords: docker sandboxes, sbx, MCP gateway, Model Context Protocol, MCP servers, sbx mcp, static MCP, OAuth
+weight: 50
+---
+
+Docker Sandboxes includes an MCP gateway for connecting agents to Model Context
+Protocol servers. The gateway gives the agent inside the sandbox one MCP
+endpoint, while `sbx` manages the registered servers, OAuth credentials, and
+sandbox lifecycle on the host.
+
+This is different from configuring an MCP server directly in an agent such as
+Claude Code. Direct MCP setup configures that agent's own MCP client. With
+Docker Sandboxes, you register MCP servers once on the host, and the sandbox
+gateway exposes them to supported agents inside isolated sandboxes. That
+host-managed gateway provides a single path for credentials, explicit server
+loading, live updates, and organization governance.
+
+> [!NOTE]
+> The Docker Sandboxes MCP gateway is separate from the Docker Desktop MCP
+> Toolkit. You don't need the Docker Desktop MCP Toolkit to use `sbx mcp`, and
+> MCP Toolkit server settings aren't shared with Docker Sandboxes.
+
+## Prerequisites
+
+- Sign in with `sbx login`.
+- Use an agent integration that configures MCP at startup: Claude Code, Codex,
+  Gemini, Kiro, or OpenCode.
+- For remote servers that require OAuth, use MCP servers that support OAuth
+  Dynamic Client Registration.
+- For `--local --url` registrations that resolve to OCI packages, use a host
+  with Docker installed and running. Docker is also required for explicit
+  `--command docker ...` registrations.
+
+## Quick start
+
+Start by registering one MCP server on the host:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+```
+
+If the server requires OAuth, `sbx` opens an authorization flow before it stores
+the registration. After registration, verify that the server is registered:
+
+```console
+$ sbx mcp ls
+NAME                 TYPE     URL/COMMAND
+notion               remote   https://mcp.notion.com/mcp
+```
+
+Then start a sandbox and expose the registered server:
+
+```console
+$ sbx run claude --name mcp-demo --static-mcp notion
+```
+
+The sandbox starts with an MCP gateway and pre-loads the `notion` server. The
+registration remains on the host and can be reused by other sandboxes.
+
+## Register an MCP server
+
+`sbx mcp add` registers an MCP server by name. The registration records the
+server definition on the host. It doesn't attach the server to a sandbox by
+itself. To expose a registered server to a sandbox, pass it with
+[`--static-mcp`](#expose-servers-at-sandbox-creation) when you create the
+sandbox, or use [`sbx mcp load`](#add-a-server-to-a-running-sandbox) for a
+sandbox that's already running.
+
+Server names can contain letters, numbers, dots, hyphens, and underscores.
+
+The `--url` flag can point to different kinds of input. The execution location
+depends on what you register:
+
+- A remote endpoint URL identifies a running MCP server. The server runs
+  remotely, and the sandbox gateway connects to it.
+- A metadata URL with `--local` returns a registry entry, `server.json`, or
+  `server.yaml` that describes an OCI-packaged stdio server. `sbx` resolves the
+  image and runs it on the host with Docker.
+- An explicit command runs on the host as a stdio MCP server.
+
+Local stdio servers run on the host, not inside the sandbox. The agent inside
+the sandbox connects only to the MCP gateway.
+
+### Remote endpoint URL
+
+For a remote MCP endpoint, pass the server URL:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+$ sbx mcp add linear --url https://mcp.linear.app/mcp
+```
+
+### Local stdio server
+
+Some MCP servers communicate over stdio instead of exposing a remote HTTP
+endpoint. Use a local stdio server when `sbx` should launch the MCP server on
+the host. You can provide a metadata URL or an explicit command.
+
+#### From registry or manifest metadata
+
+Use `--local --url` when you have an MCP community registry URL or a URL that
+returns a `server.json` or `server.yaml` document. The registry entry or
+manifest must describe an OCI package that uses stdio transport. `sbx` doesn't
+launch non-OCI package types, such as `npm`, from metadata. To use those
+servers, register an explicit command.
+
+This path resolves the image from the metadata and starts it on the host with
+Docker, so Docker must be installed and running on the host.
+
+```console
+$ sbx mcp add fetch --local \
+  --url https://registry.modelcontextprotocol.io/v0/servers/fetch-mcp/versions/latest
+```
+
+If the entry doesn't publish an OCI stdio package, `sbx` rejects the
+registration instead of starting it locally.
+
+A server manifest describes the MCP server package and how to start it. It can
+be hosted on a GitHub raw URL, internal HTTP server, or CDN.
+
+```console
+$ sbx mcp add opine --local --url https://example.com/mcp/opine/server.yaml
+```
+
+#### From an explicit command
+
+Use `--command` when you already know the executable and arguments, or when you
+need custom Docker flags. The command can be a package runner such as `npx` or
+a Docker container command:
+
+```console
+$ sbx mcp add playwright --command npx --args @playwright/mcp@latest
+$ sbx mcp add local-image-server --command docker \
+  --args "run,-i,--rm,your/image"
+```
+
+Use registry or manifest metadata when you have a published server definition
+and don't need to customize `docker run`. Use `--command` for local
+development, private servers, or custom container flags.
+
+> [!WARNING]
+> Local stdio servers run on the host, outside sandbox isolation. If the command
+> starts a Docker container, that container uses host Docker isolation, not
+> sandbox isolation. The process or container can access host files, host
+> network resources, and credentials made available to it. Use trusted commands
+> and images, and avoid mounting host paths or passing credentials unless the
+> server needs them.
+
+## Authorize OAuth-backed servers
+
+If a registered remote server requires OAuth, `sbx mcp add` starts the
+authorization flow by default:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+Resolving MCP server "notion"...
+Open this URL to authorize MCP server "notion":
+https://api.notion.com/v1/oauth/authorize?...
+MCP server "notion" authorized
+MCP server "notion" registered (type: remote)
+```
+
+OAuth credentials stay on the host. In local gateway mode, `sbx` stores tokens
+in the host operating system's credential store.
+
+To register an OAuth-backed server without authorizing it, pass `--skip_auth`:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp --skip_auth
+```
+
+When an unauthorized OAuth-backed server is exposed to a sandbox, the gateway
+exposes a helper tool named `<server>-authorize`, such as `notion-authorize`.
+The agent can call that tool from inside the sandbox when it needs the server.
+
+You can manage OAuth credentials from the host:
+
+```console
+$ sbx mcp auth status notion
+$ sbx mcp auth notion
+$ sbx mcp auth rm notion
+```
+
+Use `--all` to apply `auth`, `auth status`, or `auth rm` to all registered
+OAuth-backed servers. Use `--format=json` for machine-readable output.
+
+## Expose servers at sandbox creation
+
+Every sandbox starts an MCP gateway. When the sandbox starts, supported agent
+integrations read the gateway URL and register it with the agent.
+
+Use `--static-mcp` when you want to pre-load registered MCP servers into a
+sandbox:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+$ sbx mcp add linear --url https://mcp.linear.app/mcp
+$ sbx run claude --name my-session --static-mcp notion,linear
+```
+
+You can pass `--static-mcp` as a comma-separated list or repeat the flag:
+
+```console
+$ sbx run claude --name my-session \
+  --static-mcp notion --static-mcp linear
+```
+
+Every name in the static set must already be registered with `sbx mcp add`. The
+static set is fixed at sandbox creation time. If you omit `--static-mcp`, the
+sandbox starts with an MCP gateway but no registered MCP servers. To use a
+different static set, create a new sandbox.
+
+## Add a server to a running sandbox
+
+To attach an already-registered server to a running sandbox, use
+`sbx mcp load`:
+
+```console
+$ sbx mcp add linear --url https://mcp.linear.app/mcp
+$ sbx mcp load linear --sandbox my-session
+MCP server "linear" loaded into sandbox "my-session" (live)
+```
+
+Connected agent sessions receive a tool-list update, so the added tools become
+visible without reconnecting.
+
+## Built-in gateway tools
+
+The local MCP gateway exposes a small set of built-in tools. These tools belong
+to the gateway itself, not to a registered MCP server. Agents can see and call
+them on the same MCP connection as server tools, so they can appear in agent
+tool lists, logs, policy decisions, audit logs, or approval prompts.
+
+You don't need to call these tools directly for normal setup. Use `sbx mcp`
+commands to register servers and manage credentials from the host. The tools
+matter because agents can call them during a session, and admins can govern
+them separately from tools provided by registered MCP servers.
+
+| Tool                 | Description                                                                                    |
+| -------------------- | ---------------------------------------------------------------------------------------------- |
+| `mcp-exec`           | Executes a tool by name in the current gateway session.                                        |
+| `code-mode`          | Creates a session-scoped JavaScript tool that can call selected tools through the MCP gateway. |
+| `<server>-authorize` | Starts OAuth authorization for an exposed server that requires authorization.                  |
+
+The gateway exposes `<server>-authorize` only when an OAuth-backed server is
+exposed to the sandbox and needs authorization. If `code-mode` creates a
+generated tool, that generated tool is available only in the current session.
+
+In MCP access policies, built-in gateway tools are `MCP::Primordial` resources
+and use the `invokePrimordial` action. Tools from registered MCP servers are
+`MCP::Tool` resources and use the `invokeTool` action. For details, see the
+[MCP policy reference](governance/reference/mcp-policy.md).
+
+## Manage registrations
+
+List registered servers:
+
+```console
+$ sbx mcp ls
+```
+
+Inspect a registered server:
+
+```console
+$ sbx mcp inspect notion
+```
+
+Remove a registered server:
+
+```console
+$ sbx mcp rm notion
+```
+
+For OAuth-backed servers, `sbx mcp rm` removes the OAuth credential before it
+removes the server registration. To remove only the OAuth credential, use
+`sbx mcp auth rm`.
+
+## Register a bundle
+
+An MCP bundle is a JSON array of server definitions fetched from a URL. Each
+entry maps to one `sbx mcp add` registration.
+
+```json
+[
+  { "name": "notion", "url": "https://mcp.notion.com/mcp" },
+  { "name": "linear", "url": "https://mcp.linear.app/mcp" },
+  {
+    "name": "github",
+    "command": "npx",
+    "args": ["@modelcontextprotocol/server-github"]
+  }
+]
+```
+
+Fetch and register a bundle:
+
+```console
+$ sbx mcp bundle add core --url https://example.com/mcp-bundle.json
+```
+
+List registered bundles:
+
+```console
+$ sbx mcp bundle ls
+```
+
+Remove a bundle and the servers it registered:
+
+```console
+$ sbx mcp bundle rm core
+```
+
+## Governance
+
+Organizations with AI Governance can use
+[MCP access policies](governance/access-controls/mcp.md) to control MCP server
+registration, tool calls, gateway meta-tools, resources, prompts, and approval
+requirements. MCP access policies are organization policies written in Cedar.
diff --git a/content/manuals/ai/sandboxes/release-notes.md b/content/manuals/ai/sandboxes/release-notes.md
index 4a53befc15d7..17d319e1e1e1 100644
--- a/content/manuals/ai/sandboxes/release-notes.md
+++ b/content/manuals/ai/sandboxes/release-notes.md
@@ -3,6 +3,7 @@ title: Docker Sandboxes release notes
 linkTitle: Release notes
 description: New features, bug fixes, and changes in Docker Sandboxes
 keywords: docker sandboxes, sbx, release notes, changelog
+weight: 120
 toc_min: 1
 toc_max: 2
 tags:
@@ -23,7 +24,7 @@ the full release history, including pre-releases and downloads, see the
 
 ### Highlights
 
-This release revamps **policy tooling** with a concise `sbx policy ls`, a new `sbx policy inspect`, and a `sbx policy check network` command for testing whether the current policy would allow an access request before you run. 
+This release revamps **policy tooling** with a concise `sbx policy ls`, a new `sbx policy inspect`, and a `sbx policy check network` command for testing whether the current policy would allow an access request before you run.
 Networking gains a **SOCKS5 upstream-proxy transport**.  
 Secrets get a new **`sbx secret import`** with clearer env-source visibility.
 
diff --git a/content/manuals/ai/sandboxes/security/_index.md b/content/manuals/ai/sandboxes/security/_index.md
index 2991f9bcf81a..f7ba69482fb5 100644
--- a/content/manuals/ai/sandboxes/security/_index.md
+++ b/content/manuals/ai/sandboxes/security/_index.md
@@ -1,7 +1,7 @@
 ---
 title: Security model
 linkTitle: Security model
-weight: 50
+weight: 80
 description: Trust boundaries, isolation layers, and security properties of Docker Sandboxes.
 keywords: docker sandboxes, security model, isolation, trust boundaries, microVM
 ---
@@ -26,6 +26,8 @@ What crosses the boundary into the VM:
   outbound HTTP requests. The raw credential values never enter the VM.
 - **Network access:** HTTP and HTTPS requests to
   [allowed domains](defaults/) are proxied through the host.
+- **MCP gateway traffic:** supported agents connect to a host-side MCP gateway
+  endpoint. The gateway brokers access to registered MCP servers.
 
 What crosses the boundary back to the host:
 
@@ -38,6 +40,12 @@ Everything else is blocked. The agent cannot access your host filesystem
 localhost, other sandboxes, or any domain not in the allow list. Raw TCP, UDP,
 and ICMP are blocked at the network layer.
 
+MCP servers are an explicit integration point. Remote MCP servers run outside
+Docker Sandboxes, and local stdio MCP servers run on the host, not inside the
+sandbox VM. An agent can invoke the tools those servers expose through the MCP
+gateway, subject to MCP policies when organization governance is active. Treat
+local MCP servers as trusted host integrations.
+
 ![Sandbox security model showing the hypervisor boundary between the sandbox VM and the host system. The workspace directory is shared read-write. The agent process, Docker Engine, packages, and VM filesystem are inside the VM. Host filesystem, processes, Docker Engine, and network are outside the VM and not accessible. A proxy enforces allow/deny policies and injects credentials into outbound requests.](../images/sbx-security.png)
 
 ## Isolation layers
@@ -91,6 +99,11 @@ supply-chain risk, `sbx` restricts kit installs to an allowlist of sources
 that defaults to Docker Hub only. See
 [Restrict kit sources](../customize/kits.md#restrict-kit-sources).
 
+Local stdio MCP servers run outside the sandbox VM. If you register a local MCP
+server that starts a host process or host Docker container, that process or
+container uses host permissions and host isolation, not sandbox isolation. See
+[MCP gateway](../mcp-gateway.md).
+
 ## Organization-wide control
 
 On a single developer's machine, security and policy are configured locally —
@@ -109,5 +122,5 @@ admins.
 - [Default security posture](defaults/): what a fresh sandbox permits and
   blocks
 - [Credentials](credentials/): how to provide and manage API keys
-- [Governance](../governance/): configure network and filesystem access rules,
-  locally or across your organization
+- [Governance](../governance/): configure network, filesystem, and MCP access
+  controls locally or across your organization
diff --git a/content/manuals/ai/sandboxes/security/defaults.md b/content/manuals/ai/sandboxes/security/defaults.md
index 349ddc03d418..7e78bcefa0d7 100644
--- a/content/manuals/ai/sandboxes/security/defaults.md
+++ b/content/manuals/ai/sandboxes/security/defaults.md
@@ -19,7 +19,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. Org-level rules take precedence over local
-rules. See [Governance](../governance/).
+rules. See
+[Network access policies](../governance/access-controls/network.md).
 
 ## Workspace defaults
 
diff --git a/content/manuals/ai/sandboxes/security/isolation.md b/content/manuals/ai/sandboxes/security/isolation.md
index 5d72cea66660..6aef8c7a27a1 100644
--- a/content/manuals/ai/sandboxes/security/isolation.md
+++ b/content/manuals/ai/sandboxes/security/isolation.md
@@ -37,10 +37,11 @@ each other and cannot reach your host's localhost. There is no shared network
 between sandboxes or between a sandbox and your host.
 
 All HTTP and HTTPS traffic leaving a sandbox passes through a proxy on your
-host that enforces the [network policy](../governance/). The sandbox routes
-traffic through either a forward proxy or a transparent proxy depending on the
-client's configuration. Both enforce the network policy; only the forward proxy
-[injects credentials](credentials.md) for AI services.
+host that enforces the
+[network access policy](../governance/access-controls/network.md). The sandbox
+routes traffic through either a forward proxy or a transparent proxy depending
+on the client's configuration. Both enforce the network policy; only the
+forward proxy [injects credentials](credentials.md) for AI services.
 
 Raw TCP connections, UDP, and ICMP are blocked at the network layer. DNS
 resolution goes through the proxy and is subject to the same network policy —
@@ -64,6 +65,12 @@ your host. When the agent runs `docker build` or `docker compose up`, those
 commands execute against that engine. The agent has no path to your host Docker
 daemon.
 
+This Docker Engine boundary applies to processes running inside the sandbox VM.
+It doesn't apply to local stdio MCP servers registered through the
+[MCP gateway](../mcp-gateway.md). Those servers run on the host, outside the
+sandbox VM. If a local MCP server starts a Docker container, it uses Docker on
+the host.
+
 Each sandbox VM runs its own Docker Engine. The agent runs inside the VM,
 alongside that engine, and drives it to create containers, all within the
 VM:
diff --git a/content/manuals/ai/sandboxes/troubleshooting.md b/content/manuals/ai/sandboxes/troubleshooting.md
index 7be080191a21..57b7312769a1 100644
--- a/content/manuals/ai/sandboxes/troubleshooting.md
+++ b/content/manuals/ai/sandboxes/troubleshooting.md
@@ -1,6 +1,6 @@
 ---
 title: Troubleshooting
-weight: 60
+weight: 100
 description: Resolve common issues when using Docker Sandboxes.
 keywords: docker sandboxes, sbx, troubleshooting, diagnostics, reset, network policy, git, ssh
 ---
@@ -44,7 +44,8 @@ data. Create fresh sandboxes afterwards.
 
 ## Agent can't install packages or reach an API
 
-Sandboxes use a [deny-by-default network policy](governance/local.md).
+Sandboxes use [network access rules](governance/access-controls/network.md) to
+control outbound traffic.
 If the agent fails to install packages or call an external API, the target
 domain is likely not in the allow list. Check which requests are being blocked:
 
@@ -66,7 +67,7 @@ $ sbx policy allow network "**"
 
 If `sbx policy allow` doesn't unblock the request, your organization may
 manage sandbox policies centrally and take precedence over local rules. See
-[Organization governance](governance/org.md).
+[Organization policies](governance/access-controls/organization.md).
 
 ## Kit fails to install: source not in allowlist
 
@@ -141,7 +142,7 @@ If credentials are configured correctly but API calls still fail, check
 the `transparent` proxy don't get credential injection. This can happen when a
 client inside the sandbox (such as a process in a Docker container) isn't
 configured to use the forward proxy. See
-[Monitoring network activity](governance/monitoring.md)
+[Monitoring network activity](governance/monitor-and-enforce/monitoring.md)
 for details.
 
 ## API calls fail with a certificate error
diff --git a/content/manuals/ai/sandboxes/workflows.md b/content/manuals/ai/sandboxes/workflows.md
index 1de3477ae845..e1c64a1da4aa 100644
--- a/content/manuals/ai/sandboxes/workflows.md
+++ b/content/manuals/ai/sandboxes/workflows.md
@@ -484,10 +484,10 @@ defaults. Version kit specs and template definitions with the project, and
 publish reusable template images to your registry. This gives each developer the
 same starting environment.
 
-Use [organization governance](governance/org.md) for rules that admins need to
-apply across developers, such as network and filesystem policies. Organization
-rules are managed in the Docker Admin Console, take precedence over local
-policy, and require a separate paid subscription.
+Use [organization policies](governance/access-controls/organization.md) for
+controls that organization administrators apply across developers, such as
+network, filesystem, and MCP policies. Organization policies take precedence
+over local policy and require a separate paid subscription.
 
 You can use both. Templates and kits describe the development environment;
 governance defines the boundaries it runs within.
diff --git a/content/manuals/subscription/plans/ai-governance.md b/content/manuals/subscription/plans/ai-governance.md
index 80149e061901..4b28959aef2f 100644
--- a/content/manuals/subscription/plans/ai-governance.md
+++ b/content/manuals/subscription/plans/ai-governance.md
@@ -20,7 +20,7 @@ aliases:
 
 ## Usage
 
-AI Governance lets organization owners enforce [governance policies](/manuals/ai/sandboxes/governance/org.md) to license-holding members. Organization policies override the local policies of a license-holding member.
+AI Governance lets organization owners enforce [organization policies](/manuals/ai/sandboxes/governance/access-controls/organization.md) for license-holding members. Organization policies override a license-holding member's local policies.
 
 You can [assign AI Governance licenses](/manuals/admin/organization/manage/manage-licenses.md) to any organization member, even if they don't occupy a Docker Team or Docker Business seat. For best practice, review available licenses as you add new members since members without an AI Governance license can still use Docker AI products.