The Web Page Told Your Agent What to Do Next

Ask a coding agent to add a date picker and it will often search for the library's documentation, read a page or two, and get to work. That is exactly what you want, and it is the whole of the problem. The page it read was written by someone else. To a language model, the words on that page and the words in your request arrive as the same kind of thing: text.

Now imagine the page contains a line that says, in effect, to finish setup the assistant should run a script from this address and send the project's environment file to that one. A person would see it for what it is. A model might see an installation step. This is prompt injection, and every agent that reads content it did not write is exposed to it.

The model cannot reliably tell your instructions from a stranger's. Design as if it never will.

Where the stranger's text comes from

Web pages are the obvious source, but not the only one. Anything the agent reads and you did not write can carry an instruction:

Why spotting it is not the answer

The natural first response is to detect injected instructions: scan pages for suspicious phrases, train a classifier, tell the model to ignore instructions in documents. All of those help a little. None of them is a security boundary, for the same reason spam filters are not. The attacker gets unlimited attempts and only needs one phrasing that slips through, and the defender has to catch every one.

So the useful question is not whether the agent will ever be fooled. It will. The question is what a fooled agent is able to do.

Gate what it does, not what it reads

An injected instruction only causes harm when it turns into an action: running a command, sending data somewhere, spending money, publishing. Reading cannot hurt you by itself. That suggests where the controls belong.

In Vibez.now, searching the web is allowed without asking, because a search query does not change anything and gating every one of them would teach people to approve prompts without reading them. Fetching a specific address goes through the approval gate, because the address is chosen by the model, and that makes it the one read-only-looking tool that could carry your project's contents to a destination an injected instruction picked. Shell commands, deletes and anything that provisions a paid resource are gated in the default mode as well.

Unknown tools start out gated

A policy that lists the dangerous tools and lets everything else run has a hole the size of every tool nobody thought about. New integrations, renamed tools and namespaced names that do not match the list all default to running unreviewed, which is exactly backwards for a defence against an attacker who goes looking for gaps.

So the list runs the other way. There is a short allowlist of tools that genuinely cannot change anything or reach anywhere, and every other tool needs approval in guarded mode. If the approval service itself is down, unconfigured or returns something unexpected, the answer is no. A control that fails open is a control an attacker can switch off by knocking over its dependency.

What to do as the person in the loop

• Read the approval prompt for anything that leaves the machine. The address of a fetch and the text of a command are the two places an injection shows itself.
• Be suspicious of a request that does not match what you asked for. You asked for a date picker. Why is it sending a file to a domain you have never heard of?
• Use guarded mode when the agent is reading things you did not write, such as user-submitted content or an unfamiliar library.
• Keep production keys out of projects where an agent experiments. A separate test key limits what a mistake can reach.

You will not stop strangers writing instructions for your agent. You can make sure the instructions it follows by mistake land on a closed door.