Network Access for Cloud Coding Agents: Default-Deny by Design

Agent internet access should be off by default and enabled only for named destinations and task phases that genuinely need it.

This guide focuses on the engineering decision behind cloud coding agent network access: what to standardize, what to constrain, and what evidence a reviewer should expect before accepting the result.

The core decision

Setup often needs package registries, while the coding phase may need no external network at all. Separate those phases. Build an allowlist from actual dependency and documentation requirements, and route outbound traffic through a proxy that can log destinations without exposing secret values.

A workflow that holds up in review

Test three cases: normal allowed traffic, a request to an unapproved domain, and an attempt to send repository content outward. Make failure explicit so the agent cannot silently substitute an untrusted source or skip an important check.

The failure mode to design around

Unrestricted access increases both exfiltration risk and nondeterminism. Remote pages can change, disappear, or contain hostile instructions. Bring required evidence into the task or use approved documentation tools rather than giving the agent the whole web.

Implementation checklist

Separate setup and agent-phase access.
Allowlist domains by task class.
Log egress metadata.
Test denied and exfiltration scenarios.

Turn the checklist into operating controls

Separate setup and agent-phase access: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Allowlist domains by task class: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Log egress metadata: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Test denied and exfiltration scenarios: name the owner, the evidence that proves it happened, and the condition that should stop the run.

The list becomes useful when every item produces visible evidence. Store that evidence with the task or pull request rather than in a private chat. A future reviewer should be able to tell which repository revision was used, which permission profile applied, what stopped or failed, and who accepted the remaining risk. For cloud coding agent network access, a short, complete record is more valuable than a long narrative that cannot be reproduced.

Move from one run to a repeatable practice

Promote environment changes like build-system changes. Review the script and image inputs, test a clean build, test a warm build, and record the cache key. Roll the change out to a small task set before making it the shared default. Keep the previous environment definition available long enough to reproduce an active incident. If developers cannot run the core setup locally or in another sandbox, document why and provide an equivalent diagnostic path.

Before expanding the workflow, ask three review questions:

What evidence shows that separate setup and agent-phase access was satisfied, and would that evidence survive a rerun from the recorded commit?
What evidence shows that allowlist domains by task class was satisfied, and would that evidence survive a rerun from the recorded commit?
What evidence shows that log egress metadata was satisfied, and would that evidence survive a rerun from the recorded commit?

Write the answers in the same place as the code review. That creates a compact decision record and lets the team compare later runs without relying on memory.

A practical acceptance test

Run the workflow from a clean checkout at a recorded commit. Give the agent only the documented task packet and the intended permission profile. Then ask a reviewer who did not launch the run to reproduce the important checks, explain the changed behavior, and identify the rollback path. The task passes only when the artifact, evidence, and repository state agree. Keep the failed examples as regression cases; they are more useful than a polished demo because they reveal where instructions, environment, permissions, or tests need improvement.

Primary references

Vendor features, limits, preview labels, and pricing can change. Recheck the linked first-party documentation for the current state before making a purchase or rollout decision.