2026年4月29日 18:41

4 ファイル変更+15-11

この更新の概要

ネットワークサンドボックスにおけるドメイン制限の仕組みが具体化され、Python SDKにallowedDomainsなどの新しい設定オプションが追加されました。組み込みプロキシがTLSトラフィックの終端や検査を行わない仕様であることが明文化され、ドメインフロントリングによる制限回避のリスクが説明されています。より高度なセキュリティが必要な開発者向けに、TLS終端プロキシの構築やカスタムプロキシ構成への誘導が強化されました。ファイルシステムやネットワークのアクセス制限が、サンドボックス設定ではなくパーミッション設定から派生する点も整理されています。

agent-sdk/python+8-8

allowedDomainsやdeniedDomainsなど、サンドボックスプロセスがアクセス可能なドメインを制御するための新しい設定フィールドが追加されました。また、ファイルシステムやネットワークの制限はパーミッション設定から派生し、コマンド実行のみサンドボックス設定を使用するよう役割が整理されました。

@@ -3051,14 +3051,6 @@ class SandboxSettings(TypedDict, total=False):

**Filesystem and network access restrictions** are NOT configured via sandbox settings. Instead, they are derived from [permission rules](/en/settings#permission-settings):

- **Filesystem read restrictions**: Read deny rules

- **Filesystem write restrictions**: Edit allow/deny rules

- **Network restrictions**: WebFetch allow/deny rules

Use sandbox settings for command execution sandboxing, and permission rules for filesystem and network access control.

#### Example usage

```python

@@ -3085,6 +3077,9 @@ Network-specific configuration for sandbox mode.

```python

class SandboxNetworkConfig(TypedDict, total=False):

allowedDomains: list[str]

deniedDomains: list[str]

allowManagedDomainsOnly: bool

allowLocalBinding: bool

allowUnixSockets: list[str]

allowAllUnixSockets: bool

@@ -3094,12 +3089,17 @@ class SandboxNetworkConfig(TypedDict, total=False):

| :- | :- | :- | :- |

| `allowManagedDomainsOnly` | `bool` | `False` | Managed-settings only: when set in managed settings, ignore `allowedDomains` from non-managed settings sources. Has no effect when set via SDK options |

The built-in sandbox proxy enforces the network allowlist based on the requested hostname and does not terminate or inspect TLS traffic, so techniques such as [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting) can potentially bypass it. See [Sandboxing security limitations](/en/sandboxing#security-limitations) for details and [Secure deployment](/en/agent-sdk/secure-deployment#traffic-forwarding) for configuring a TLS-terminating proxy.

### `SandboxIgnoreViolations`

Configuration for ignoring specific sandbox violations.

agent-sdk/secure-deployment+1-1

組み込みプロキシがホスト名に基づいて許可リストを適用し、TLS検査を行わないことによるドメインフロントリングのリスクが追記されました。高いセキュリティ要件がある場合に、TLS終端プロキシを設定するための詳細な案内が追加されています。

@@ -99,7 +99,7 @@ Then create a configuration file specifying allowed paths and domains.

1. **Same-host kernel**: Unlike VMs, sandboxed processes share the host kernel. A kernel vulnerability could theoretically enable escape. For some threat models this is acceptable, but if you need kernel-level isolation, use gVisor or a separate VM.

2. **No TLS inspection**: The proxy allowlists domains but doesn't inspect encrypted traffic. If the agent has permissive credentials for an allowed domain, ensure it isn't possible to use that domain to trigger other network requests or to exfiltrate data.

2. **No TLS inspection**: The proxy allowlists domains based on the client-supplied hostname and does not terminate or inspect encrypted traffic. Code running inside the sandbox can potentially use [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting) or similar techniques to reach hosts outside the allowlist. If your threat model requires stronger guarantees, configure a [TLS-terminating proxy](#traffic-forwarding). See the [sandboxing security limitations](/en/sandboxing#security-limitations) for more detail. Separately, if the agent has permissive credentials for an allowed domain, ensure it cannot use that domain to trigger other network requests or to exfiltrate data.

For many single-developer and CI/CD use cases, sandbox-runtime raises the bar significantly with minimal setup. The sections below cover containers and VMs for deployments requiring stronger isolation.

agent-sdk/typescript+2-0

組み込みプロキシがリクエストされたホスト名に基づいて制限を強制することや、TLS検査を行わない設計上の制約が明記されました。ドメインフロントリングによる回避の可能性と、必要に応じたTLS終端プロキシ構成の検討を促しています。

@@ -2853,6 +2853,8 @@ type SandboxNetworkConfig = {

The built-in sandbox proxy enforces `allowedDomains` based on the requested hostname and does not terminate or inspect TLS traffic, so techniques such as [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting) can potentially bypass it. See [Sandboxing security limitations](/en/sandboxing#security-limitations) for details and [Secure deployment](/en/agent-sdk/secure-deployment#traffic-forwarding) for configuring a TLS-terminating proxy.

### `SandboxFilesystemConfig`

Filesystem-specific configuration for sandbox mode.

sandboxing+4-2

ネットワークサンドボックスの制限事項として、TLS検査が行われないことによる具体的なセキュリティ上の影響と対策が詳細に記述されました。信頼できないドメインの許可に伴うデータ漏洩リスクや、カスタムプロキシによる証明書運用の必要性について説明されています。

@@ -52,6 +52,8 @@ Network access is controlled through a proxy server running outside the sandbox:

- **Custom proxy support**: Advanced users can implement custom rules on outgoing traffic

- **Comprehensive coverage**: Restrictions apply to all scripts, programs, and subprocesses spawned by commands

The built-in proxy enforces the allowlist based on the requested hostname and does not terminate or inspect TLS traffic. See [Security limitations](#security-limitations) for the implications of this design, and [Custom proxy configuration](#custom-proxy-configuration) if your threat model requires TLS inspection.

### OS-level enforcement

The sandboxed bash tool leverages operating system security primitives:

@@ -216,9 +218,9 @@ When Claude Code attempts to access network resources outside the sandbox:

## Security Limitations

- Network Sandboxing Limitations: The network filtering system operates by restricting the domains that processes are allowed to connect to. It does not otherwise inspect the traffic passing through the proxy and users are responsible for ensuring they only allow trusted domains in their policy.

- Network Sandboxing Limitations: The network filtering system operates by restricting the domains that processes are allowed to connect to. The built-in proxy does not terminate or perform TLS inspection on outbound traffic, so the contents of encrypted connections are not examined. You are responsible for ensuring that only trusted domains are allowed in your policy.

Users should be aware of potential risks that come from allowing broad domains like `github.com` that may allow for data exfiltration. Also, in some cases it may be possible to bypass the network filtering through [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).

Allowing broad domains such as `github.com` can create paths for data exfiltration. Because the proxy makes its allow decision from the client-supplied hostname without inspecting TLS, code running inside the sandbox can potentially use [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting) or similar techniques to reach hosts outside the allowlist. If your threat model requires stronger guarantees, configure a [custom proxy](#custom-proxy-configuration) that terminates TLS and inspects traffic, and install its CA certificate inside the sandbox. Stronger TLS-aware network isolation is an active area of development.

- Privilege Escalation via Unix Sockets: The `allowUnixSockets` configuration can inadvertently grant access to powerful system services that could lead to sandbox bypasses. For example, if it is used to allow access to `/var/run/docker.sock` this would effectively grant access to the host system through exploiting the docker socket. Users are encouraged to carefully consider any unix sockets that they allow through the sandbox.

- Filesystem Permission Escalation: Overly broad filesystem write permissions can enable privilege escalation attacks. Allowing writes to directories containing executables in `$PATH`, system configuration directories, or user shell configuration files (`.bashrc`, `.zshrc`) can lead to code execution in different security contexts when other users or system processes access these files.