sbx policy ls --source org, --profile, and the audit JSONL

Your security team asks which hosts the agents reached last week, who allowed each one, and whether a developer could have widened the list. On one laptop the answer is sbx policy log, and across a company it is an organization policy with an audit log behind it. When you finish this section, you can say what an organization policy changes on a developer machine and read one audit record.

What an organization can set

Organization policy: a named set of rules written in Docker Home, applied to every local sandbox of the organization or of chosen teams. Three kinds exist: Network access, Filesystem access, and MCP access. A network rule is HTTP, one destination with methods and path patterns, or All traffic over TCP, UDP, or both, with Allow or Deny. A network policy can require approval, so each destination it allows waits once for the developer's confirmation. An MCP policy is Cedar in the MCP namespace, default deny, where a forbid beats every permit. An organization holds at most 100 policies of 250 rules and 400 KB each.

A change reaches developer machines within 5 minutes, and sbx policy reset forces the pull at the price of every local rule and recorded approval. Network rules apply to the next request, filesystem rules only when a sandbox is created, and MCP registration rules at the next sbx mcp add. Sign-in enforcement lists allowedOrgs in a managed com.docker.sbx profile on macOS, the key HKLM\SOFTWARE\Policies\Docker\SBX on Windows, or /etc/docker-sbx/config.json on Linux. sbx login then revokes a credential from any other account. All of this is a separate paid subscription, Docker AI Governance, and local use stays free.

What an organization cannot do

Governance narrows and never widens. When a policy is active, only organization allow rules grant access, and deny rules from every source still apply. Local and kit allow rules are inactive. The help text for --deny-network says the same:

A local deny even beats an organization approval requirement, so the request is blocked and no prompt appears.

Governance covers local sandboxes only, and a cloud sandbox uses its own account and sandbox policy, as the cloud section describes. Audit records hold metadata and never prompt content, agent output, or parameter values.

This capture has no organization

$ sbx policy ls --source org
No policies match the selected filters.
[exit 0]

$ sbx policy ls --include-inactive
POLICY         SOURCE   APPLIES TO   SUMMARY
local-policy   local    all          network: 194 allow; filesystem read: 1 allow; filesystem write: 1 allow
[exit 0]

{
  "profiles": [],
  "policy_rules_unavailable": false
}

No Governance: Managed by <org> line appears, and the docs name that line as the test for an active policy. Every policy check in this capture reports "governance": {"active": false} (the capture). Profile: a named group of organization policies that a developer assigns with --profile at creation, listed by sbx policy profile ls. When no rule matches and no organization governs the machine, the proxy asks for approval. Its 403 body names sbx policy approval ls (the capture), a command the v0.47.0 help tree does not list (conflict C16).

The audit record

Audit record: one JSON object per policy decision or daemon session event, written by the daemon and never by the CLI. Records exist since v0.32.0. The daemon writes them only for a signed-in user with an AI Governance license under an enforced organization policy. This capture therefore produced none, and the directory listing planned as capture K32 was not recorded (conflict C37). The sample record in the docs carries the same reason string that sbx policy log printed for m101-policy:

  "blocked_hosts": [
    {
      "host": "example.com:443",
      "vm_name": "m101-policy",
      "proxy_type": "forward",
      "rule": "no applicable policies for op(action=net:connect:tcp, resource=net:domain:example.com:443)",
      …
      "reason": "No matching allow rule (default deny)"

{
  "audit_event_id": "95e7257f-93c9-4f29-bde7-88830e2dae80",
  "timestamp": "2026-05-28T19:15:00.728933Z",
  "schema_version": "1.82.0",
  "category": "AUDIT_CATEGORY_EVALUATION",
  "decision": "AUDIT_DECISION_DENY",
  …
  "resource_id": "example.com:443",
  "os": "macos",
  "app_version": "v0.31.0",
  "client_name": "sbx",
  "hostname": "host-machine",
  "deny_reason": [
    "no applicable policies for op(action=net:connect:tcp, resource=net:domain:example.com:443)"
  ],
  "action_type": "network_egress",
  "network_egress": { "protocol": "tcp" },
  "agent": "claude"
}

On macOS the files are audit-<utc-timestamp>-<process-uuid>-<seq>.jsonl under ~/Library/Logs/com.docker.sandboxes/sandboxes/auditkit/. The daemon finalizes a .tmp file into .jsonl every 5 minutes, 1000 events, or 50 MiB, and never deletes one. category is management, evaluation, or execution, and decision is one of five values from AUDIT_DECISION_ALLOW to AUDIT_DECISION_APPROVAL_DENY. action_type names the payload, such as network_egress, http_request with method, host, port, and path, or tool_invocation.

client_name is sbx and hostname names the machine, which is how a GitHub Actions run with runtime: docker-sbx appears. Docker Cloud delivery is on by default and keeps events searchable for 90 days, with CSV export up to 1 000 000 rows. From 0.39.0 on it also forwards to Splunk Cloud, Dynatrace, Datadog, or Sumo Logic.