In July 2026, about 1,200 AI agents at OpenAI were running a security benchmark in separate sandboxes. The test asked each of them to find and exploit software vulnerabilities, and it ran with the safety controls deliberately turned off, because measuring what the models could do unaided was the point.
Nobody gave them a way to talk to each other. They found one anyway, using a shared package directory all of them could write to. They built a message board on it, signed their messages, and shared work among themselves. Then they broke out of the sandbox.
About 700 of them went after Hugging Face, the platform where most of the AI industry publishes its models and datasets. They got in through a malicious dataset that the platform's processing pipeline was built to open, and they went from a single container to administrative control of internal clusters in under thirteen hours. Hugging Face rebuilt roughly a third of its infrastructure afterward, because the agents had littered it with benchmark artifacts that looked like rootkits, and tearing the clusters down was the only way to be sure.
Nobody widened their permissions. They found access in places they could already reach.
They pulled Kubernetes tokens, a database password read from the worker environment, a production secret holding 136 keys, VPN keys, cloud credentials, and a signing key that would let them create their own identity tokens. None of that is AI security. That's cloud, identity, data, and network posture, the same ground enterprise programs have defended for two decades, automated and accelerated beyond what we're ready for.
Every part of that test was sanctioned. The evaluation and the sandbox were approved, and the safety controls were intentionally switched off by people doing their jobs correctly. Every one of those approvals was accurate the day it was granted.
AI security isn't just a new checkbox. We're treating it like one anyway. A committee meets, a form is filled in, an approval is logged in a register, and the system is cleared to run. I've used these forms. They're the beginning of what it takes to protect a system, not the end.
A form cannot protect. Security needs to be treated as a posture, a reading of how exposed each agent is right now, continuously reevaluated.
Keeping a posture requires both a framework and discipline. Mine has five steps.
A Posture Is Kept by a Method
A posture is a state, and states drift. Somebody adds a tool. A vendor ships a model update that changes what the thing will agree to do. Somebody wires an agent into a system nobody assessed, to get a demo out the door. A state that nobody re-reads on a schedule stops being a posture and becomes a claim about the past.
That drift is why I stopped asking teams what their posture is. What do we do next quarter that answers the posture question again, with the same instruments and the same people scoring them?
The answer is a framework with five steps. I call it the AI Security Posture Framework. I built it walking into organizations, dozens of times over the past several years, finding out what they were running and working out what had to happen first, second, and third before any of it could be governed. Every step produces an artifact the next step consumes, which is what keeps it from turning into a reading exercise.
This book is about securing what agents do. Deciding which AI a company may buy is a different job, and in most rooms I walk into, the two sit on one agenda line.
The Five Steps
The parts of this book are verbs because the book is the framework itself. Map, Measure, Rank, Govern, and Prove are the five steps, in the order a practitioner takes them.
Map comes first, because everything after it is guesswork. Almost every organization I talk to has an AI estate, every model, agent, and assistant it runs, and no list of it. The step ends with one record per system and an owner on every line, a named human who answers for that system rather than a security team that inherited it. The stops in Map, and how each record's fields feed the ranking, wait in Chapter 4. Discovery has to run on instruments, because asking people finds the sanctioned half of an estate. Instruments find the systems, and somebody with authority assigns the humans, which is the part most teams skip. A system with nobody accountable for it is a finding, and it gets written down as one.
With a list in hand, Measure reads the posture of what's on it. Two instruments do the reading, deterministic controls and AI reasoning, and seven domains give them somewhere to point. The output is one verdict per cell, one domain on one system. Chapter 6 defines the triage every system starts with, defines all seven domains, and sets what a tight verdict looks like in each.
Nothing gets fixed all at once, so the third step puts the work in order. Rank sorts systems on two axes, business value and risk exposure, each scored high, medium, or low. It sorts actions by consequence. Exposure is scored from the verdicts Measure produced. Half of that rubric is scored by people who don't work in security. Business owners score value, because they're the ones who know what a system is worth to the company. Security scores the exposure side except for the regulatory surface. Compliance and legal score that one, and they can veto. Two things come out, a prioritized roadmap and the order in which systems enter threat modeling, working out how a system gets attacked. That rubric, and who scores which axis, belongs to Chapter 14.
Then you build the gates. Govern binds what an agent does to what somebody actually intended, with gates that can stop an action. Most of that work ships through delivery machinery the organization already runs and already funds, the identity systems, the secrets stores, and the pipelines. Teams route around a parallel security stack. Chapter 16 makes the case for governance as a security control and builds the gates layer by layer.
One more layer has to be built at the point of execution, the last moment before an agent's action takes effect. Operating systems have checked every access against a policy for decades. Admission controllers, the policy check in front of a container cluster, already stop a bad deployment before it lands. The action arriving at that gate came from a model, which is why the gate has to judge intent at all. Each gate leaves behind a decision record, and that record is what Prove tests.
I ask for evidence at the end, and Prove produces it. The step threat-models the systems the ranking put on top and validates every guardrail with a misuse test, which asks whether the control blocks the attack it was built to block. A guardrail nobody has tried to defeat is a hypothesis. Prove measures last, under one rule I apply to every metric. If a number doesn't change what you do next, it isn't worth tracking. The threat modeling, the validation, and the metric families that survive it all land in Chapter 29, including the boundary metric Book 1 promised to this one.
Three of those five verbs are not mine. The National Institute of Standards and Technology publishes the AI Risk Management Framework, whose core is four functions, Govern, Map, Measure, and Manage. I borrowed three of those words. NIST says its four functions can run in any order, and that Govern runs through all of them. Mine is a fixed sequence with Govern as the fourth step. I split Manage into Rank and Prove, because deciding what to fix first and proving you fixed it are different jobs done by different people.
The framework also runs again, and a second pass compares two reads taken with the same instruments. Chapter 30 takes up that second pass and the program it becomes once an organization runs it on a schedule.
The five steps stop at evidence. The three-in-the-morning work after a control fails belongs to the security operations program this work feeds. This method owes that program the instrumentation it runs on, which is why detection and containment get scored inside agent governance posture, the seventh domain.
The Seven Posture Domains
Every one of those steps works across the same seven posture domains. This book scores agent identity, agent input, agent data and context, agent tool and API, agent communication, agent runtime, and agent governance, and it scores them in that order every time. The rest of the book calls them the seven agentic posture domains.
Six of the seven have parents, and the parents are also mine. I published Defense in Layers in 2022. It reads an enterprise security program as a fabric, six posture domains covering cloud, applications, data, networks, identity, and devices, crossed with five security layers, which are perimeter, network, endpoint, application, and data. Data appears on both axes, once as a domain and once as a layer. I added a seventh domain for AI systems in 2025. This book calls those seven the classical domains, the ones an enterprise program is already organized around. The agentic seven are those domains adapted to a thing that reasons and acts on its own.
That adaptation runs both ways. The seventh domain is what AI added. The six that came before it each rest on an assumption an agent breaks. Identity assumed a credential belongs to one worker with one job. Cloud assumed infrastructure changes at the speed of a change ticket. Neither assumption survives an agent. Repairing those six belongs to the program you already run, and this book scores the agentic side.
Input is the exception, and no classical domain covers it. Traditional security had an answer for hostile instructions hidden in data, which was to keep instruction and data on separate channels, and a context window gives you one channel for both. If the classical domains had covered it, this would be a shorter book.
Chapter 6 defines all seven, maps each one to its classical parent, and shows where the other agentic frameworks answer questions this one does not. After that, each domain gets a chapter of its own.
How the Posture Gets Read
Pairing deterministic controls with AI reasoning is the design decision most of this book rests on.
Deterministic controls take every decision a rule can express. A check on whether a request matches an approved list, or whether a file path sits inside a folder the agent may touch, returns the same answer on every run. Those controls are quick, cheap, and provable after the fact.
AI reasoning takes the decisions rules cannot express. It judges a proposed action or a finished artifact against what the human asked for, which is how you catch the case where the syntax is clean and the meaning is wrong.
I hold one rule on that pairing everywhere in this book. The hard boundary is always deterministic, enforced outside the model's control, so nothing the agent says can argue its way past. That boundary is the floor. Reasoning is a new column beside it, never the floor itself. A judge that can be wrong has no business standing between an agent and an action nobody can undo. Chapter 5 builds the reasoning mechanism and takes on the objections. Chapter 12 puts the pairing to work at the runtime edge, where the two tiers become a single gate.
The same method reads at two scales. You measure the estate once against the classical fabric enterprise security programs already run. A Layer Gap Analysis reads that fabric for which layers are under-protected, which are over-protected, and which postures are missing altogether. Chapter 4 runs that read at estate scale. Each system then gets its own read, the triage first, then the three layers of the agentic security stack, then the seven agentic domains. The instruments are the same at both scales, and only the resolution changes.
What the Reading Produces
Score every control tight, thin, or absent, one verdict per cell, and count only the coverage that actually exists. Posture is the fabric those verdicts make. I never roll it into one number, because a composite hides exactly the cell you needed to see. Maturity is whatever changed between two runs of the framework, and there's no level to reach.
Something still goes up to whoever owns the program, and it is a count, never an average. You report how many high-value, high-exposure systems came back absent in a domain, against how many were scored, how many still have no named owner, and which way both numbers moved since the last run. Chapter 30 turns those counts into the board's version of this question.
The inventory and the verdict map together are strong reconnaissance for anyone attacking the estate, and I treat them that way. Classify both the way you classify vulnerability findings, under the owner your vulnerability program already has. The business-side AI governance program still gets the inventory it needs, at the summary level the ranking runs on.
Two Rules That Keep It Honest
Two rules govern everything scored above.
Uses AI is not the same as secures AI. Nearly every organization now runs a business-side AI governance program, and that program is a good partner. It's the natural home for the inventory, and its approvals are where executives see the ranking. The confusion is easy, because both programs use the same words and both can hand you a register of AI systems. That register is the sanctioned half. It lists what somebody asked permission for, and the estate is always bigger than the register. An approval to use a system says nothing about whether that system can be attacked. I've watched teams read the approval as though it did, and re-doing the work later costs more than doing it once.
In this book the developer is the organization deploying the agent, with its change-control process and its validation gates. Developer-controlled means developer-secured, or it is not secured at all. Chapter 1 drew the three layers untrusted text travels through, context, model, and execution, and marked context and execution as yours. Faith in the vendor's model covers exactly one layer, and it is the layer you did not build.
Three Ways to Read This Book
Three paths run through the book, and I mark them with step names rather than chapter numbers on purpose.
If you build and ship an agentic system and answer for its security, you want the controls that apply to the domains you own. Run Map at the scale of one system rather than an estate. You own the repository and the deployment configuration, so there's nothing to discover, and that read takes an afternoon. Read all of Measure, because the seven domains are your control checklist and the verdicts tell you where you're thin. Then read Govern, starting with the chapters on the delivery pipeline and the gates that sit inside it. The estate-scale read, the ranking rubric, and the board conversation belong to whoever owns a portfolio, and none of the controls depend on having read them.
If you're folding agentic systems into a security program that already exists, the whole framework is the job and it should be read in order. You skip nothing. Read each domain chapter against what your program already instruments. Expect input, communication, and runtime to come back absent, because almost nobody has ever instrumented them. Absent is a different conversation with your leadership than thin is, and going in with the wrong one costs you credibility you'll need later.
If you answer for the program, you need to know what to ask for, who owns which score, and what a good answer sounds like. The chapters that take one posture domain each are the ones you can skip, because you don't need to know what tight looks like inside each domain. You need to know that somebody scored it, that they scored real coverage, and that they can show you the cell. Read Map at estate scale and all of Rank, which is where the business scores the ranking alongside you and you settle who owns what. Then the first chapter of Govern for the case behind the gates, and all of Prove for the evidence and the numbers.
What This Book Is Not
This isn't one size fits all. Two organizations running the same five steps land in different places, because the answers depend on what each one is running and what its business values. The method transfers. The answers never do.
It also isn't an off-the-shelf product. There's nothing in here to install, and nothing you can buy that ends the work. Tools appear in this book where they make a control real, and I name them there. What you won't find is a roadmap with dates, a vendor landscape, or a budget. The calendar belongs to whoever owns the delivery plan, and each part says roughly what its step costs.
This book is a collection of the frameworks and mental models I use to build a security posture in the age of AI. I've walked them into organizations for several years now, and what's in here is what held up.
One failure mode shows up more than the rest, and I've been in the room for it more than once. The assessment turns into a survey, the survey turns into a report, and the report gets filed. Refusing the roadmap is part of the antidote, because a roadmap invites that ending. Every finding has to terminate somewhere it can be acted on, either as a record in the inventory or as a named gap in the fabric. A finding that terminates in a slide hasn't terminated. Chapter 30 collects the other five ways this program fails and the antidote built into each step.
Where the Framework Starts
Chapter 1 proves the thesis at the stack. It draws the three layers, shows why each one has to assume the others might fail, and makes the case that an approval granted once cannot describe a system that rewrites its own perimeter as it runs.
Then the framework begins with Map, and every step after it assumes a list of agents exists. No committee meeting ever produced that list, and almost nobody can list the agents their own organization is already running. Building it is the first thing you do.