How to Reduce Prompt Injection Risk When a Coding Agent Fetches Web Pages

When a coding agent fetches a web page, it adds the page’s text to the information it uses alongside the user’s request to decide what to do. An attacker can put instructions in the page text, its comments, or other content the agent retrieves. If the agent follows those instructions, its tools may allow it to change files, run commands, or send information elsewhere.

This attack is called indirect prompt injection: instructions reach the agent through content it retrieves rather than through the user’s message. The practical defense is to limit what the agent can do, isolate tools and data, and review consequential actions. Warnings and content filters provide additional defenses, but they do not reliably prevent every attack.

How a fetched page can trigger an action

A coding agent encounters an injection when it treats page text as a command rather than as information to analyze. For example, a page could tell the agent to ignore the user’s request and run a command that deletes files. The agent’s permissions determine whether it can carry out that mistaken decision. VS Code’s security guidance describes prompt injection in fetched content and tool output, including risks such as file changes and data exposure.

The risk grows when one agent has broad access. An agent asked to summarize public documentation does not need access to private configuration. It also does not need the ability to modify a repository or permission to run shell commands. If the same agent can do all three, malicious page text has more routes to cause harm.

Prompt instructions and permissions address different parts of the problem. Instructions tell the model how to interpret content; permissions determine which actions its tools allow. A warning in the prompt does not constrain a tool, while a permission limit reduces the consequences of a bad decision.

Limit the agent’s access and isolate its tools

Give the agent only the access its task requires. For a read-and-summarize task, allow page retrieval and text analysis. Withhold shell access and repository write access. Keep deployment tools and secrets out of reach as well. This approach, called least privilege, limits an agent’s authority to the minimum needed for its assigned work. OWASP’s prompt-injection guidance also recommends limiting access to sensitive data and tools.

When the agent needs to run commands, use a sandbox, an operating-system or container boundary that restricts what a program can reach. Restrict the command runner’s filesystem access to the relevant workspace and verify which network destinations it can reach. An approval prompt and a sandbox do different jobs: approval asks a person to authorize an action, while the sandbox limits what the command can access when it runs.

Check which tools fall inside each sandbox. A terminal sandbox may restrict shell commands without restricting a browser, fetcher, or other connected tool. VS Code’s documentation, for example, describes sandbox limits for terminal commands and notes that other tools fall outside that boundary. Its trust and safety guidance also documents network and platform-specific limits. Read the documentation for the agent version and configuration in use, then test the boundaries directly.

Restrict requests the agent can send

Limit the destinations an agent can contact when the task permits it, and require review before it sends a request to an unfamiliar destination. Check the full URL and every destination the request reaches after a redirect, not just the domain name. A malicious instruction can try to make the agent include sensitive information in a URL, where the destination receives it as part of the request.

A list of allowed domains can reduce exposure, but checking only the hostname misses some redirects and ways a request can reach its destination. OpenAI’s URL-exfiltration analysis describes how open redirects can undermine naive domain allowlisting under the paper’s stated assumptions. Choose a network policy based on every route the agent uses to send requests, including routes used by tools other than its browser or page fetcher.

Keep page content separate from instructions

Tell the agent to treat retrieved text as untrusted information and to follow the user’s request rather than commands found in a page. Track where retrieved text came from so the agent and reviewer can tell it apart from the user’s instructions. Clear markers at the start and end of page content can reinforce that distinction.

These prompt-level measures help guide interpretation, but they do not enforce access control. In a 2025 adaptive-attack study, researchers tested defenses such as warnings and delimiters. They also tested repeated instructions, detectors, and other approaches. They reported adaptive attack success rates above 50% across the defenses and agents they tested. The result is limited to the study’s setups and supports using protections beyond a warning or delimiter alone.

A content filter can flag suspicious text for review, but hidden, encoded, or transformed instructions can evade screening. Treat a detector’s result as one signal. Keep tool restrictions in place even when the page passes a filter.

Review consequential actions and test the full setup

Require human review before the agent edits sensitive files, commits code, deploys, or sends data externally. Check what the agent plans to do and the details it will use, not just its explanation. Inspect code diffs before integrating changes. A reviewer cannot undo every consequence: restoring a file does not reverse a completed network request, deployment, or change to an external service. VS Code’s approval guidance describes approval controls and their limits.

Test the model, fetcher, and prompts as part of the complete setup. Include the tools, permissions, and sandbox too. Include pages with visible and hidden instructions, requests that redirect, and attempts to pass malicious content from one tool to another. Check whether the agent completes its assigned task and whether any test makes it change a file, run a command, or send a request that includes data without authorization.

Benchmark results show why the test should cover more than simple attack strings. The InjecAgent benchmark contains 1,054 test cases across 17 user tools and 62 attacker tools; its authors reported that ReAct-prompted GPT-4 was vulnerable in 24% of their evaluation. Anthropic later reported lower attack success rates for configurations in its internal browser-use evaluation, while also acknowledging residual risk in its browser safety results. These figures measure different systems, attacks, and success criteria, so they do not establish a general rate for coding agents. Use them as evidence that defenses can improve results and still fail, not as a prediction for your own setup.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com