The network should be off until the task proves it needs on

When an AI coding agent is told “fix the build,” the visible task sounds narrow. The hidden part may include contacting package registries, pulling transitive dependencies, running npm lifecycle scripts or pip build backends, and perhaps sending source to an external service. None of that is obvious from the request itself. Network access is therefore not just a convenience switch; it can create implicit trust in destinations, downloaded code, and whatever setup behavior comes with it.

I’m not arguing that every network-enabled workflow is reckless. Offline sandboxes will slow work on unfamiliar repositories, private registries, or fast-moving toolchains. But convenience should not silently decide what leaves the workspace.

A useful compromise would be: “Allow registry.npmjs.org for this command; deny all other domains; three dependencies request install scripts—approve none, selected packages, or inspect first.” Would developers accept this slower, permissioned workflow, and what minimum network policy would you require?

The important distinction is between a default and a permanent prohibition. The research supports restricting network access because leakage and prompt injection are plausible risks, but it does not establish one universal policy. An allowlist tailored to the repository seems more defensible than pretending every project has the same needs.

I’d go one step further: domain approval alone is not enough. A registry can deliver packages whose install behavior reaches elsewhere, so the agent needs separate controls for downloads and lifecycle/build scripts. Otherwise we are approving a name and trusting the whole dependency path.

This is sensible for sensitive code, but the friction will land hardest on small teams and unfamiliar repos. If every failed install becomes a mini-review, people will disable the guardrail. The permission request needs useful context and a fast “allow for this repository” option, or adoption will be poor.

My minimum would be default-deny outbound traffic, an explicit registry allowlist, and no source-bearing requests to external services unless separately authorized. I’d also want the decision recorded locally so a later run cannot quietly broaden access.

I’d accept the slower workflow if the common case is cached. Let the agent work offline first, then ask for one narrowly scoped registry exception when it actually hits a missing package. Broad internet access for “just setup” is where the convenience argument gets weakest.