Safety is not a property of models. It emerges from interaction.
Most organizations are securing agents as if the opposite were true. They benchmark model safety, pick the vendor with the strongest alignment story (the training work labs do to shape a model toward safe default behavior), and file the security question as answered at procurement. I watch teams make that bet in most of the agent architectures I review. The selection matters. But the model is the one layer of the system you control least, and it cannot see the context that decides whether an action is safe.
The seed of this book's thesis comes from Matin Mavaddat, whose January 2026 essay "Safety Is Not a Property of Models" put the argument in its sharpest form. His test case is a single instruction an agent might receive, and what context does to it.
"Delete all transaction logs. In one context, this is a compliance requirement. In another, it is destruction of evidence. The behaviour is identical. The safety judgment is not."
Everything that decides between those two worlds, who asked, under which policy, with what data at stake, sits outside the model. The judgment depends on facts the weights (the numbers inside the model) never carry.
If safety lives in the interaction, then no single layer of an agentic system can guarantee it. Defense-in-depth, security engineering's old answer to problems shaped like this, puts controls at every layer of a system and designs each layer assuming the others might fail. This book applies that discipline to systems that read untrusted text and act on it.
When Anthropic disrupted what it described as the first reported AI-orchestrated cyber espionage campaign, the attackers had not trained a new model. They wired a commercial coding agent into an automated attack system, and by Anthropic's account that system executed up to 90% of the campaign's tactical steps. The risk did not ship with a model launch. It arrived with what someone built around a model that already existed. The offense has moved on to the interaction. Too much of the defense is still benchmarking models.
We Moved Security Once Already
Around the turn of the decade, I was the product manager for DevOps at a large financial services company. My team ran the enterprise's delivery machinery, the source code repositories and the continuous integration and delivery (CI/CD) pipelines, as an internal product serving 4,000 application developers. Then a corporate reorg arrived with an unusual instruction. The entire DevOps team would move into the Cybersecurity organization and take the mission global.
A reporting-line change would've been simple. This one changed what the team was for. Cyber DevSecOps would operate as a value center rather than a cost center or a compliance gate, and we asked to be judged on three outcomes: faster delivery, lower cost, and less exposure to vulnerabilities. We weren't bolting security onto an existing pipeline. We were changing what the pipeline's product was.
We started with Software Composition Analysis (SCA), which scans the open-source packages your code depends on for known vulnerabilities. SCA sees nothing in the code your own developers write, so Static Application Security Testing (SAST) joined the pipeline next to read our source for exploitable flaws. SAST can't catch a misconfigured server, so Infrastructure-as-Code (IaC) scanning followed, checking the configuration files that define infrastructure before anything deployed. Nobody handed us that sequence in a strategy deck. We added each control because the one before it had a blind spot. By the end of year one, the program had cut the average time a Critical-severity vulnerability sat exposed from 120 days to under 30.
I've watched security's home move before, and it moves when the platform moves. Back then, our platform-as-a-service model was giving way to Kubernetes, the container orchestration system that became the industry default, and the pipeline was becoming the spine of software delivery. So security moved into the pipeline, and my team moved with it. Today agents are becoming the delivery spine, and security is packing again. This book exists to make the second move deliberate.
That build-out retaught us what security engineering has known for decades. Firewalls never replaced input validation. Authentication never replaced authorization. No single control catches everything, so controls have to layer, and every layer has to assume the rest might fail. Agentic systems are not exempt from that law. They are about to stress it harder than anything the discipline has defended yet.
The Three Layers of the Agentic Stack
Defense-in-depth needs a map before it needs controls. For agentic systems I draw three layers, and the rest of this book treats them with deliberately unequal weight. Three is a claim, not an estimate. A layer earns its place on this map when its owner and its clock change together (who can alter the surface and when the alteration takes hold). Agentic systems have exactly three of those regimes. You shape what the model reads, request by request. The vendor shapes the weights, training run by training run. You shape the architecture that acts, design decision by design decision.
Finer maps exist, and they are not wrong. The Cloud Security Alliance's MAESTRO framework (Multi-Agent Environment, Security, Threat, Risk, and Outcome) threat-models agentic systems across seven layers, giving data operations, deployment infrastructure, and observability rows of their own. Those are enumeration maps, built to answer where things can go wrong, and Chapter 8 returns to them as complementary views. This map answers who must act and on what clock, because that is the question a defense budget hangs on.
The map also has a floor. Beneath all three layers sits the classical stack, the networks, the identity systems for humans and workloads, and the serving infrastructure that host everything above. Agents did not retire any of it, and this book assumes you are defending it already. The three layers cover what agents made new, and agent identity is part of that new surface. Who an agent is, whom it acts for, and what authority it inherited are questions the classical floor was never built to answer.
The Context Layer: What the Model Reads
The context layer is everything the model reads while the agent works. Your system instructions live here. So do the user's messages, the documents the agent retrieves, the pages it reads, and the results its tools return. You will hear this layer called "the prompt," but the prompt you wrote is one tenant among many. The model does not distinguish among those sources the way you would. It reads one stream.
That single fact produces the layer's signature threat. Prompt injection hides instructions inside content the agent was only supposed to read, a sentence buried in a support ticket, a comment planted in a code file, a line tucked into a scraped web page. Jailbreaking is the sibling threat, inputs crafted to talk the model out of its trained refusals. Both amount to social engineering aimed at the agent's working memory. The Open Worldwide Application Security Project (OWASP) puts agent goal hijack, injected instructions redirecting what the agent is trying to accomplish, at number one on its 2026 Top 10 for Agentic Applications.
The defenses here are real. Input validation rejects malformed or suspicious content before the model sees it. Guardrails, automated filters that sit between the world and the model, block known attack patterns before they reach the context. Rate limiting and anomaly detection catch the probing that precedes a serious attempt. Structured input formats shrink the space where an attacker can hide free-form instructions.
None of them can anticipate every attack, because injection is a creativity contest and the attacker needs only one phrasing your filters have never seen. Chapter 3 takes this attack surface apart in depth, and Chapter 10 builds the continuous posture response to it.
The Model Layer: What the Vendor Ships
The model layer is the trained artifact itself, the weights that turn input into output. Unless you are training your own foundation model, you do not control this layer. Anthropic, OpenAI, Google, and the open-weight labs (the ones shipping models you can download and run yourself) decide what data goes in, how the training gets tuned, and which behaviors get suppressed before release. Self-hosting moves the serving under your control, but the weights arrive already shaped by whoever trained them. Fine-tuning lets you adjust that shape, not replace it.
The threats here operate at training time and arrive pre-installed. Poisoned training data can plant behaviors that surface long after deployment. Capability misalignment produces a model whose tendencies drift from what its builders intended. Emergent behaviors show up that nobody trained for and nobody predicted. You will rarely observe these threats directly. You inherit their consequences.
The mitigations belong to the vendor too. They curate training data, run evaluation suites and benchmarks, and hire red teams, paid attackers whose job is to break the model before its release. The best-known alignment technique is Reinforcement Learning from Human Feedback (RLHF), in which human reviewers rate model outputs and the model learns to prefer the responses people rated highly.
All of it matters, and none of it is sufficient. Mavaddat names the ceiling precisely. "Training can internalise rules and heuristics. It cannot internalise the full set of conditions under which those rules should be overridden." Alignment can teach a model that destroying evidence is wrong. It cannot tell the model whether this deletion, requested today, by this user, under this retention policy, is evidence destruction. Treat the model layer as a baseline you inherit, not a guarantee you rely on.
The Execution Layer: What You Build
The execution layer is where the model's output turns into effect: the tools the agent may call, the permissions those tools carry, the memory that persists across sessions, and the governance that watches the whole assembly. When the model was the whole product, this layer barely existed. The moment you wire a model to tools and let it take actions, you have built one, whether you designed it deliberately or not.
You will meet this layer's name elsewhere with narrower scope, as the sandbox that runs agent code or as the gate that authorizes actions before they fire. Both live inside this layer. The sandbox is one tool boundary among several, and the gate is the layer's runtime edge. This book uses the term for the whole surface, because defense-in-depth has to cover the whole surface.
The threats here fire at the moment output becomes action. Tool misuse turns a legitimate capability toward a purpose nobody intended. Unauthorized action chains string individually approved steps into an outcome nobody approved. Context pollution lets junk or hostile content accumulate in the agent's working memory until it crowds out the instructions that matter.
Two more threats deserve names now. Unsafe patterns propagate through inheritance, because when an agent spawns helper agents, its permissions and configuration flow downstream by default. And privilege escalates through tool composition, where two tools that each passed review combine into a capability nobody meant to grant. An agent holding one tool that reads internal files and another that posts to the web is holding a data-leak channel, even though each tool looked safe on its own.
The defenses are architectural. Governance structures put more than one party, human and agent both, in the approval path for consequential actions. Tool boundaries scope what each capability can reach. Context hygiene keeps working memory lean and compartmentalized. Least privilege grants every component the minimum access its job requires.
Output filtering screens what leaves the system for sensitive content, the outbound twin of the context layer's inbound guardrails. Human oversight sits above the actions whose consequences cannot be undone. Action logging and audit trails belong on the same list, because you cannot govern what you cannot reconstruct. None of this is exotic. It is classical security engineering pointed at a new execution surface.
This layer gets the deepest treatment in the book. Chapter 6 makes the case for governance as a security control in its own right. Chapter 7 follows unsafe patterns down the spawn trees of multi-agent systems. Chapter 12 builds the posture discipline for agent tools and APIs.
The map also recurses. The coding harness you build agents with (the working environment wrapped around a coding agent) is itself an agentic system, with a context, a model, and an execution surface of its own, and Parts III and IV carry this same map into the development pipeline.
Why Single-Layer Security Fails
Single-layer security always sounds reasonable in the meeting where it gets approved. Three versions of it are circulating right now, and each one fails in a way the other two layers were built to catch.
We use an aligned frontier model, so we are covered. Frontier models are the most capable general-purpose models the big labs ship, and alignment shapes their defaults. Defaults matter. But an aligned model still follows hostile instructions it cannot distinguish from legitimate ones, and it acts with whatever permissions the surrounding system hands it. IBM's 2025 Cost of a Data Breach research found that 97% of organizations reporting an AI-related security incident lacked proper access controls around the AI itself. The model got the scrutiny. The system around it was wide open.
We validate and filter every input. Filters catch the patterns they know, and injection is exactly the attack class that refuses to hold still for enumeration. A clean input is not a safe outcome either. Tool misuse and runaway action chains need no hostile prompt at all.
We have strict tool permissions and governance. Of the three, this is the strongest single bet, because it lives at the layer you control most. Injection can still steer an agent into harm without ever crossing a permission boundary, and when the model itself misreads the situation, hallucinating a fact or misjudging intent, well-scoped tools will execute the mistake faithfully.
Each layer assumes the others might fail. That sentence is the design stance of this book, and every chapter that follows is an application of it.
Where Your Investment Goes
Lay the three layers along the path text travels, mark the owners, and the investment decision reads straight off the diagram.
Two of the three layers are yours. The vendor owns the weights, and your influence there ends at model selection and configuration. Everything else, the surface where text enters and the surface where output becomes effect, is developer-controlled, which means it is developer-secured or it is not secured at all.
The execution layer deserves the largest share of the investment, and the diagram shows both reasons. It is the last barrier before consequence, so it is the only layer positioned to catch what every control upstream of it missed. And it is where the interpretive frame gets constructed, because the facts that decide whether an action is safe, who asked for it, under which policy, against which data, do not live in the weights and cannot be smuggled in through input filters. They live in the architecture you build around the model. Mavaddat's transaction logs get decided at this layer, or they do not get decided at all.
That is also why I wrote this as a developer's guide to security architecture rather than a survey of model safety. Model safety is the vendor's full-time job. The interaction is yours.
The Moving Perimeter
Classical defense-in-depth granted defenders one mercy. The thing being defended held still. A firewall protected a network whose boundaries someone drew on purpose. An application security program protected code that changed only when a developer shipped. Layers failed, and the discipline assumed some would, but they failed in fixed positions around a fixed target.
Agentic systems revoke that mercy. An agent's effective boundary is its context, the accumulated working memory of everything it has read, retrieved, and produced. Every document the agent retrieves joins the attack surface. Every tool result comes back as content, and content can carry instructions. Every intermediate conclusion the agent records becomes input to its own next step. Each of those additions lands after your security review ended.
Picture an agent that starts its morning summarizing a vendor contract, pulls a pricing page at noon, and ingests a support ticket by mid-afternoon. Same agent, same deployment, three different attack surfaces in one working day. The perimeter you audited at deployment is not the perimeter running an hour into execution. When I threat-model an agentic system, I draw its boundary twice, once as deployed and once as it stands a day later. A static assessment can certify the system you launched. It says nothing about the system that exists once retrieval, tool results, and accumulated reasoning have rebuilt the boundary from the inside.
Defense-in-depth for agents therefore carries a requirement the classical version never faced. It is not enough for the layers to cover each other's failures. They have to cover a boundary that moves while the system runs. That one condition shapes more of this book's architecture than any other.
Defense-in-Depth in Miniature
The layered logic does not stop at the system level. It recurs inside individual control points, and one instance matters enough to plant now. At the execution layer's runtime edge, the moment an agent's proposed action either proceeds or does not, a single gate can run two tiers. The first tier is deterministic, made of checks that evaluate the same way every time: schema validation, allowlists, rate limits, policy rules. It is fast, cheap, and unambiguous, and it serves as the hard boundary.
The second tier applies AI reasoning, judgment of the proposed action against intent and policy, to the cases rules cannot express. A rule can verify that a deletion command is well-formed. Judgment is what asks whether this deletion is the compliance task the human approved or the evidence destruction Mavaddat warned about.
The tiers pair because each fails where the other holds. Deterministic checks are fast but brittle, and attackers route around fixed patterns. Reasoning is semantic but slower, and it is probabilistic, which means it can be wrong. That is exactly why the reasoning tier never serves as the hard boundary. It pairs with one. Throughout this book, AI reasoning enters as a new column beside deterministic controls, never as a replacement for them. Chapter 5 defines the mechanism, and Chapter 14 applies it at the runtime edge. For now, hold the shape, layers within layers, each covering the other's failure mode.
If You Read Book 1
This book stands alone. But if you read Agentic-Oriented Development, you will recognize its architecture returning here with a security job to do.
| Book 1 concept | Where it becomes security architecture |
|---|---|
| Context encapsulation (Book 1, Chapter 2) | The context and memory surfaces of the stack (Chapters 3 and 11 here) |
| VOICE tool design (Book 1, Chapter 3) | Tool boundaries at the execution layer (Chapter 12 here) |
| Configuration inheritance (Book 1, Chapter 4) | Unsafe patterns propagating through spawn trees (Chapter 7 here) |
| The Governance Triad (Book 1, Chapter 2) | Multi-party authorization at the execution layer (Chapter 6 here) |
The order is the point. Book 1 built these structures to make agents effective. This book hardens them, because the architecture that makes an agent capable is the same architecture an attacker will turn against it.
From Checkpoint to Posture
Safety emerges from interaction, so no single layer can guarantee it. The boundary moves at runtime, so no point-in-time audit can certify it. You cannot checkpoint your way to a secure agentic system, because no gate stays passed while the context keeps changing on the other side of it.
Security becomes a posture instead, a state you continuously assess and improve across every surface the agent exposes. Posture is the organizing idea of this book. Part II turns it into a discipline, seven posture domains built for continuous assessment. The layers map where controls live. The domains govern how you keep those controls alive.
None of it waits for Part II. Three moves start the posture work now. Map every agent you already run onto the stack diagram and write an owner's name at each layer. Rebalance the security budget toward the execution layer, beginning with an inventory of every tool the agent can call and the permissions each one carries. Then threat-model the boundary twice, as deployed and as it stands a day into execution.
If safety emerges from interaction, then interaction patterns are what you must secure, and interaction patterns differ by agent type. A conversational assistant, an orchestrator delegating work to sub-agents, and a coding agent producing artifacts for other systems to run do not share a threat surface, so layered controls tuned for one will under-protect the others. Before you can defend "the agent," you need vocabulary for which agent you mean. Chapter 2, Know Your Agent, builds that vocabulary.
The layered stance is the price of admission for all of it. Teams that adopt it while they run one agent will be ready when they run fifty. Teams that keep trusting a single layer will learn which one failed from an incident report.