Information Flow Control
Day 23 gave you the dual LLM pattern, two models with a boundary so a compromised reader has no privileged hands. Today we name the principle that pattern is just one instance of. Information flow control is the general rule that governs good agent architecture: track where every piece of data came from, and forbid data from an untrusted origin from ever reaching a privileged action. The dual LLM pattern is one way to enforce it. Information flow control is the law it enforces.
If you only remember one defensive idea from this whole series, make it this one, because every working defense is a special case of it. Scoping, dual LLM, egress allowlisting, sandboxing, all of them are the same move: keep untrusted influence away from privileged capability. Information flow control is that move stated precisely enough to design around.
The idea, borrowed from an old discipline
This is not new. Information flow control is a decades old concept in security, from systems that had to keep classified data from leaking to unclassified outputs. The core idea: every piece of data carries a label describing its trust level or its origin, and the system enforces rules about where labeled data is allowed to flow. Secret data cannot flow to a public output. Untrusted input cannot flow to a trusted decision.
Agents need exactly this, because the whole prompt injection problem is an information flow problem. Untrusted content, a ticket, a page, an issue, flows into the agent’s reasoning and then out to a privileged action. The bug is a forbidden flow: data from an untrusted source reached a capability it should never have been allowed to drive. Name it that way and the defense becomes obvious. Block the flow.
Taint: the practical version
The engineering form of this is taint tracking. The concept is simple and you already know it from classic appsec, where tainted user input must be sanitized before it reaches a dangerous sink like a SQL query.
Apply the same lens to agents:
Everything has a taint label. Content is either trusted or tainted, by where it came from. The user’s direct instruction is trusted. A ticket body, a fetched page, a retrieved document, a tool result, a memory loaded from an untrusted write, all tainted.
Taint propagates. Anything derived from tainted data is itself tainted. If the agent summarizes a tainted ticket, the summary is tainted. If it extracts a value from a tainted page, that value is tainted. The label follows the data through every transformation. This is the part people miss: laundering tainted content through a summary does not clean it.
Privileged actions reject tainted input. A tool that can cause harm, send email, read another customer, issue a refund, push code, must refuse to be driven by tainted data. Its arguments, the ones that decide what it does, have to come from trusted sources, not from tainted content.
That third rule is the whole defense. A privileged action may only be controlled by trusted data. Tainted data can inform, can be summarized, can be shown to a human, but it can never be the thing that decides what a privileged tool does.
Why this is the parent of every defense
Watch the other defenses fall out of this one principle.
Dual LLM, Day 23, is information flow control by architecture. The quarantined model is where tainted data is allowed to go. The privileged model is where only trusted data may flow. The boundary between them is the flow control rule, physically enforced by separation. The typed channel exists precisely so tainted data cannot carry a command across to the trusted side.
Capability scoping, Day 11 and Day 25, is information flow control on the target side. Binding a tool’s reach to the ticket owner means the tainted ticket content cannot expand what the tool touches. The flow from tainted input to privileged reach is cut.
Egress allowlisting, Day 21, is information flow control on the exit. Restricting where data can go means tainted influence cannot redirect the outbound channel. The destination is trusted data, not tainted.
Sandboxing, Day 17, is information flow control on the environment. The agent’s actions flow into a contained space where tainted influence reaches nothing real.
Every one of them is the same sentence: do not let untrusted origin data reach a privileged action. That is why information flow control is the principle and the rest are techniques. Once you see it, you stop memorizing defenses and start deriving them.
Designing an agent with flow control in mind
The practical design method, which you apply before building, not after breaking.
Label every data source. Go through every input the agent can receive and mark it trusted or tainted. The user’s instruction, trusted. Everything the agent reads from the world or from storage, tainted, including memory and retrieval, the Day 20 lesson.
Identify every privileged action. Every tool or capability that can cause harm or reach something valuable. These are your sinks.
Trace the flows. For each privileged action, ask: can tainted data reach the arguments that decide what this action does. If yes, you have a forbidden flow, which is a vulnerability, found at design time before anyone exploited it.
Cut the forbidden flows. For each one, either bind the privileged argument to a trusted source instead, or route the tainted data through a quarantine that strips its ability to control the action, dual LLM, or constrain the action so tainted input cannot expand it, scoping.
This is threat modeling for agents, and it is far more reliable than testing, because it finds the forbidden flow in the design rather than hoping a payload reveals it.
The honest difficulty
Flow control is the right principle, and it is genuinely hard to enforce perfectly, for one reason: the agent’s usefulness often depends on tainted data influencing decisions. You want the agent to act on the ticket. The ticket is tainted. A purist no tainted data ever influences any action rule would make the agent useless.
So real flow control is about the degree and shape of influence, not total prohibition. The workable rule: tainted data may influence a decision within tightly constrained bounds, a choice among a fixed set, a value within a validated range, but may never have arbitrary control over a privileged action. The ticket can make the agent pick from three allowed responses. It cannot make the agent compose an arbitrary command. This is the typed channel from Day 23, stated as a flow rule.
That is the real art: allowing tainted data enough influence to be useful while denying it enough to be dangerous. Every design decision in agent security is somewhere on that line.
Reproduce the thinking in your lab
This one is a design exercise more than a code exercise, which is the point.
- Take your lab agent and label every input trusted or tainted. Be honest, memory and tool output are tainted.
- List every privileged tool as a sink.
- For each sink, trace whether tainted data can reach its deciding arguments. Write down every forbidden flow you find. These are your vulnerabilities, identified without a single payload.
- For each forbidden flow, apply one cut: bind to trusted source, quarantine, or scope. Reuse your Day 11, 21, 23 work.
- Re run a week three
