Should coding agents declare their network capabilities per task?

I want agentic developer tools to produce a machine-readable network capability manifest for every task: files they may read, APIs and package registries they may contact, and model providers they may use. If an undeclared cloud dependency appears, the task should fail closed rather than quietly proceed.

Our convenience-first workflows make this fuzzy. A local-looking command can involve remote inference, package downloads, MCP services, telemetry, or uploaded diagnostic context. Copilot’s cloud agent has a configurable firewall, while Claude Code documents required internet access for authentication and processing; npm install can also pull transitive dependencies. Local-only modes exist, but they are not a universal task contract.

The cost is friction across CI, containers, registry mirrors, and genuinely offline environments. Should manifests be enforced by the toolchain, merely displayed, or left to project policy? Concrete counterexamples welcome.

Display-only is a warning label, not a boundary. I would require enforcement at the process boundary, with an explicit escape hatch for a human-approved task. The manifest should cover subprocesses and data classes too; domain allowlisting alone does not say whether source code or credentials can leave.

The hard part is transitive behavior. A manifest naming npm is not enough if an install script contacts somewhere else, and containers can hide that behind a subprocess. I like fail-closed in CI, but interactive development probably needs a staged mode: log first, enforce in reproducible runs.

I agree with the goal, but “every task” may be the wrong product surface. Most developers will accept a manifest they never read if the defaults work; they will resist a tool that stops for every registry mirror. Make the safe path boring and the exception path visible.

For offline work, the manifest could be a capability set rather than a list of domains: local model, local package cache, mounted workspace, no network. That is easier to reproduce across a laptop, container, and CI runner than trying to infer intent from shell commands after the fact.

I would separate two questions: what the tool intends to contact, and what the operating environment permits. A manifest can answer the first; firewall or sandbox policy must enforce the second. Treating one as a substitute for the other risks overstating the guarantee.

Counterexample: debugging a broken build often means adding a one-off registry or fetching a platform-specific artifact. A hard failure turns a ten-second fix into policy maintenance. I would accept fail-closed for release and CI jobs, but keep an explicit, noisy override locally.

Project policy sounds attractive until the policy has to cover shared runners, private registries, proxy settings, and rotating credentials. Still, a checked-in manifest would give operations something concrete to review instead of screenshots of agent settings. Enforcement could vary by environment.

I’m not convinced the task boundary is stable enough. “Fix the tests” can reveal a missing package, which triggers a registry request, which triggers an install script. A manifest that must predict all of that may become either uselessly broad or so restrictive that people disable it.