Monitoring policies
sbx policy ls and sbx policy log give you a combined view of all active
policy rules and sandbox network activity, regardless of whether those rules
come from local configuration or organization governance. They're useful both
for verifying rules you've written and for debugging why a request is being
blocked or allowed.
Listing rules
Use sbx policy ls to see all active rules and their current status:
$ sbx policy ls
NAME TYPE ORIGIN DECISION STATUS RESOURCES
balanced-dev network local allow active api.anthropic.com
ads-block network local deny active ads.example.com
kit:my-sandbox network sandbox:my-sandbox allow active api.example.com
kit:my-sandbox:deny network sandbox:my-sandbox deny active telemetry.example.com
The columns are:
NAME: the rule name.TYPE: the rule domain, such asnetwork.ORIGIN: where the rule was configured.localmeans the rule is global and applies to all sandboxes.sandbox:<name>means the rule is scoped to the named sandbox.remotemeans the rule was set by your organization.DECISION: whether the rule allows or denies the resource.STATUS: whether the rule is in effect. A rule may beinactiveif it's overridden or suppressed — for example, when organization governance is active, local rules are not evaluated. Inactive rules are hidden by default; pass--include-inactiveto list them. See Showing inactive rules.RESOURCES: the hosts or patterns the rule applies to.
When organization governance is active, the output starts with a governance header showing which organization manages the policy and when it last synced:
$ sbx policy ls
Governance: managed by my-org
[OK] last synced 13:54:21
NAME TYPE ORIGIN DECISION STATUS RESOURCES
allow AI services network remote allow active api.anthropic.com
api.openai.com
allow Docker services network remote allow active *.docker.com
*.docker.io
The governance header shows which organization is managing the policy and
confirms the daemon has successfully pulled the latest rules. If the sync
status shows an error or a stale timestamp, the daemon may not have the most
recent org policy. Run sbx policy reset to force a fresh pull.
Showing inactive rules
When organization governance is active, local and kit-defined rules are not
evaluated, so sbx policy ls hides them by default. To list them too — for
example, to confirm which local rules the organization policy overrides — pass
--include-inactive:
$ sbx policy ls --include-inactive
Governance: managed by my-org
[OK] last synced 13:54:21
NAME TYPE ORIGIN DECISION STATUS RESOURCES
balanced-dev network local allow inactive api.anthropic.com
allow AI services network remote allow active api.anthropic.com
api.openai.com
allow Docker services network remote allow active *.docker.com
*.docker.io
Inactive rules show with an inactive status. They have no effect while
organization governance is active.
Use --type network to show only network rules. Without a sandbox argument,
sbx policy ls shows every rule across all sandboxes. Pass a sandbox name to
filter to global rules and rules scoped to that sandbox:
$ sbx policy ls my-sandbox
Monitoring traffic
Use sbx policy log to see which hosts your sandboxes have contacted and
which rules matched:
$ sbx policy log
Blocked requests:
SANDBOX TYPE HOST PROXY RULE REASON LAST SEEN COUNT
my-sandbox network blocked.example.com transparent domain-blocked default-deny 10:15:25 29-Jan 1
Allowed requests:
SANDBOX TYPE HOST PROXY RULE REASON LAST SEEN COUNT
my-sandbox network api.anthropic.com forward domain-allowed 10:15:23 29-Jan 42
my-sandbox network registry.npmjs.org forward-bypass domain-allowed 10:15:20 29-Jan 18
my-sandbox network app.example.com browser-open 10:15:10 29-Jan 1
The PROXY column shows how the request left the sandbox:
The RULE column identifies the policy rule that matched the request. The
REASON column includes extra context when the daemon records one.
Filter by sandbox name by passing it as an argument:
$ sbx policy log my-sandbox
Use --limit N to show only the last N entries, --json for
machine-readable output, or --type network to filter by policy type.