All text your agent reads can give it orders. For example, the input and the context of the web page it was asked to summarize both reach the model at the same time. The model can't reliably tell whether bad instructions were injected from the provided context. Similarly, the long-distance phone network had the same flaw for decades.
The network carried its routing commands as tones inside the same voice path that carried the conversation. Engineers called it in-band signaling. While a trunk, the long-distance line between switching offices, sat idle, a single 2600 Hz tone marked it free, and the moment that tone stopped, the network read the line as seized. Pairs of tones then spelled out the number to route the call. None of it was secret.
Bell printed the full tone table in its own technical journal, so the blueprint for speaking to the network was public. Joe Engressia, blind and blessed with perfect pitch, found he could whistle the right note into a handset and seize the trunk on the far side of his own call. A whistle from a box of Cap'n Crunch cereal came close enough to 2600 Hz to do the same, and gave John Draper the handle he carried ever after. The blue box turned the whistle into a pocket device that faked the idle tone and dialed a free call anywhere.
I review enough agent designs now to hear that whistle in the room. I hunt for the merge point, the place where the instructions I trust and the text I do not are poured into one stream and handed to the model as a single input. Find the merge point and you have found the modern blue box. The model has the architecture the phone network had. One channel, carrying command and content together.
Prompt Injection Is an In-Band Signaling Attack
Prompt injection is the name for that whistle. It is a security flaw where malicious instructions hidden in the content an agent reads slip past the safety rules meant to stop them and change what the agent does. The instruction comes through the front door, on the same channel as everything legitimate, because the model has only one channel.
Everything a model reads while it works arrives as one stream of text. Your system instructions, the user's question, a retrieved document, a returned tool result, the web page you asked the agent to summarize, all of it lands in the same context window as undifferentiated text. The stream carries no reliable marker of origin. By the time text reaches the model, the trusted and the untrusted have already merged, and the seams you drew in the architecture are invisible in the input the model reads. The model was built to follow instructions. So when instructions turn up inside the document too, it follows those.
Researchers split the attack into two shapes. Direct injection is the one people picture first, a user typing a hostile instruction straight into the chat, something like "ignore your previous instructions and do this instead." Indirect injection is the more dangerous shape, because the hostile instruction rides in on content the agent was only asked to process. It might be a sentence planted in an email the agent triages, a comment tucked into a code file, or a line of pale text on a page the agent scrapes. The user never sees it. The agent reads it as part of the job and follows it. Indirect injection is the shape that survives a realistic retrieval pipeline, because outside content reaches the model with no human in the loop to catch it.
The Open Worldwide Application Security Project (OWASP) ranks goal hijack, an agent's objective redirected by injected instructions, at the top of its 2026 Top 10 for Agentic Applications. In a chat product, a successful injection changes an answer. In an agent holding tools and permissions, it changes what the system does next.
Context is the attack surface because it is one channel. Everything else in this chapter is a face of that fact.
The Context Is Not One Thing
Say "the prompt" and you picture a single block of text. The context an agent actually reads is six different things. The context-engineering guides I've read sort the window by the type of content, which is the right cut for making an agent smarter. For security, I go back to the rule I used to draw the three-layer stack in Chapter 1. Ask who can write each part and when that content arrives, and the window splits into six surfaces.
- System instructions are the role, the rules, and the worked examples you write before the agent ships.
- Tool descriptions tell the agent what each tool, skill, and connected server can do, in words written by whoever built the tool.
- Requests carry the job in, whether that's a user's message, the payload that fired a trigger, or a task an upstream agent handed down.
- Documents are the outside text the agent reads to do the job, the web pages it browses, the passages it retrieves, the emails it triages, and the files a user attaches.
- Tool results are whatever a call returns, including the answer a subagent sends back.
- Memory is the conversation so far, the agent's own notes and reasoning, and whatever it saved from earlier sessions and reads back in. The agent writes this one itself, out of everything above.
You write the first surface, and the second only if you built every tool the agent calls. Users, outside authors, whoever controls the data a tool touches, and the agent itself write the last four, and an attacker can reach every one of them. Two surfaces are supposed to direct the agent, your instructions and the request that hands it a job. The rest are only supposed to inform it. The model can't reliably tell the difference.
Three of these surfaces turn injection from theory into standing risk.
Memory turns a one-time injection into a standing one, and it has two depths. Short-term memory is the chat history and the session state, where an instruction keeps acting long after the message that carried it scrolled out of view. Long-term memory is what the agent keeps across sessions, the facts, experiences, and procedures it judged worth saving, and a hostile instruction promoted there steers conversations that have not happened yet. The payload outlives the moment that delivered it.
Tool results are trusted by default, and they should not be. When an agent calls a tool, the orchestration layer running the agent takes whatever comes back and appends it to the context as ordinary text. A compromised tool, or an honest tool returning attacker-controlled data, hands the model instructions wearing the costume of a result.
Documents are a poisoning target. Retrieval-augmented generation (RAG) is the common pattern where an agent looks material up before answering, pulling relevant documents from a store and dropping them into the context. Poison a document that lands in that store and the payload rides retrieval into the model as trusted knowledge. The research literature tracks a growing family of these attacks under names like PoisonedRAG.
Tool descriptions could join those three. A poisoned description ships with the tool itself, so Chapter 10 takes it up with the rest of the tool supply chain.
The academic framing that fits these surfaces best comes from Huihao Jing and colleagues, whose 2026 survey organizes agent attacks by the boundary where isolation first breaks rather than by attack type. Two of their boundaries are pure context, one for requests and one for documents. The user-agent boundary, in their words, "asks whether an agent can keep user content from becoming privileged control," and its catalog includes an attack the single-message picture misses. The attacker spreads hostile instructions across several turns, so no one message looks like an attack and the steering shows up only in the accumulated conversation.
The system-environment boundary covers everything the outside world sends in, the hostile webpage, the poisoned document, the manipulated interface element, content the agent was merely asked to observe. Their standard is that retrieved passages, documents, and memory artifacts "should remain observations rather than hidden commands."
The Four Faces of the Context Threat
One channel gives the threat four faces, and naming them is how the rest of this book will point at them.
Injection is the entry face, the one the first two sections built. Hostile instructions arrive through any surface someone else can write, and the model obeys them because it cannot tell them from the instructions it was supposed to obey. Every other face depends on this one being possible.
Pollution is the crowding attack. In Book 1 I defined context pollution as a quality problem, low-value information filling the window and crowding out the high-value instructions that matter (Book 1, Chapter 2). I lived that version on an early project of my own, where the rules file grew into a small book of just-in-case instructions until the signal drowned. That was craft failing. The security version is an adversary doing it on purpose, flooding the context until the safety-relevant instructions are drowned out, cut off, or summarized away. Same mechanism, hostile hand.
Exfiltration is the leak. The agent can reach something sensitive, a customer record, a stored secret, an internal file, and an attacker gets it to hand that data back out through its own output. Simon Willison, who coined the term prompt injection, named the shape of this precisely. He calls it the lethal trifecta: "Access to your private data," "Exposure to untrusted content," and "The ability to externally communicate." An agent holding all three can be told by the untrusted content to take the private data and route it somewhere the attacker is waiting. Any one of the three alone is survivable. The three together are the leak engine.
Drift, context drift in full, is the temporal face, and it is this book's contribution to the list. The other three are things done to the context. Drift is the context moving on its own. The window an agent holds at deployment is not the window it holds an hour into execution, because every new request, document, tool result, and memory entry lands in it, and none of that content existed when your security review signed off. This is the runtime face of the moving perimeter from Chapter 1, the boundary that redraws itself while the system runs.
It is not data drift, the model-level problem of production data diverging from training data. It is not context pollution, the quality problem above. Drift is a security claim. The perimeter you audited no longer exists, because the agent rebuilt it from the inside.
Jing and colleagues document the attacks that exploit this, injections that persist in context and memory across interactions, without naming the temporal frame. Their catalog is the evidence. The moving perimeter is the lens. Detecting that movement while it happens is observability work, and it waits for Chapter 13, which builds the discipline of seeing what an agent is doing, and Chapter 12, which judges what it does next.
Which Agents Run Hottest on Which Threat
Chapter 2 sorted agents into five architecture types, automation, orchestration, coding, research, and interactive, and added an axis for lifetime, whether the agent is permanent and holds state across sessions or ephemeral and vanishes after one task. The context runs hottest on a different surface for each.
Research and retrieval agents live closest to the fire. They read untrusted outside sources for a living, which puts RAG poisoning and indirect injection at the top of their threat list. The document is the job, and the document is the weapon.
Interactive agents put a human on the channel, so requests run hottest. Direct injection, social engineering, and the leak of personal data dominate, because the attacker is talking to the agent in real time and the agent is talking back.
Coding agents read the repository for a living, and everything in it is input. Repository content, the comments inside the code, and the documentation of the packages they pull in can each carry a planted instruction, and in most coding agents all of it comes back as tool results, one read call at a time. Of the six surfaces, tool results are the one I see mishandled most often in the agent designs I review. Teams screen the document they retrieved and append the tool result untouched, because the tool is theirs and theirs feels safe. No agent type leans on that default harder than a coding agent, whose whole working loop is tool output.
Permanent agents run hottest on memory. Long-lived state is durable injection, a planted instruction that outlives the session that carried it and keeps acting across the ones that follow. Ephemeral agents invert the exposure. A worker that vanishes after one task offers almost nothing lasting to poison, which concentrates the fight on the request it spawns with and whatever it reads before it dies.
Orchestration agents spread contamination. One agent's poisoned context becomes another's trusted input when work hops between them, so a single injection can travel the whole delegation tree. The task goes down as a request and the answer comes back as a tool result. Jing and colleagues compress the pattern into five words. "Serious failures often cross boundaries." Their survey traces one recurring path, a poisoned document entering through retrieval and surfacing downstream in tool calls and in the messages agents pass each other, each handoff carrying the payload further from the place a reviewer would think to look.
Automation agents have the narrowest exposure, the one request that fires them. Narrow is not the same as safe when that request starts a task wired into something that matters.
The lesson is the one Chapter 2 made about controls in general, now aimed at context. A generic context defense, applied evenly, over-protects the surfaces that were never hot and under-protects the one that was. Type determines which face of the context threat you are fighting.
Why Injection Resists Deterministic Prevention
OWASP keeps a companion list of risks for applications built on large language models (LLMs), and prompt injection sits at number one there too. Its 2025 entry carries a concession. "Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection."
Stochastic is the load-bearing word. A model turns every input into probabilities, so no filter can test every phrasing a patient attacker might try. That concession is an architectural fact, not defeatism. Willison has argued for years that the attack targets the model's instruction-following itself, and following instructions is the entire job of the model. You cannot pattern-match your way out of an attack that is indistinguishable from the intended use, because the malicious instruction and the legitimate one are the same kind of thing arriving on the same channel.
Bell did not stop phone phreaking by teaching the network to recognize bad whistlers, a losing game against anyone patient enough to sound legitimate. It rebuilt the architecture instead. Common Channel Interoffice Signaling (CCIS), deployed from 1976, moved every control signal onto separate data links running switch to switch, a channel no customer telephone could reach. On every trunk CCIS converted, a perfect 2600 Hz tone in the voice path commanded nothing, because the equipment it once commanded had stopped listening on that wire. Separation, not detection.
I sort every mitigation I meet with one question. Does control travel on a channel the attacker can also write to? Call it the 2600 Hz test. Input filters and jailbreak classifiers, the tools that scan for the bad whistle, are the detection branch of the family tree. They earn a place as depth, one defensive layer among the several you stack. They are never sufficient alone, because they are trying to win the game Bell walked away from.
The temptation now is to overcorrect, to throw out the filters and let an AI judge do the whole job. Deterministic scanners, the checks that evaluate the same way every time, are the floor, and they stay the floor. AI reasoning, judgment applied to an input against intent and policy, is a new column beside them, never a replacement for them, and never the hard boundary on its own. It pairs with a deterministic gate. A bigger rule set will not save you, because rules get reviewed once while the surface they guard changes continuously. The answer to an attack that resists prevention is a posture, which Chapter 8 builds, and a runtime judgment tier, which Chapter 12 builds.
What You Can Do at the Context Layer
None of this leaves a developer helpless while the posture chapters are still ahead. There is real work at the context layer today, as long as you keep the honest limit in view. The measures that follow reduce exposure. They do not close the hole.
Separate the channels wherever the platform allows it. Keep privileged instructions out of the data path, so the system prompt and the untrusted document are not concatenated into one undifferentiated stream. This is the separation move from the phone network, scaled down to a context window, and it is the branch of the family tree that holds. CaMeL, a 2025 research design from Edoardo Debenedetti and colleagues, shows what the full version looks like. It pulls the plan out of the trusted request before the agent reads anything else, so that "the untrusted data retrieved by the LLM can never impact the program flow."
The limit is the platform itself, because most model interfaces still merge everything into one input at the last step. The orchestration framework you build on may do its own merging somewhere you never look, so separation built upstream narrows the merge point without deleting it. When you evaluate a platform or a vendor, ask one question. Do system instructions travel in a separate field, or are they concatenated with retrieved content before the model reads them?
Enforce an instruction hierarchy instead of assuming one. System instructions should outrank user input, and user input should outrank the text that comes back from tools and documents. Assume that ordering silently and an attacker will invert it, so declare it in the role structure most model interfaces already expose. Every message arrives labeled system, user, or tool, but the labels do little unless the model has been trained to rank them. OpenAI's researchers named that ranking the instruction hierarchy in 2024 and trained a model to follow it. Put the privileged instructions in the system role, and keep retrieved text labeled as tool output or document content instead of pasting everything into one user message. The honest limit is that hierarchy lives in trained behavior rather than in hardware, and trained behavior is exactly what injection attacks, so a declared hierarchy raises the attacker's cost without zeroing it.
Treat documents, tool results, and memory as observations, not commands. That is the Jing standard from earlier in the chapter, turned into a design rule and stretched to cover tool results too. It is the most useful one here. Data that came from outside is data, and it is not allowed to give orders.
Break one leg of the lethal trifecta. Willison's own advice for the leak engine is to remove one of its three legs, and the leg you control most directly is the exit. Deny external communication for any agent that combines private-data access with untrusted input, or allowlist the few destinations it genuinely needs. Outbound control is old network discipline, deployable today, without waiting for any platform to mature. The limit is scope. Removing the exit stops the leak, not the injection that drives it, so the other faces still need their own answers.
Put guardrails on both ends, and assume they fail. Steve Wilson, who founded OWASP's Top 10 for LLM Applications, states the position well. "I tell people: put in guardrails on the input, but assume they're going to fail sometimes. This means you need another set of guardrails on the output." Assume-failure is the design posture of this whole book, and it is why a single filter is never the plan.
Add provenance and freshness checks to what you retrieve, and segment sensitive memory so one poisoned entry cannot reach everything. Provenance asks whether you can prove where a document came from, and freshness asks whether it is still the version you think it is. That work has a whole posture domain waiting for it in Chapter 9, which builds the defensive discipline for agent data and context.
The tooling is filling in around these ideas. Open-source projects like NVIDIA's NeMo Guardrails and Guardrails AI offer input and output validation you can wire in rather than build. Use them the way Bell's engineers used every trick they had before separation arrived. They are useful depth, never the fix. The fix is architecture.
Why This Matters Now
Context is the widest attack surface an agentic system has, because it is the one channel everything the model reads travels on. Injection, pollution, exfiltration, and drift are not four separate problems. They are four faces of one structural fact. Command and content arrive together, and the model cannot tell them apart by reading harder. No input filter closes that gap, because the gap is how the model works.
The response runs across three later chapters. Chapter 8 builds Agent Input Posture, the continuous discipline for governing everything that can influence the agent. Chapter 9 builds Agent Data & Context Posture, the defensive domain for memory and retrieval. Chapter 12 builds Agent Runtime Posture, where a two-tier gate applies the runtime judgment a deterministic check cannot. This chapter names the surface. Those three defend it.
Every agent platform is walking the arc Bell walked. Control and data share one channel. The system obeys anyone who can speak it. Detecting bad speakers turns out to be a game you lose to the patient attacker, and the durable answer was never a better filter. It was separation. Fifty years ago that meant moving a 2600 Hz tone off the line a customer could reach. Today it means keeping the instruction path out of the stream the untrusted document rides in on. The whistle still works. We are still deciding whether to move the signaling.
Chapter 4, Map the Estate, widens the lens from one agent to the whole organization. The surface this chapter named is running on agents nobody has inventoried yet, and you cannot defend a surface you have not found.