The Policy Model
Before you run the live demo, here's the mental model.
Where policies live
Policies for your organization are defined in one place:
https://app.docker.com/accounts/<your-org> → AI governance
Only org admins can modify policies. Developers cannot override them locally. That's the point.
How policies reach developers
When a developer runs docker login with org credentials, the Docker client fetches the org's AI governance policies as part of authentication. The local sbx daemon caches them and applies them to every sandbox launched on that machine.
Admin Console ──auth flow──▶ Developer Docker Desktop ──cache──▶ Every sandbox
(one source
of truth)
When the admin changes a policy, developers pick up the change on next sync. To force an immediate refresh:
sbx policy reset
(You'll be prompted to choose a default baseline. Pick Balanced.)
How rules evaluate
Rules are evaluated per request at the sandbox network proxy. For an outbound HTTP request from inside a sandbox, the proxy checks:
- Does any deny rule match? → Block (403)
- Does any allow rule match? → Forward
- Otherwise → Default-deny (block)
This means:
- Explicit deny always wins. Adding a deny rule for
paste.eeblocks paste.ee even when a broader allow rule exists. - Default-deny posture means you don't need to enumerate every bad destination. If you didn't explicitly allow it, it's blocked.
- A
0.0.0.0/0catch-all allow rule defeats this model - it permits everything. We'll remove it in the next section if it's present.
Local vs remote policies
Run this to see what's currently active:
sbx policy ls
You'll see two kinds of policies:
ORIGIN column | Meaning |
|---|---|
local | Defaults shipped with sbx, or rules you added with sbx policy allow ... |
remote | Pulled from your org's Admin Console |
When the org has policies set for a rule type (e.g., network), local rules of that type go inactive - you'll see corporate policy takes precedence and does not delegate this rule type to local policy.
The CISO has the wheel.
Confirm governance is active
Look at the top of the sbx policy ls output. You should see:
Governance: managed by <your-org>
[OK] last synced HH:MM:SS
If Governance says anything other than your org, check that you're logged in with the right account (docker login) and that the account is a member of your org.
That's the model. Now let's prove it works end-to-end.