sbx: restructure governance docs and add governance API reference

Splits the existing security/governance and security/policy pages into a
new governance section with concepts, local, organization, monitoring,
and API reference sub-pages, and adds a custom api-reference Hugo layout
that renders the colocated OpenAPI 3 spec directly from the spec file.

The layout reads the spec via transform.Unmarshal, resolves $ref nodes
through a small returning partial, and overrides baseof's main block to
take the full content width. The built-in right-rail TOC is replaced
with a sticky endpoint navigator that groups operations by tag with
method-colored pills.

Each operation card shows method/path, summary, description, parameters,
request body, and responses. Responses use native <details> elements so
the list of status codes stays scannable; 2xx defaults to open. JSON
examples are wrapped in the site's syntax-light/dark utility so Chroma
classes pick up the theme. Each operation also exposes a copy-as-cURL
button that assembles a ready-to-paste command from the spec's path and
query parameter examples, the bearer-auth scheme (with $TOKEN as a
literal placeholder), and the request body's default JSON example.

A companion api-reference.markdown.md template renders the same spec as
a clean markdown document so the page's "Copy Markdown" / "View
Markdown" actions and the .md alternate link return real content
instead of just the page title.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: dvdksn

content/manuals/ai/sandboxes/_index.md

@@ -14,7 +14,7 @@ build containers, install packages, and modify files without touching your host
 system.
 
 Organization admins can
-[centrally manage sandbox network and filesystem policies](security/governance.md)
+[centrally manage sandbox network and filesystem policies](governance/org.md)
 from the Docker Admin Console, so the same rules apply uniformly across every
 developer's machine. Available on a separate paid subscription.
 

content/manuals/ai/sandboxes/architecture.md

@@ -36,7 +36,7 @@ layers, and volumes, and this grows as you build images and install packages.
 
 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](security/policy.md) and handles
+enforces [network access policies](governance/local.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

content/manuals/ai/sandboxes/faq.md

@@ -14,7 +14,7 @@ Signing in gives each sandbox a verified identity, which lets Docker:
   containers, install packages, and push code. Your Docker identity is the
   anchor.
 - **Enable team features.** Team-scale features like
-  [organization governance](security/governance.md), shared environments, and
+  [organization governance](governance/org.md), shared environments, and
   audit logs need a concept of "who," and adding that later would be worse for
   everyone.
 - **Authenticate against Docker infrastructure.** Sandboxes pull images, run
@@ -30,7 +30,7 @@ organization and take precedence over local rules set with `sbx policy`.
 Admins can optionally delegate specific rule types back to local control so
 developers can add additional allow rules.
 
-See [Organization governance](security/governance.md). This feature requires
+See [Organization governance](governance/org.md). This feature requires
 a separate paid subscription —
 [contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
 to get started.
@@ -99,7 +99,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](security/policy.md),
+isolated microVM with [network policies](governance/local.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

content/manuals/ai/sandboxes/get-started.md

@@ -114,7 +114,7 @@ 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](security/policy.md) for a full description of each
+rules later. See [Policies](governance/local.md) for a full description of each
 option.
 
 > [!NOTE]
@@ -233,7 +233,7 @@ $ sbx policy allow network -g registry.npmjs.org
 
 With **Locked Down**, even your model provider API is blocked unless you
 explicitly allow it. With **Balanced**, common development services are
-permitted by default. See [Policies](security/policy.md) for the full rule
+permitted by default. See [Policies](governance/local.md) for the full rule
 set and how to customize it.
 
 ## Clean up
@@ -269,4 +269,4 @@ working tree are unaffected.
   with kits
 - [Credentials](security/credentials.md) — credential storage and management
 - [Workspace trust](security/workspace.md) — review agent changes safely
-- [Policies](security/policy.md) — control outbound access
+- [Policies](governance/local.md) — control outbound access

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

@@ -0,0 +1,39 @@
+---
+title: Governance
+weight: 55
+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
+---
+
+Sandbox governance covers the policy system that controls what sandboxes can
+access over the network and on the filesystem. It operates at two layers that
+build on each other:
+
+**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).
+
+**Organization policy** is configured centrally in the Docker Admin Console or
+via the [Governance API](api.md). Rules defined at the org level apply
+uniformly across every sandbox in the organization and take precedence over
+local rules. Admins can optionally delegate specific rule types back to local
+control so developers can extend the org policy with additional allow rules.
+See [Organization policy](org.md).
+
+> [!NOTE]
+> Organization governance is available on a separate paid subscription.
+> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+> to request access.
+
+## Learn more
+
+- [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 from the Admin Console
+- [Monitoring](monitoring.md): inspect active rules and monitor sandbox
+  network traffic with `sbx policy ls` and `sbx policy log`
+- [API reference](api.md): manage org policies programmatically via the
+  Governance API