A sandbox needs network and secret boundaries

Draw five boundaries

A sandbox review should map filesystem reads and writes, outbound and local network reachability, injected credentials, child processes, and artifacts leaving the environment. Constraining only writes to the repository still permits source exfiltration over an open network. Blocking the public internet while allowing an internal network may expose services that were never designed for hostile code. Removing explicit API keys does not help if the process can reach a user credential helper, cloud metadata endpoint, or authenticated local socket. GitHub's sandbox documentation separates filesystem, network, credentials, and subprocess controls, which is a useful inventory. It is a product description, not evidence that any unexamined configuration meets a team's threat model.

Separate acquisition from execution

Many coding tasks need packages or documentation, creating pressure to grant broad internet access. Use a staged design. An acquisition phase may fetch approved dependencies through a registry proxy, verify lockfiles or checksums, and populate a clean cache. The execution phase receives that cache but no general egress. If live documentation is necessary, allow specific domains and treat downloaded text as untrusted context, never as executable instruction. GitHub documents a firewall and allowlist controls for its cloud agent, explicitly connecting limited internet access with exfiltration risk. Allowlists reduce reachability; they do not make an allowed host trustworthy, prevent DNS mistakes, or inspect data encoded in permitted requests. Record the exact policy used for each run.

Worked example: a hypothetical pull-request repair

A hypothetical agent is asked to repair a failing test in an external contributor's pull request. The repository code is untrusted because build scripts can execute during installation. The first job checks out the change with a read-only token, no repository secrets, no internal network, and egress only to a package proxy. It produces test logs and a patch artifact. A second trusted job inspects the artifact as data and may publish a status after human approval; it never executes the contributor's workspace. GitHub's guidance on pull request workflows similarly withholds secrets from untrusted fork runs and warns about executing fork code in privileged pull_request_target jobs. The hypothetical split reduces privilege crossing without claiming to eliminate malicious dependency or artifact risk.

Prove denials and clean teardown

A policy file is not enough. Add canary tests that attempt a write outside the workspace, access a denied environment variable, connect to a blocked public host and internal address, invoke an unsandboxed child process, and recover credentials from common helpers. The expected result is a recorded denial with no secret value echoed. After the run, verify that the environment is ephemeral or sanitized: processes are gone, temporary files and caches are handled by policy, and credentials are revoked or expired. Inspect output channels too. A patch, log, trace, or test artifact can carry sensitive content out of an otherwise constrained runtime. Re-run these checks after platform updates because the boundary is an implemented system property, not a permanent label.

GitHub sandbox controls ↗

GitHub Copilot firewall configuration ↗

Assign control ownership

Name the owner of each boundary and its denial tests. Otherwise a failing network probe or credential leak can linger while repository, platform, and security teams each assume another group controls it. Changes to an allowlist, credential mount, or subprocess exception should receive the same review as code that invokes the capability.