Could a web page give your agent orders?

White text on a white background is still text to a machine. Imagine a line in a web page telling the reader to ignore its earlier orders and send a config file somewhere. A human eye skips it, and an agent reads it at full weight. Nothing was broken into. The page was quoted correctly, which is the whole trouble.

Models can receive role labels and instruction hierarchies, but they still have to interpret untrusted material without treating it as a new command. An attacker can place instructions inside that material and try to influence the next action. That attempt is prompt injection. The version people picture, a user typing a trick into a chat box, is the less interesting one. The version that lands arrives inside something you sent the agent to read for you: a web page, a document, a filename, a support email, an issue comment.

The usual defence is one more sentence in the system prompt asking the model to be careful, and that sentence lives in the same channel as the attack. It may lower how often a trick works, but it cannot bring that rate to zero, and an attacker only needs to be believed once.

Change what believing it is worth

If you cannot reliably spot the bad sentence, what you can still change is what the agent is able to do after believing it. Look at three capabilities:

access to private data: your database, your files, someone's inbox;
exposure to untrusted content: anything written by people you do not control;
a way to send information out: an HTTP request, an email, a message, even an image URL it can get rendered.

This combination creates a direct route for data exfiltration; it is a way to inspect risk, not a proof that any other combination is safe. The untrusted content supplies the instructions, the private data supplies something worth taking, and the outbound channel carries it away. When a job needs all three, separate retrieval from external actions and enforce which data may leave through which tool. Human review can be one gate; a narrowly scoped tool with deterministic checks is another. A reminder in the prompt does not enforce that boundary.

The OWASP list of risks for LLM applications puts prompt injection first and lists excessive agency separately. You build the second one yourself, usually by handing over write access because scoping the read access properly would have taken twenty more minutes. Blast radius is decided when you mint the token, not when the agent misbehaves. Giving an agent production credentials with delete rights is a bet that it will never be confused, let alone persuaded.

A worked example

Picture a support agent that reads incoming emails, looks up the customer's orders and drafts a reply. As first specified, it has a database connection with full access and can send email to any address.

Before reading on, list what it holds. Private data: yes. Untrusted content: yes, every incoming email. A way out: yes, it can mail anyone. All three.

Now cut. Have the application establish the customer through an authenticated support session, not the email's claimed From field. Expose a tool that returns only that customer's relevant orders, using a server-verified identity the model cannot substitute. Let the model draft a reply for review; if automatic sending is needed, the application fixes the verified recipient and checks the allowed fields. A forged sender header must not unlock another customer's order history.

What rabadon does with this

Rabadon separates proposals from checks. An observing mode and a blocking gate are different capabilities: recording that an action happened does not prevent it. When evaluating an agent tool, inspect which mode is active and which operation the gate actually controls.

The repair mode is where authority gets spent, so it is fenced. Before a repair starts, the files that make up the test harness are hashed and locked, so a repair cannot pass by editing the tests. A fix also has to show red first, with a check that fails on the broken code, and green afterwards. The repair check rejects changes to those locked files. This is a verification rule within the repair workflow, not an operating-system boundary against a process that can rewrite the verifier itself.

Exercise

Pick one agent or automation you run and write a table: every tool, token and permission it holds, and which of the three capabilities each one grants. Then remove or narrow one entry and confirm the job still works.

The question about your agent is not what a stranger might say to it. It is what the agent is holding while they say it.