A system maintains a data channel (content to process) separate from a control channel (directives that govern processing); an interpreter downstream can be triggered by cues in its input to read data as control. When untrusted content crosses into the data channel un-inertised, the interpreter — following its own rules exactly — executes it as control, wielding the defender's authority on the attacker's behalf. The fault is at the boundary, never in the interpreter.
How would you explain it like I'm…
The Tricked Robot
Imagine a robot that does whatever is written on the notes you feed it. You're supposed to feed it plain story notes, but a sneaky person writes 'open the safe' inside their story. The robot can't tell the difference, so it opens the safe — not because it broke a rule, but because it followed its rules on the wrong kind of note.
Command Hidden In Content
A data-control plane breach happens when a system mixes up two kinds of input: plain content it's supposed to just handle, and commands that tell it what to do. Somewhere downstream there's an interpreter — a part that reads input and treats certain patterns as instructions. If untrusted content sneaks into the content channel without being 'defused,' the interpreter reads it and obeys it as a command. The system isn't malfunctioning; it's following its own rules correctly, just on input it should have treated as harmless. The attacker ends up borrowing the system's own power and trust. To stop it, you either keep the two channels truly separate, defuse incoming content so it can't act like a command, or make sure commands can't do much damage.
Data Posing As Control
A data-control plane breach is a structural vulnerability, not a malfunction. A system keeps a data channel (content to be processed, stored, or transported) separate from a control channel (directives about what to do, in what order, with what authority). Downstream sits an interpreter that reads its inputs and treats certain tokens or structural cues as control. The breach occurs when untrusted content crosses into the data channel without being 'inertised' — and the interpreter, obeying its own rules perfectly, executes the attacker-supplied content as control, wielding the defender's authority on the attacker's behalf. The interpreter is 'fooled' only relative to the designer's expectation; its own rules were never broken. This is why the same flaw appears everywhere from SQL injection to prompt injection: any substrate where the data-control separation rests on convention rather than a real mechanism inherits it. The fixes are structural — separate the channels at the mechanism level, inertise at the crossing point, or reduce the interpreter's authority.
A Data-Control Plane Breach is the structural pattern in which a system maintains a separation between a data channel (content being processed, transported, or stored) and a control channel (directives that govern processing — what to do, in what order, with what authority); an interpreter downstream of the data channel reads its inputs and treats certain tokens or structural cues as control; and untrusted content crosses into the data channel without being inertised — at which point the interpreter, operating correctly relative to its own rules, executes the attacker-supplied content as control. The defender's authority and trust are wielded on the attacker's behalf, and the interpreter is 'fooled' only relative to the designer's expectation; its own rules were never violated. The breach is structural, not malice-dependent: any substrate with an interpreter that reads inputs and treats certain patterns as instructions inherits the vulnerability whenever the data-control separation is maintained by convention or implicit assumption rather than by a structural mechanism. The structural commitments are: at least two logical channels (data and control); a downstream interpreter that can be triggered to switch its interpretation of its input from data-mode to control-mode by patterns in the input itself; a boundary at which data-channel content reaches the interpreter; and a crossing point at which untrusted content can enter the data channel without being inertised. The prediction is invariant — any such configuration is exploitable regardless of the attacker's tools or the defender's implementation — and so is the solution: separate the channels at the mechanism level, inertise at the crossing point, or reduce the interpreter's authority. The substrate-independence is proved by the biological case: viral integration involves no malicious principal on the data side and no cell 'trying' to maintain a boundary, yet the structural vulnerability is present and exploited.
Software security: SQL injection, XSS, command and format-string injection — user content reaches a parser that treats it as code.
Language models: prompt injection, where retrieved content crosses into the model's instruction channel.
Molecular biology: viral integration and horizontal gene transfer — foreign DNA the host's machinery reads and executes, with no strategic principal on the data side.
Social engineering: a pretext story crosses into the victim's instruction-following channel via trust shortcuts.
Law and bureaucracy: a descriptive memo read as a directive because recitals are not distinguished from operative provisions.
Animal behaviour: brood parasitism and pheromone mimicry, where a parasite's signal is read as a directive by the host's recognition apparatus.
It names what unifies injection, social engineering, viral infection, and brood parasitism: the interpreter is correct, and the failure lives at the un-inertised crossing point, not in the interpreter's intelligence.
It compresses escaping, sandboxing, immune recognition, and signature verification into one boundary-and-authority problem with four remedies: separate channels, inertise at the crossing, mark-don't-trust, and reduce authority.
It trains the reasoner to ask, of any system, whether an interpreter's input can switch from data-mode to control-mode and whether untrusted content can reach it un-inertised — and if so, to harden the boundary, never the interpreter.
Security ↔ biology: a SQL-injection defender recognises the same pattern in immune evasion; both attack the recognition machinery at the data-control boundary.
Software → institutions: the "demote content to data-by-default, require explicit elevation" discipline ports from parameterised queries to document intake and clerical authority.
In classic SQL injection, a form field (data channel) is concatenated into a query string; input ' OR '1'='1 makes the parser (interpreter) read a tautology as grammar (control) and run it with the application's database authority. The durable fix is a parameterised query — channel separation — never "make the parser smarter."
Parents (2) — more general patterns this builds on
Data-Control Plane Breachis a kind ofUntrusted Input Execution — child of emergent untrusted_input_execution
Data-Control Plane Breachpresupposes, typicalInterface — A failure mode at the contracted meeting point where content arriving through an interface is re-interpreted from data into control; presupposes an interface (the stage on which the breach occurs). Tentative — largely foundational/structural.
Data-Control Plane Breach is not Escape and Leakage because the breach is the entry dual — untrusted content entering and executed as control — whereas leakage is the exit dual, confined material getting out.
Data-Control Plane Breach is not Controlled Reentry because controlled reentry is governed, authorised re-admission across a boundary, whereas the breach is un-authorised, un-inertised crossing the interpreter executes as control.
Data-Control Plane Breach is not Interface because an interface is the contracted meeting point, whereas the breach is the failure mode in which content arriving through that interface is reinterpreted from data into control.