Make network access a separate sandbox permission

[CHXZAVARKA]

Problem

The local sandbox has a clear filesystem policy, but network access is outside its enforcement contract. That makes workspace-write mean different things on different platforms.

On platforms where the restricted process keeps normal network access, a model can reach arbitrary hosts even though its file writes are limited. On Windows, the current restricted-token backend can remove outbound access entirely, as reported in #1157. A user who needs npm install, git fetch, or a local development server should not have to switch the whole call to danger-full-access just to get network access.

Loopback also needs its own rule. #250 shows why a sandboxed process reaching the Harness control plane is different from reaching a package registry.

Proposal

Make process network access a separate sandbox permission. A tool call should be able to request workspace-write together with a bounded network policy.

A first contract could distinguish:

• inherit: preserve today's platform behavior
• deny: block outbound and loopback connections
• allow: permit declared destinations and deny everything else

Loopback should be explicit rather than included in a broad network grant. Providers should report whether they enforced the requested policy fully, partially, or not at all. A profile should also be able to fail closed when the selected backend cannot enforce it.

How I would implement it

I would split this into two stages.

The first stage would add the provider-neutral policy, enforcement reporting, approvals, and a reliable deny mode. This gives every consumer one contract and removes silent platform differences.

The second stage would add destination allowlists through a local network broker. The sandboxed process would only reach the broker, and the broker would enforce host, port, DNS resolution, and loopback rules. That avoids putting domain matching into Seatbelt, Landlock, Windows ACL, or every shell integration separately.

The same policy should cover Bash, PowerShell, persistent terminals, Code Mode workers, and workflow children. Host-side tools such as web_search can keep their own policy because they do not run inside the model-side process sandbox.

Acceptance criteria

• workspace-write plus deny cannot reach public addresses or the Harness loopback control plane.
• A bounded grant can allow an approved destination without widening filesystem access.
• Loopback requires a separate grant.
• Unsupported enforcement is visible in the tool result and can fail closed by profile policy.
• Bash, PowerShell, terminals, Code Mode, and workflow children apply the same network contract.
• The sandbox documentation includes a platform matrix for filesystem and network enforcement.

The current filesystem-only scope is documented in the sandbox subsystem. This proposal keeps that boundary explicit while adding a separate capability for network access.

[Electricitysheep]

网络访问从文件系统沙箱里独立出来（单独权限项）——很对，"workspace-write 语义模糊"（文件权限 vs 网络行为混在一起）确实是安全隐患。

这和我们在第 13 章讲的权限模型（工具权限分级/最小权限）一致：网络应该是显式授予的能力，而不是沙箱的隐式附带。https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/13-security.md