Should a cloud agent's setup phase have more internet than its work phase?

Yes, in most cases. Let a setup step fetch dependencies with the access it needs, then run the agent with a much narrower network. That way the part that executes model-driven commands has the least reach. The catch is that setup itself runs code from your dependencies, so it needs scrutiny too.

How one platform splits it

One vendor documents that its cloud environments block internet access during the agent phase by default, while setup scripts still run with internet access so they can install dependencies. Internet access for the agent phase can be turned on per environment, with a domain allowlist and a method limit.

Another platform lets you define a setup workflow that installs tools before the agent starts. It documents that without setup steps, the agent installs dependencies by trial and error, which can be slow and unreliable and may fail for private dependencies. Setup steps make that deterministic. It also notes that its firewall does not directly cover processes started in setup steps.

Put those together and you get a useful pattern. Setup is predictable and scripted, so you can review and pin it. The agent phase is open ended, so it gets the tight network.

Why the split helps

The agent phase is where prompt injection can steer behavior. OWASP describes indirect injection as instructions hidden in content the model processes, such as files or web pages. A tight network during that phase limits where an injected instruction can send data.

What the split does not fix

• Setup is code execution. Install scripts from dependencies run with whatever the setup phase has. Pin versions and prefer lockfile installs.
• Secrets present at setup may persist. One platform's page does not say how secrets are exposed to setup versus agent phases, so check this for your vendor rather than assume.
• The agent may need packages later. If it hits a block, you will see failures. Decide whether to widen access or add the package to setup.
• Caching copies the result. One vendor caches what a setup script installs, so a compromised install could repeat across sessions until the cache is rebuilt.

A starting recipe

1. Write setup as a script in version control with reviewed changes.
2. Use lockfiles and exact versions.
3. Allow only registries you actually use during setup.
4. Switch to none, or a short custom list, for the agent phase.
5. Rebuild cached environments on a schedule and when a dependency advisory affects them.
6. Check whether tokens used for setup are still present in the agent phase, and remove them if so.

Worked example: what a setup run actually does

An illustrative scenario for a service with a lockfile of a few hundred packages.

During setup, the script runs a lockfile install. That one command downloads each listed package and its transitive packages. Some run install scripts. The script then runs a build step that compiles native code, and finally warms a test database. All of this happens with network access to the registries, and perhaps with a read-only token for a private feed.

Then the agent phase begins with the network cut. The agent edits code, runs unit tests, and prepares a branch. It does not need the registry, because everything it needs was installed in setup. If it tries to add a new package, that request fails, and the agent reports the block, which is the correct outcome: adding a dependency becomes a human decision.

This pattern also changes how you review. In setup you review the script and the lockfile. In the agent phase you review the diff, including any attempt to change the lockfile.

Phase comparison

Steps to implement the split

1. Put install and build in a script that runs before the agent, and version it.
2. Give that phase read only access to the specific feeds it needs.
3. After setup, revoke or discard setup credentials.
4. Switch the network policy to deny for the agent phase, or to a short list.
5. Make dependency changes a deliberate action: the agent proposes, a person approves, and the next setup run installs.
6. Record the installed package list as an SBOM for each environment build.

Edge cases

• Tools that download at run time. Some test frameworks fetch browsers or data on first use. Pre-fetch them in setup.
• Language servers and formatters. Install during setup, so the agent phase stays quiet.
• Private package changes mid task. If the agent legitimately needs a newly published internal package, publish it first and rebuild the environment.
• Caches. If the platform caches setup output, rebuild it when a dependency advisory lands. One vendor documents that its cache keeps what a setup script installs, so staleness is your problem to manage.

When the split does not fit

Some tasks, such as research agents that browse documentation, need network access during work. For those, use an allowlist of specific documentation hosts and method limits, and keep the agent away from credentials entirely.

Where Safeguard fits

Safeguard does not control the platform network. Its dependency scanning and policies can check what a setup script installs, and you can run a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Click through it and look at how direct and transitive packages appear, since setup installs both.

Quick check

Sources

• Codex cloud internet access (OpenAI documentation)
• Customize the Copilot cloud agent environment (GitHub Docs)
• Customize the Copilot cloud agent firewall (GitHub Docs)
• Configure cloud environments (Anthropic documentation)
• OWASP LLM01:2025 Prompt Injection

Last reviewed: 19 October 2026.