Allow it narrowly. Give an agent access to a short allowlist of documentation hosts and package mirrors, and block the rest. Open web access feeds untrusted text into the model and offers a way to send data out, so do not combine it with credentials or write access.
Two risks in one feature
Web access does two things. It brings text in, and it lets requests go out.
In. Any page the agent reads can carry instructions aimed at it. OWASP lists Prompt Injection as LLM01 in its 2025 Top 10 for LLM applications. The agent cannot reliably separate a page's content from an instruction.
Out. A request to a URL can carry data in the path or query. If an agent holding a secret can reach any host, a hijacked agent can send the secret anywhere.
The MCP security guidance covers a related problem for clients that fetch URLs: server-side request forgery. It describes how a malicious server can point a client at internal addresses or cloud metadata endpoints, and recommends blocking private and link-local ranges and considering an egress proxy.
Options
| Option | Risk | When it fits |
|---|---|---|
| No web access | Lowest | Sensitive repositories, CI jobs |
| Allowlisted hosts only | Low to moderate | Most teams, covering documentation and mirrors |
| Search through a separate, read-only agent | Moderate | Research tasks with no access to code or secrets |
| Open web with the coding agent | High | Throwaway experiments only |
Splitting roles
The cleanest design separates the agent that reads the web from the agent that touches code. The researcher has no credentials and no write access, and it returns a summary that a person reviews. The coder has repository access and no web access. A hijacked researcher can only produce bad text, and a person sits between that text and the code.
Practical steps
- List the hosts the agent really needs. Documentation sites, your package mirror, your internal wiki if appropriate.
- Enforce the list at the network layer, in the sandbox, not only in tool settings.
- Block private ranges and cloud metadata addresses for any fetch the agent makes.
- Strip or ignore redirects to unlisted hosts, since a listed site can bounce to an unlisted one.
- Log every outbound request with host and size. Odd destinations are the signal.
- Review what the agent learned from the web before accepting code that depends on it, for example an API usage it found online.
Our post on agent runtime egress controls goes further on network limits.
The package question
Fetching a package is web access too. When an agent installs a dependency, it pulls code from a registry and runs install scripts. Route it through a mirror you control and gate new packages with checks before they land in a merge.
Test it
In a sandbox, plant a page with a harmless injected instruction, point the agent at it, and see whether it acts. Then try fetching a blocked host and a private address. Your results tell you which layers hold.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: allowlisting for a Node service
A team builds an allowlist for their coding agent by watching a week of traffic in a sandbox with logging on.
| Host category | Examples seen | Decision |
|---|---|---|
| Model endpoint | The vendor's API host | Allow |
| Package mirror | Internal mirror host | Allow |
| Public registry | Direct registry host | Block, use the mirror |
| Framework documentation | Two documentation sites | Allow |
| Code hosting site | Public code hosting | Block, use mirrored copies |
| Q and A and forum sites | Several | Block, risk of hostile text |
| Unknown hosts | Three one off requests | Block, investigate |
The three unknown hosts were interesting. Two came from a documentation page that linked to an analytics script. The third was a link inside a README in a dependency, which the agent followed. Without logging, nobody would have known. After the review, the team added the documentation sites to the allowlist and left the others blocked.
The two roles design
| Role | Web access | Repository access | Credentials | Output |
|---|---|---|---|---|
| Researcher | Allowlisted or open | None | None | Text summary for a person |
| Coder | None or mirror only | Yes, scoped | Scoped, short lived | Diff for review |
A human carries information from researcher to coder by reading and rewriting it. This breaks the chain by which hostile text on a web page could steer an agent that holds write access.
Mirrors and vendored docs
If your agent needs documentation, copy it into a folder in the sandbox. Many teams mirror the handful of documentation sites they use. This removes live browsing for most tasks, and the content can be reviewed once.
Handling redirects and metadata addresses
Guidance for tool clients on fetching URLs recommends blocking private and link-local address ranges, which include cloud metadata endpoints, and treating redirects with care. Apply the same ideas to any fetch the agent performs. Use a proxy that enforces them, since hand written checks miss encoding tricks.
Checklist before enabling web access
- Is there a named reason for each allowed host?
- Is the allowlist enforced outside the agent?
- Are private ranges blocked?
- Is every request logged with host and size?
- Is web access separated from credentials and write access?
- Is there a review date for the list?
What to log
Capture the host, path length, response size, and which session asked. Long paths and large uploads to unusual hosts are the pattern to watch. A real review looks at the top ten new hosts each month and decides allow or block for each.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice how ongoing monitoring surfaces new behavior after setup.
Quick check
Can the agent just read documentation offline?
Often yes. Mirror or vendor the docs you need, and the agent loses little by having no live web access.
Is a search tool different from browsing?
It still returns untrusted text. Treat results as input to review, not as instructions.
Is a package registry fetch also web access?
Yes. Route installs through a mirror you control and gate new packages with checks before they reach a merge.
Sources
Last reviewed: 19 October 2026.
