Network access policies

The governance described here applies to local sandboxes. Cloud sandboxes use separate network policy configuration. See Cloud network policy for cloud controls.

Network access policies control outbound connections from sandboxes. Each policy contains one or more rules that allow the domains, IP ranges, and ports a workflow needs, or block destinations that should stay unavailable. Rules can also match the HTTP method and path of a request, so a policy can allow part of an API without allowing all of it.

You can configure network access in two places:

• Local policy, which applies to sandboxes on one developer machine when organization governance is not active.
• Organization policies, which apply centrally across an organization or to selected teams.

When organization governance is active, only organization allow rules grant network access. Local allow rules are inactive until organization governance no longer applies, while local deny rules still apply on top of the organization policy. See Precedence.

Rule syntax

Network rules use connect:tcp for TCP and connect:udp for UDP. Resources are hostnames, CIDR ranges, ports, or hostnames with ports. UDP requires experimental outbound UDP. ICMP is blocked.

Examples:

• api.example.com
• *.example.com
• **.example.com
• example.com:443
• 10.0.0.0/8

For exact wildcard behavior and CIDR support, see Network rules.

HTTP method and path rules

A network rule matches a destination, so it allows or blocks everything a sandbox sends there. An HTTP rule narrows the match to specific HTTP methods and URL paths on that destination, which lets a policy allow reads from an API without allowing writes to it.

HTTP rules layer on top of network rules. A network allow is the baseline for a destination and HTTP rules carve into it, while a network deny blocks the destination outright and no HTTP allow can reopen it. For the pattern syntax and the full matching table, see HTTP rules.

Configure them in either place:

• Organization policies, in the network rule composer in Docker Home. Set the rule Type to HTTP, then select the methods and path patterns. See Add a network rule.
• Local policies, with --method and --path on sbx policy. See HTTP method and path rules.

Local network rules

Use sbx policy allow network and sbx policy deny network to manage local network rules:

$ sbx policy allow network api.example.com
$ sbx policy deny network ads.example.com

For presets, sandbox-scoped rules, testing, and troubleshooting, see Local policy.

Organization network rules

Organization network rules belong to policies that can apply to the whole organization or to selected teams. For setup steps and team scoping, see Organization policies.

Use Monitoring policies to inspect which network rules are active on a developer machine.

Approval-required access

An organization network policy can require approval instead of granting access outright. Destinations the policy allows aren't reachable until the developer confirms them, which keeps an allowlist broad enough to be usable while still putting a person in front of each destination an agent reaches for.

Without organization governance, a request with no matching allow or deny rule also asks for approval rather than being denied outright, so access opens up as the developer approves each destination.

Under organization governance, approval is a property of the policy rather than of individual rules, so turning it on applies it to every allow rule in that policy. A destination stays directly reachable only when no policy that allows it requires approval. If a policy that requires approval also matches, the request needs approval regardless of what the other policies allow.

Only a destination the developer has already approved satisfies the requirement. Preset rules, kit-defined rules, and rules the developer added with sbx policy allow network don't answer it. An approval also can't reach a destination the organization doesn't allow at all, and it can't override a deny rule. To withdraw a destination, add a deny rule, which takes precedence over any approval already recorded.

To require approval on an organization policy, see Organization policies.

Respond to an approval request

When a destination needs approval, a sandbox can't reach it until you confirm it. The request is blocked and the sandbox receives a message naming the destination:

Approval required for api.example.com.

Review and respond with:
  sbx policy approval ls

If your organization configures a support message, it appears after the approval instructions.

The request that triggers the prompt doesn't wait for an answer. It's denied, and approving the destination affects later requests. Agents that retry a failed request pick up the new access on their next attempt. For others, run the operation again.

List the destinations waiting for a response:

$ sbx policy approval ls
APPROVAL                                              SANDBOX      TITLE                 DETAIL                                                                              OPTIONS
network:cWtN-4xUrNjxh4ouezcstgjrky6Rg57QfeRe3WEkyyY   my-sandbox   api.example.com:443   Protocol: TCP Resource type: domain approval required by policy "default network"   allow (Allow), dismiss (Dismiss)

Each entry names the destination, the sandbox that asked for it, and why it needs approval. Under organization governance that reason names the policy, as shown. Without it, the reason is that no matching allow rule covers the destination. A request that an HTTP rule matches also shows the method and path, such as GET api.example.com:443/v1/data.

To inspect a single entry, pass its ID to sbx policy approval inspect:

$ sbx policy approval inspect network:cWtN-4xUrNjxh4ouezcstgjrky6Rg57QfeRe3WEkyyY
APPROVAL network:cWtN-4xUrNjxh4ouezcstgjrky6Rg57QfeRe3WEkyyY  (sandbox: my-sandbox)
  api.example.com:443
  Protocol: TCP
  Resource type: domain
  approval required by policy "default network"

  OPTION    LABEL
  allow     Allow
  dismiss   Dismiss

Respond by selecting one of the options the entry offers:

$ sbx policy approval respond network:cWtN-4xUrNjxh4ouezcstgjrky6Rg57QfeRe3WEkyyY --option allow
Recorded: Allow

Choosing allow grants access to that destination. Choosing dismiss leaves it blocked, and the destination is requested again the next time the sandbox tries to reach it. Repeated attempts collapse into a single entry, so a sandbox retrying in a loop leaves one request to answer, not a queue of duplicates.

What approving grants

Approving records a rule that allows the destination the sandbox actually asked for, scoped to the sandbox that asked. Three things follow from that:

• The rule covers one destination, not the pattern the policy rule used. A policy that allows *.example.com with approval asks about api.example.com and cdn.example.com separately.
• A destination includes its port, so api.example.com:443 and api.example.com:8443 are approved separately.
• Another sandbox reaching the same destination asks again.

When an HTTP rule in the policy matches the request, approving covers the method and exact path the sandbox requested rather than the whole destination. GET /v1/data and POST /v1/data on the same host are approved separately. A request whose method or path can't be recorded as a rule, such as a path with percent-encoding, is blocked without an entry to respond to.

Approved destinations stay allowed until the rule is removed. List them with sbx policy ls --wide --created-via approval, and remove one the same way as any other local rule, with sbx policy rm network.

Approvals live in the local policy store, so sbx policy reset removes all of them along with your other local rules. Each destination is requested again the next time a sandbox reaches it.

Note

To manage Model Context Protocol (MCP) server registration and requests through Docker's MCP gateway, use MCP access policies. These policies apply only to the gateway. Direct MCP connections from a sandbox don't use the gateway, but you can control access to remote MCP servers with network policy.