Prompt injection in HTTP headers adds a risk for AI agents

Attempts to manipulate AI agents are appearing in HTTP response headers, the metadata that accompanies web content. According to The Register – Security, researchers found attempts on 30 sites in a large crawl sample, mostly as pranks and with little likelihood of anyone having been affected. The finding exposes a conditional risk, not evidence of a successful attack campaign: an agent must first receive the headers before their instructions can influence it.

What happened

Security firm Signals Corps examined 217 million HTTP page responses from Common Crawl. Almost 8,000 sites sent header messages addressed to AI agents, although most were offering directions rather than attempting manipulation.

Of those sites, 7,271 supplied pointers telling agents where to go next, while 6,989 sent the x-llms-txt header. These figures describe related categories of messaging, not separate totals to be added together. The presence of an AI-facing header was not, by itself, evidence of an attack.

The researchers identified attempted indirect prompt injection on 30 sites. Most of the attempts—22—were classified as little more than pranks. Examples included demands that an AI delete its training data and rebel, and a header combining an instruction to disregard earlier directions with an SQL-style command to drop database tables. Neither example establishes that the requested action was possible, let alone performed.

Other messages had a more plausible target. One header contained a refusal-triggering string associated with Claude. According to the report, that string could make Claude refuse to answer when encountered until May 2026. Its appearance in the sample demonstrates an attempt to use a known model behaviour, not that the same mechanism remains effective.

Another header appeared designed to influence an AI hiring screener by asserting that an applicant had a 94% match confidence. That percentage was the website's assertion, not a measured screening result. It illustrates a less theatrical objective: contaminating an assessment rather than persuading a machine to stage a revolution.

The scale of the crawl needs care. The 217 million figure counts HTTP responses; the findings are reported in sites. Dividing the 30 sites by the response count would not yield a meaningful rate of affected websites. Nor does finding an instruction establish that an agent read or obeyed it.

The background

Indirect prompt injection places instructions inside material an agent retrieves while working for someone else. A user may legitimately ask for a page summary; the page, email, file or tool result may then contain an illegitimate request to change the task. The attacker need not control the user's original instruction.

HTTP headers extend that problem beyond the visible page. A response contains protocol information, headers expressed as key-value pairs and, optionally, a body carrying content. Headers can contain both standard and custom fields. Whether their contents reach a language model depends on the software fetching the page and how its results are presented.

That distinction matters because reading a website through an AI tool is not necessarily equivalent to viewing it in a browser. A tool can expose supporting metadata that an ordinary reader would never inspect. The relevant security boundary is therefore the material delivered to the agent, rather than merely the text displayed on screen.

Dedicated material for AI visitors remains relatively uncommon. The Register reports that separate surveys found roughly 3–10% of sites supplying llms.txt, a proposed format for presenting website information to AI systems. About 10% use robots.txt rules to restrict AI crawlers. These figures describe different practices and are not measures of protection against prompt injection.

The predominance of navigational pointers in Signals Corps' findings creates a practical complication. Agent-facing metadata can serve a legitimate purpose, so treating every such field as hostile would confuse intended functionality with abuse. The harder question is which information a tool needs to expose, and whether an agent treats it as evidence or authority.

The business stakes also depend on the task. An injected instruction encountered during summarisation and one encountered during a purchasing workflow do not carry identical consequences. Our earlier coverage of prompt-injection tests involving automated purchases addresses that distinction: the permissions attached to an agent matter alongside the words it reads.

What people are saying

The source's substantive assessment comes from threat researcher Sarah Andrews. In a blog post cited by The Register, she explains the weakness as the language model encountering instructions and retrieved data together in its context. Text alone does not reliably establish which material has the right to issue commands.

Andrews identifies concrete differences between tools. Anthropic's Claude Code would need to run curl with suitable flags to see response headers. Google's Gemini CLI would need its experimental.directWebFetch flag enabled. For Microsoft's Playwright MCP server, the browser_network_request tool returns full headers by default. Those are exposure conditions, not findings that any of the three products was successfully compromised.

The Register judges it statistically extremely unlikely that anyone was affected by the discovered headers. That qualification deserves as much weight as the examples themselves. The reporting presents attempted manipulation and possible delivery routes, but no demonstrated victim, financial loss or successful hiring-screen alteration.

Andrews nevertheless argues that organisations should account for header-based abuse when designing agents. Her recommendations include allowlisting metadata, treating redirect destinations as untrusted and requiring approval for MCP connections. These measures address what outside material and connections an agent is permitted to encounter.

She also recommends labelling external text, checking proposed actions outside the model and escaping model output for the context in which it is rendered. The distinction is important: identifying untrusted input, authorising an action and safely displaying an output are separate controls. Asking the model to recognise suspicious prose does not perform all three jobs.

What happens next

The immediate operational question is exposure. A business assessing this finding needs to distinguish tools that return page content alone from those that expose response headers, including settings or command options that change that behaviour. A product name without its configuration is an incomplete description of the risk.

The hiring-screen example also broadens what counts as an unwanted outcome. A malicious instruction need not request data theft or an obviously destructive action. If accepted as evidence, an unsupported confidence score could distort a decision while leaving the agent apparently engaged in its assigned task. The source does not show that happening; it shows the attempted route.

Andrews' recommendation to check actions outside the model has particular relevance as businesses move from assistants that draft to agents that execute. It puts enforcement in the surrounding system rather than relying entirely on the model's interpretation. That is a concrete part of the business-readiness gap in agentic AI, rather than an abstract argument about model intelligence.

Evidence of wider exploitation would require more than finding additional hostile headers. It would need to connect a header to an agent receiving it, changing its behaviour and producing a consequential result. For now, the reported evidence stops at attempted instructions and identifiable exposure conditions. Buyers should preserve that distinction when weighing security claims.