Prompt injection is a 2600 Hz whistle

In the 1960s a 2600 Hz tone could take over a long-distance phone line, because the control signals travelled on the same wire as voices. The phone company didn’t fix it with a better tone detector. It moved control to a separate wire. Prompt injection is the same bug, and because a model has to read its input, the separate wire has to go around the model.

Prompt injection is text inside a model’s data that the model obeys as an instruction. Say an agent, a language model that can call tools, summarises your inbox. One email says to forward your mail to a stranger, and the agent does it. The phone network, the SQL database and the browser each had this bug first. (note note 1) 1. Bruce Schneier made the phone comparison briefly in 2024. The database and browser parallels are mine. Try both kinds of fix in all 4 places.

The phone switch obeyed a sound

A switch is the machine that routes calls. A 2600 Hz tone told it the line was idle. When the tone stopped, the switch waited for routing digits. Anyone who could make that tone could make free calls. A few people could whistle it. Others built small “blue boxes” that played it.

The first fix was detection. A guard circuit judged whether the sound was a pure tone. It could judge the sound, but not who made it. The fix that held was common channel interoffice signalling (CCIS), which moved control onto a separate data link from 1976. A blue box could still play a perfect tone, but nothing listened for it. Bell’s engineers wrote in 1978 that “fraudulent manipulation of the telephone network is eliminated in an all CCIS environment.”

The database obeyed text inside a query

In 1998 the hacker magazine Phrack showed a web page that pasted form input into a SQL query. The page would run any SQL the input carried. Phrack’s first advice was to escape quotes, which means marking each quote mark in the input so the database reads it as plain text. But a number field needs no quotes, and it got straight past that. The fix that held was parameters:

# unsafe: the input becomes SQL
q = "SELECT * FROM users WHERE id="
db.execute(q + uid)

# safe: the input goes as a value
q = "SELECT * FROM users WHERE id=?"
db.execute(q, (uid,))

A parameter travels to the database beside the query, so the parser never reads it as code.

The browser obeyed other sites

A form on any website could post to your bank, and the browser attached your bank cookie. This is cross-site request forgery (CSRF). The browser was a confused deputy, a program tricked into using its own powers for someone else. The fix that held stopped asking whether a request looked malicious. It asks which site started it. Since Chrome 80 in 2020, cookies are SameSite by default, so a request from another site arrives without them.

A model has to read the data

Simon Willison named prompt injection in 2022, after SQL injection. In the same post he asked for separate inputs for instructions and data, like parameters for prompts. I don’t think we can have them. The switch and the parser didn’t need the content to do their jobs. A model that can’t read the email can’t summarise it, and once it reads the email, the email can steer it.

Most defences so far are detection. Spotlighting marks untrusted text so the model can tell it apart. StruQ and Meta SecAlign train the model to ignore instructions found in data. A detector is a separate filter model that scores text before the main model reads it. In 2025 the paper “The Attacker Moves Second” tested 12 published defences against fixed attacks, then against attacks tuned to each defence. Guess how 4 of them did against the tuned attack.

Most of the 12 went above 90%. That gap is the guard circuit again. A trained detector compares how text sounds with how instructions usually sound. A 2026 paper, “Prompt Injection as Role Confusion”, found that models judge who is speaking from the style of the text, not its label. A better detector still outputs a probability, and the attacker gets another try. Even Anthropic’s defences for its browser agent left attack success at 11.2%, down from 23.6%.

Filters still help as alarms. A hit means someone is working on a payload. A miss means nothing, so a filter shouldn’t decide what the agent may do.

Put the control around the model

The UK’s National Cyber Security Centre (NCSC) calls the model an inherently confusable deputy. It advises fixed rules on what the system can do, and privileges no higher than those of whoever wrote the text. Both sit outside the model.

Google DeepMind’s CaMeL (2025) is one design for this. A privileged model plans the steps from the user’s request before any untrusted text is read. A quarantined model reads that text and can’t call tools. Every value carries a tag that says where it came from. So a rule can block send_email when the recipient came from someone else’s text. On AgentDojo, a benchmark of agent tasks under attack, CaMeL solved 77% of tasks with its guarantee in place, against 84% undefended. Those 7 points are a cheap price for the second wire.

You don’t need all of CaMeL to get one piece of it. In April I built an agent that sets up a new country’s site from a short specification. It shares one piece of this design, a gate outside the model. It shows a dry run, waits for a person to confirm, and its changes reach the code only as a pull request. In May it opened one for a new country’s site, and 2 of us reviewed it before it merged.

That gate only works if people read what they approve. The CaMeL authors warn that people get tired of approving. If I could track one number for an agent like this, it would be how often someone approves without reading.