Docker Sandboxes Network Credentials

DockerOfficialPublished by Docker

Skill
Tool integration
Cloud and DevOps
Apache-2.0
No issues found

From the author

Use this skill when configuring what a Docker Sandboxes (`sbx`) sandbox can reach on the network or which credentials it authenticates with, even if the user just says they want to "let the agent call an internal API", "block all network access", "give the agent a GitHub token", or "use a private registry image for a sandbox". Covers `sbx policy init/allow/deny/ls/inspect/log/check/rm network` (global and per-sandbox egress rules, deny-over-allow precedence) and `sbx secret set/set-custom/ls/rm/import` (service secrets, dynamic secrets via --ref/--command, and registry pull credentials with their host-pulls-only-by-default injection scope).

— the description by Docker

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides the interface for configuring network access and secret management within the Docker Sandboxes (sbx) environment. It allows users to define granular egress rules to control which hosts a sandbox can reach, and to securely inject service secrets or registry credentials without exposing raw values to the sandbox environment. The skill covers the lifecycle of policies and secrets, including initialization, scoping to specific sandboxes, and dynamic secret resolution.

What it does

Initializes and manages global or per-sandbox network egress policies.
Configures allow/deny rules for specific hosts, CIDRs, or wildcard patterns.
Injects service secrets and API keys via a proxy-managed sentinel system.
Handles dynamic secret resolution using external references or shell commands.
Manages container registry pull credentials with configurable injection scopes.
Provides diagnostic tools to check, log, and inspect active network and secret policies.

When to use it

When you need to restrict or permit network access for a specific sandbox.
When you need to provide an API key or OAuth token to an agent securely.
When a sandbox requires authentication to pull images from a private registry.
When troubleshooting blocked network requests or failed credential injections.
When you need to audit current network rules or stored secret configurations.

Advantages

Prevents credential leakage by using proxy-managed sentinels instead of raw environment variables.
Enforces security through a deny-over-allow precedence model.
Supports dynamic secret retrieval from secure sources like 1Password or AWS Secrets Manager.
Allows fine-grained control over network egress at both global and individual sandbox levels.
Provides safe, non-destructive ways to audit and manage policies.

Usage examples

“Allow my sandbox named 'data-processor' to access api.example.com.”: The agent executes 'sbx policy allow network --sandbox data-processor api.example.com' to update the sandbox-specific egress rules.
“Set an Anthropic API key for my agent to use.”: The agent prompts for the key and executes 'sbx secret set anthropic' to store it securely in the proxy-managed credential store.
“Check if my sandbox can reach the internet.”: The agent runs 'sbx policy check network --sandbox my-sandbox **' to verify if the wildcard egress rule is permitted.
“Configure credentials for pulling images from my private registry.”: The agent uses 'sbx secret set --registry my-registry.io --password-stdin' to store the credentials for host-side image pulls.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/docker/docker-sandboxes-network-credentials/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip docker-sandboxes-network-credentials.zip -d .agents/skills

Documentation by Docker

Docker Sandboxes: Network Policy & Credentials

Overview

This skill owns sbx policy (network egress) and sbx secret (service secrets and registry credentials). The proxy enforces egress policy and injects stored credentials on matching domains. Proxy-managed sentinels are not usable upstream credentials, but OAuth passthrough can expose real tokens to the sandbox. Egress policy does not protect a real credential once leaked outside the sandbox; revoke or rotate a leaked credential.

When to use this skill

Activate this skill when:

The user wants to allow, deny, or inspect which hosts a sandbox (or all sandboxes) can reach.
The user wants to give an agent an API key, OAuth token, or other service credential without exposing the raw value inside the sandbox.
The user wants to pull a private template image or kit from a registry that requires authentication.
The user is debugging a blocked network request or a credential that isn't being injected.

Do not use this skill when

Do not use this skill when:

The task is running docker agent run --sandbox or managing its docker agent sandbox allowlist — use docker-agent-run. If the CLI is unclear, establish whether the user runs Docker Agent or standalone sbx before choosing commands.
The task is creating, reattaching to, or removing a sandbox itself — use docker-sandboxes-lifecycle.
The task is declaring secrets/registries/bindings inside a checked-in sbxenv.yaml file — use docker-sandboxes-env for the file format (this skill's rules on precedence and injection scope still apply to what that file provisions).
The task is declaring a kit's own credentials:/permissions.network: block in a spec.yaml — use docker-sandboxes-kits for the schema (this skill's model of what those declarations mean at runtime still applies).

Core guidance

Network policy: global, per-sandbox, and precedence

The global network policy must be initialized once before creating the first sandbox: sbx policy init <allow-all|balanced|deny-all>. balanced is the recommended starting point (typical dev traffic — AI services, package registries — allowed). This is a one-time setup.
sbx policy reset is destructive: it deletes the entire local policy store and stops the daemon and every currently running sandbox. The daemon restarts on the next daemon-backed command. It is not a lightweight way to "start over" or a routine diagnostic step — never propose it as a first troubleshooting move for a single misbehaving rule. Use targeted sbx policy rm network (by --id or --resource) to remove one rule instead; reserve sbx policy reset for when the policy store itself needs to be rebuilt from scratch, and warn the user that it will stop running sandboxes before running it.
Add rules with sbx policy allow network RESOURCES / sbx policy deny network RESOURCES. RESOURCES is a comma-separated list of exact hosts, *.example.com single-label wildcards, **.example.com multi-label wildcards, optional :port suffixes, CIDR prefixes, or ** for "all hosts".
```
sbx policy init balanced
sbx policy allow network "api.example.com,cdn.example.com"
sbx policy deny network ads.example.com
```
Deny always wins over allow for the same hostname/CIDR when both match. An allowed hostname is not checked against CIDR deny rules for its resolved IP.
A rule applies globally by default. Pass --sandbox NAME to scope it to one sandbox's local policy instead:
```
sbx policy allow network --sandbox my-sandbox api.example.com
```
At creation time only, sbx create/sbx run accept --deny-network RESOURCE (repeatable) to add a per-sandbox deny rule. This is safe to expose even under centralized (org) governance because a local deny can only narrow, never widen, egress — it can never override an org-level allow into a broader grant.
Use sbx policy check network [--sandbox NAME] TARGET to test what the current policy would do for a host/URL before it matters, and sbx policy log [SANDBOX] to see what was actually allowed or blocked historically, with the matching rule.
```
sbx policy check network --sandbox my-sandbox api.example.com:443
sbx policy log my-sandbox --json
```
sbx policy ls [SANDBOX] [--wide] lists active policies/rules; --wide adds rule IDs (needed for sbx policy rm network --id) and per-resource status. sbx policy inspect <policy-or-rule> gives full detail including each rule's exact removal command or the reason it is read-only (e.g. org-managed). To remove a sandbox-scoped rule, retain --sandbox NAME; omitting it targets the global policy instead:
```
sbx policy rm network --sandbox my-sandbox --resource api.example.com
sbx policy check network --sandbox my-sandbox api.example.com
```
Removing one rule does not determine the final decision; other matching rules still apply.

Service secrets: how injection works

sbx secret set [SERVICE] stores a credential the proxy uses to authenticate outbound requests on behalf of the agent. In the normal proxy-managed flow, the sandbox sees a sentinel rather than the raw secret; the proxy substitutes the real value on requests to the domains the matching kit/binding declares.
```
sbx secret set github                       # interactive
printf '%s' "$ANTHROPIC_API_KEY" | sbx secret set anthropic
```
Storing a secret does not grant network access. Egress is governed separately by sbx policy; check the target domain in the intended scope before debugging authentication:
```
sbx policy check network --sandbox my-sandbox api.anthropic.com
```
OAuth passthrough is an exception, not a no-secret-exposure guarantee. When a kit sets oauth.passthrough: true without a refresh sentinel, the proxy forwards the real token response to the sandbox. The built-in devin kit uses this mode. Review the agent's credential configuration before promising that it cannot read a token; do not enable passthrough merely to bypass an authentication failure. Even with sentinels, the agent can exercise the credential's permissions on allowed services — restrict token privileges as well as network access.
Service secrets are global by default; --sandbox NAME scopes one to a single sandbox.
Dynamic secrets resolve the value on the host at use time instead of storing it directly: --ref (1Password op://... or an AWS Secrets Manager ARN — requires an authenticated op/aws CLI) or --command (runs a shell command and uses its stdout). --refresh controls the resolution/cache policy (default 55m, or on-demand).
```
sbx secret set anthropic --ref 'op://Private/Anthropic/api-key'
sbx secret set github --command 'gh auth token'
```
--command and --ref are resolved on the host, with your own privileges, and treated as trusted execution — never point --command at anything an untrusted file or an agent's own output could influence.
Never pass a secret as a plain --env value or as a --kit-arg / --env-arg value. Both land as literal, unmasked text — in the sandbox's environment, in sbx env plan's state file, and potentially in shell history — defeating the entire point of the credential store. Use sbx secret set (or sbxenv.yaml's secrets:/registries: blocks, which route through the same store) instead.
sbx secret set-custom (experimental) covers a service sbx has no built-in support for: the sandbox sees a placeholder value in an env var you name (--env), and the proxy swaps in the real secret only on requests to the --host pattern(s) you declare.
sbx secret ls [--global|--sandbox NAME] [--service NAME] [--json] lists what is stored, without revealing values. sbx secret rm [SERVICE] [--sandbox NAME] [--all|--registry HOST] [--force] removes it.
sbx secret import [SERVICE] [--all] [--dry-run] [--force] offers to import secrets already sitting in host environment variables (e.g. OPENAI_API_KEY, GH_TOKEN) into the global store, prompting per entry unless --all/--force. A service with an OAuth token already configured is skipped — OAuth takes precedence at runtime over an imported API key.

Registry credentials: host-pulls-only by default, two distinct injection scopes

sbx secret set --registry HOST --password-stdin (optionally --username) stores pull credentials for a container registry, used to pull private template images and kit artifacts. Unlike service secrets, registry credentials are host-only by default: they authenticate pulls on the host and are never injected into any sandbox.
```
gh auth token | sbx secret set --registry ghcr.io --password-stdin
```
--all-sandboxes and --sandbox widen this differently — do not confuse them:
- --all-sandboxes: credentials are used for host pulls and injected by the proxy into every new sandbox's registry login (the credential itself never enters the sandbox filesystem).
- --sandbox NAME: credentials are injected into that one sandbox only.
- Neither flag: host-pulls-only, injected nowhere.
```
gh auth token | sbx secret set --all-sandboxes --registry ghcr.io --password-stdin
gh auth token | sbx secret set --sandbox my-sandbox --registry ghcr.io --password-stdin
```
For a registry whose Bearer auth endpoint lives on a different hostname than the registry itself, pass --registry-auth-endpoint naming the exact trusted HTTPS URL — otherwise the cross-host token exchange is rejected.
sbx secret rm --registry HOST --sandbox NAME removes only that sandbox's registry credential; host-only and global (all-sandboxes) entries are untouched. This does not revoke the upstream token or prevent use of another applicable credential.
```
sbx secret rm --registry ghcr.io --sandbox my-sandbox
```
Without --sandbox, sbx secret rm --registry HOST removes both the host-only and global entries. Add --all-sandboxes to remove only the global entry instead.

For docker agent run --sandbox and docker agent sandbox commands, use docker-agent-run.
For creating, reattaching to, and removing the sandboxes these policies and secrets apply to, use docker-sandboxes-lifecycle.
For declaring secrets:/registries:/bindings: inside a checked-in sbxenv.yaml file that provisions them at environment-create time, use docker-sandboxes-env.
For a kit's own credentials: and permissions.network: declarations (what a kit asks for, as opposed to what the user has approved), use docker-sandboxes-kits.

References

references/sources.md — provenance for every rule above (help captures, source paths, docs URLs).

Assets

None.

Checks

checks/verification.md — Verification runbook for network policy and secret commands (unexecuted runbook; run manually with an isolated --app-name, no real secret values).

Files

ATTRIBUTION.mdAdded by AutoGineer864 B
LICENSELicence file added by AutoGineer11.1 KiB
SKILL.md12.2 KiB
agents/openai.yaml419 B
checks/verification.md5.1 KiB
references/sources.md4.7 KiB
skill.yaml1.3 KiB

LICENSE


                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright 2026 Docker, Inc.

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an API key, Needs a command-line tool

The author says: Standalone `sbx` CLI (not the legacy `docker sandbox` plugin wrapper). Source-verified against repository docker/sandboxes (github.com/docker/sandboxes) @ commit df5c96ba60484fa2c375469dbac912c205da6c37. Cross-checked against an installed sbx v0.42.0-503-g951b7f6d7 (commit 951b7f6d7f6bb260fac15077b607109ffe8ae012, older than the pinned source); no source-only differences were found for the commands this skill covers. `docker_help` does not cover standalone `sbx` syntax.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

Docker

Publisher

Docker (Official)

Source

docker/skills · skills/docker-sandboxes-network-credentials · commit 9f04a05

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by Docker or Docker.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download docker-sandboxes-network-credentials.zip