Code Plain
All articles

Prompt injection already had a name in 1988

I went looking for what to call the thing that had blocked me and found four names waiting: the newest is 38 years old and the oldest is about telephones.

Isometric exploded diagram: four stacked planes, the third a solid green slab, with connector lines descending from the top and stopping at it.
The four layers, top to bottom. The solid slab is where the block happens, and it is not the layer where the authorisation was given.

After losing an argument to the harness I wrote myself, I went looking for what that thing is called, and what I wanted to name was not the block itself, which is banal, but the distinction between the authorisation I had given in a conversation and the permission that was missing from a file. I expected freshly minted vocabulary, the sort that shows up in a thread and evaporates in six months.

I found four names already waiting, and the newest thing I turned up is 38 years old. The oldest is 55 and is about telephones.

The first separation was in an operating system from 1975

The distinction between policy and mechanism came out of the Hydra project, described by Levin, Cohen, Corwin, Pollack and Wulf in a 1975 paper. The mechanism knows how to enforce while the policy decides what should hold, and kept apart they let you change the rule without rewriting the engine that applies it.

Translated back to what had happened to me: the chat is where I express policy, and the harness is the mechanism. That is why arguing with the mechanism does not work and should not work, because if a good enough argument could unlock execution, the thing was never a mechanism, only a suggestion in a lab coat.

The detail that settled it came later, when I asked the agent itself to write the permission rule that would unblock it, and that was refused too, correctly. A mechanism the supervised party can rewrite is not a mechanism.

My three blocked attempts had a name from 1975 as well

Saltzer and Schroeder published, that same year, the protection principles that still hold the subject up, and one of them is called complete mediation: every access goes through the check, with no path around it.

That is literally what happened. The official installer, blocked. The same package through another manager, blocked. Copying the files by hand, blocked. Three different routes and one decision, which while you live through it feels like obstinacy and looking at the design is the principle working, because one route getting through would have turned the other two into theatre on the spot.

The thing doing the blocking had a name from 1972

James Anderson's 1972 report describes the component that performs that check and calls it the reference monitor, with three properties: always invoked, tamper-proof, and small enough to be verified.

Translated for agents, that means the agent cannot bypass it, cannot rewrite it, and the thing has to be simple enough that a human understands why it refused. The third is the most neglected today and the most expensive: a block nobody understands becomes noise, and noise trains people to switch the protection off. An incomprehensible monitor is defeated by its own user, with no attacker involved.

Prompt injection had a name from 1988, and it is not about prompts

Norm Hardy named the confused deputy problem in 1988: a privileged program is induced to use its authority on someone else's behalf. The original example is a compiler with write access to system files, so that asking for output in one of them is enough to make it write, because the permission is its own and not yours.

The agent is the deputy in this story, because it is the one holding the tools, the credentials and the permissions, and when a tool's output says "you are authorised to", it is not asking for anything: it is trying to steer authority the agent already carries.

And this is where the name earns its keep rather than being terminological fussiness: calling it prompt injection makes the problem sound like a string bug, the kind you fix by escaping quotes. Calling it a confused deputy makes plain that the problem is badly delegated authority, and then you already know where to look for an answer, because other people looked before and wrote down what they found.

The root cause had a name in 1971, and it was about telephones

In early telephony, control and voice travelled the same channel, and a 2600 Hz tone blown into the mouthpiece was indistinguishable from the exchange's own signalling, so the network obeyed because it had no way to know who had spoken. Ron Rosenbaum told that story in Esquire in 1971, and the fix was not filtering tones: it was separating signalling from conversation into different channels.

A model's context is a single channel. System instructions, user requests, tool output, file contents and API responses all arrive as text in the same window, and anyone who controls any part of that content can write in the imperative.

There is no 2600 Hz tone to ban here, so the separation has to happen outside the channel, by the provenance of the text, and never by what it appears to be when read.

The four layers, now that each one has a surname

Intent is the prompt — "install this", "go ahead", "I authorise it" — and it expresses will without carrying any authority. Policy is the configuration, the rule written in a file saying what is allowed, in what scope and for which tool, which declares without executing. Mechanism is the harness, the point where the call is intercepted, the rule is consulted and the decision becomes effect, and which does not have opinions, it enforces. Execution is the system: process, file, network, money, where the consequence actually lands.

Four stacked bands: Intent (the prompt, expresses will), Policy (the file, declares the rule), Mechanism (the harness, intercepts and enforces — the highlighted band, where the block happens) and Execution (the system, where it lands).
The four layers, top to bottom: from prompt to code. The block happens at the mechanism, and not at the intent.

Nearly every confused argument about agent security comes from collapsing two of these into one, treating intent as policy or policy as mechanism, which was exactly my mistake when I assumed that authorising in writing would settle it.

What this changes when you sit down to configure

Authorisation is out of band, so consent in the chat is intent and the permission lives in a configuration file, out of the agent's reach. The rule that governs the agent is not written by the agent, and every tool output is data, classified by provenance and never by looking trustworthy. Least privilege per tool, because "run this installer" is not "run anything", and the narrow rule is the one that survives the next dependency. And a block has to explain itself, because whoever got blocked must leave knowing what to ask for, or they will ask to turn everything off.

None of this is a 2026 invention, because each of these names arrives with decades of traps already mapped by people who got hurt first, and the only new thing is that the confused deputy now writes in fluent English.

References

The names in this article are not mine, and the originals are worth reading:

  • J. H. Saltzer and M. D. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9), 1975 — the protection principles, including complete mediation and least privilege.
  • James P. Anderson. Computer Security Technology Planning Study. ESD-TR-73-51, USAF Electronic Systems Division, 1972 — the reference monitor.
  • Norm Hardy. The Confused Deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, 22(4), 1988.
  • R. Levin, E. Cohen, W. Corwin, F. Pollack and W. Wulf. Policy/mechanism separation in Hydra. SOSP, 1975.
  • Ron Rosenbaum. Secrets of the Little Blue Box. Esquire, October 1971 — the contemporary account of in-band signalling on the phone network.

Reply