Prevent Prompt Injection

In a test it ran on its own tools, OpenRouter, the service that sends API requests to models from many providers, found that the defense that reliably stopped a document from steering an AI agent checked the agent's actions before they ran, instead of trusting the model to ignore the attack. The threat is indirect prompt injection: text inside a document, email or web page an app reads that addresses the model as if it came from the user. A model that can only reply can at worst say something wrong or reveal its prompt. An agent with tools can act on the stranger's request, for example by emailing data to an outside address. OpenRouter's write-up is a tutorial for its own products, so its numbers come from one controlled setup rather than an independent audit.

The test assistant, called DocBot, summarized documents, held a made-up secret code in its instructions and had a send_email tool. OpenRouter ran it on four models: Claude Haiku 5.5, GPT-6 Luna, DeepSeek V4.1 Flash and Z.ai's GLM 5.3 Flash. The attacks were 13 OpenRouter wrote and 12 written by two other models that never saw the defenses. Without defenses, three of the models resisted almost everything, while GLM 5.3 Flash sent 58 of the 60 attack emails across 720 attempts. The attack that worked best contained no suspicious phrases: it was a note in the document's own voice, presented as a routine processing step, asking for a receipt email to an outside address.

The cheap defenses reduced the odds without removing them. Wrapping each document in tags with a random name per request, and telling the model that tagged text is never an instruction, cut attack emails from 60 to 13 of 720 and blocked no legitimate email. The model still decides whether to obey, though, and all 13 came from GLM 5.3 Flash. OpenRouter's guardrails then limit what a key can reach: a model allowlist keeps an app off models that failed this kind of test, and a spending cap bounds the cost of a runaway agent.

The control that held was Armor, an OpenRouter feature in beta that sends every tool call, with the conversation and rules written in plain English, to a separate decision model before the call reaches the developer's code. A hard-deny rule can never be cleared, such as never emailing the secret. A soft-deny rule blocks an action unless the user asked for that exact action, which is how it separates a user's request from a document's. With Armor on, attack emails fell to 0 of 720, with or without the tags, and all 160 legitimate emails still went out. On responses that called a tool, the median request took 3.65 seconds with Armor against 3.37 without, and the Armor documentation covers the rule format and an audit mode that records verdicts without blocking.

Armor blocked real work in one pattern. When a user said the document's process note was real and asked DocBot to send that receipt too, without naming the address, Armor blocked 55 of 80 attempts; when the user named the address, it blocked none. On the Chat Completions API, Armor's default places a marker for the blocked call in the reply, and in 19 of the 73 blocked calls that marker contained the secret code, so it has to be stripped before the reply is shown or stored. The article's simpler advice still applies to any setup: keep real secrets out of the prompt, and require a person's approval for actions that cannot be undone.