From 5df467ea28bf1dba994448ad2670be821dec2f40 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 11 Jun 2026 13:52:28 +0200 Subject: [PATCH 1/3] docs(sandboxes): clarify DNS resolution is policy-gated in network isolation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sandbox DNS lookups now go through the same policy engine as TCP connections — a denied domain is refused at the resolver level, not just the connection level. Updated the network isolation description to reflect this guarantee rather than describing DNS as merely proxied. Co-Authored-By: Claude Sonnet 4.6 --- content/manuals/ai/sandboxes/security/isolation.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/manuals/ai/sandboxes/security/isolation.md b/content/manuals/ai/sandboxes/security/isolation.md index 872cdfc1437..63d2e306f98 100644 --- a/content/manuals/ai/sandboxes/security/isolation.md +++ b/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). From f689376626b7e221efb56f8cdbaa4699bbf6d680 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 11 Jun 2026 13:52:55 +0200 Subject: [PATCH 2/3] docs(sandboxes): add agent field to audit log schema Audit records now include an `agent` field identifying which AI agent drove the sandbox (claude, codex, etc.), so multi-agent deployments can attribute policy decisions per agent. Added to the example record and the field reference table. Co-Authored-By: Claude Sonnet 4.6 --- content/manuals/ai/sandboxes/governance/audit.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/manuals/ai/sandboxes/governance/audit.md b/content/manuals/ai/sandboxes/governance/audit.md index fcf2a4d24c9..10fe4103e6a 100644 --- a/content/manuals/ai/sandboxes/governance/audit.md +++ b/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. From 3c6cc0ab3164a56b767e5b5c017ba326078fc934 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 11 Jun 2026 13:53:28 +0200 Subject: [PATCH 3/3] docs(sandboxes): document multiple --host patterns for custom secrets sbx secret set-custom --host is now repeatable, so one secret entry can cover multiple domains. Added a second example showing the multi-host form and updated the prose to reflect that the proxy matches any of the configured hosts. Co-Authored-By: Claude Sonnet 4.6 --- .../ai/sandboxes/security/credentials.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/content/manuals/ai/sandboxes/security/credentials.md b/content/manuals/ai/sandboxes/security/credentials.md index 644646f51c9..740e3495a6d 100644 --- a/content/manuals/ai/sandboxes/security/credentials.md +++ b/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 ``` +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 +``` + > [!WARNING] > Passing the secret as `--value ` 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-`). When a sandboxed process sends a request to -`api.example.com` and the placeholder appears anywhere in the request, the +`sbx-cs-`). 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 —