docs(sandboxes): post-v0.32.0 doc updates

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

@@ -63,7 +63,8 @@ A network evaluation record looks like this:
     "no applicable policies for op(action=net:connect:tcp, resource=net:domain:example.com:443)"
   ],
   "action_type": "network_egress",
-  "network_egress": { "protocol": "tcp" }
+  "network_egress": { "protocol": "tcp" },
+  "agent": "claude"
 }
 ```
 
@@ -83,6 +84,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.       |
 
 Each record is attributed to the signed-in Docker user and the organization
 whose governance policy is in effect.

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

@@ -209,7 +209,7 @@ network policy. For details, see
 For credentials that don't fit the service-identifier model — for example,
 when an agent validates the environment variable format at boot, or when the
 credential lands in a request body rather than a header — use
-`sbx secret set-custom`. The secret is keyed on a target domain, an
+`sbx secret set-custom`. The secret is keyed on one or more target domains, an
 environment variable name, and an optional placeholder string, instead of a
 service identifier.
 
@@ -220,6 +220,18 @@ $ sbx secret set-custom -g \
     --value <secret>
 ```
 
+Repeat `--host` to cover multiple domains with the same secret — useful when
+an API is split across related hostnames or when two unrelated endpoints share
+a credential:
+
+```console
+$ sbx secret set-custom -g \
+    --host api.example.com \
+    --host uploads.example.com \
+    --env API_KEY \
+    --value <secret>
+```
+
 > [!WARNING]
 > Passing the secret as `--value <secret>` records it in your shell history
 > and exposes it to other processes running as your user. Avoid pasting
@@ -228,8 +240,8 @@ $ sbx secret set-custom -g \
 > on the command line.
 
 Inside the sandbox, `API_KEY` is set to a generated placeholder (for example,
-`sbx-cs-<rand>`). When a sandboxed process sends a request to
-`api.example.com` and the placeholder appears anywhere in the request, the
+`sbx-cs-<rand>`). When a sandboxed process sends a request to any of the
+configured hosts and the placeholder appears anywhere in the request, the
 proxy replaces it with the real value. The agent never sees the real secret.
 
 Prefer the [service-based flow](#stored-secrets) whenever it's an option —

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

@@ -43,9 +43,10 @@ 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 is handled by the proxy; the sandbox cannot make raw DNS queries.
-Traffic to private IP ranges, loopback, and link-local addresses is also
-blocked. Only domains explicitly listed in the policy are reachable.
+resolution goes through the proxy and is subject to the same network policy —
+domains that policy denies are refused at the resolver. Traffic to private IP
+ranges, loopback, and link-local addresses is also blocked. Only domains
+explicitly listed in the policy are reachable.
 
 For the default set of allowed domains, see
 [Default security posture](defaults.md).