FREE BOOK FOR SOC TEAMS
The Defender’s Guide to AI Agents
Download the free bookPDF · 84 pages · No email or signup required
An AI agent changed something in production. Can your team establish who authorized it, investigate what happened and stop further damage?
Learn what to log, what to detect, and how to investigate and contain AI-agent incidents.
If you have ever secured a service account, most of this will already be familiar.
What is genuinely new is a smaller part than the noise suggests, and it is what this guide is about. Most writing on AI security is written for the people building AI. This is written for the people who have to watch it.
Read it here, or take the whole thing with you.
Thirteen chapters plus a framework crosswalk, free, with no registration. Chapters 1 through 3 are a single sitting and will leave you able to ask sharp questions. The remaining chapters are designed to be used when you have to build, investigate, contain, govern, or measure something.
The PDF presents the material as thirteen chapters, four major divisions, three appendices, references, a subject index, and an author section.
Permanent citation: doi:10.5281/zenodo.22853869. This concept DOI always resolves to the latest archived edition.
Want the practical templates too?
Get the free Defender Pack: telemetry requirements, detection specifications and incident playbook templates.
Licensed CC BY 4.0, unlike the guide itself. Lift it into your own runbooks, change it, ship it commercially — just keep the attribution. This is the part meant to be taken.
Evaluating an AI SOC product? Use the AI SOC vendor evaluation checklist for 70 questions and an editable evidence worksheet.
How to read this
Applying these controls in a Microsoft SOC? The Sentinel to Defender portal migration readiness guide covers the permissions, telemetry, automation and evidence checks needed when the operating platform changes.
Who this is for. Anyone in a defensive security role - SOC analyst, incident responder, security engineer, risk or audit - whose company has started using AI and who has been handed the job of worrying about it.
What you need to know already. Very little. You should know roughly what a chatbot is, and you should have some security background: what a log is, what an account is, what it means for something to have permissions. That is enough.
What you do not need. You do not need to code, and you do not need to know how a model is trained, what a neural network is, or any of the mathematics. That knowledge is not useless - understanding how these systems are put together will make you better at this over time, and if you have it, use it. But none of it is a prerequisite for anything in this guide, so none of it is covered here. What you do need is to understand where the decisions happen and what the system is allowed to touch, and that is a different subject.
How it is written. Chapters 1 through 3 use one running comparison: you have hired an assistant. Every technical term is introduced as a fact about that assistant before it gets its real name. From Chapter 4 the comparison is retired and the real names take over, because those are the words you will hear in meetings.
Where you can stop, twice. Chapters 1 through 3 take about twenty minutes and will leave you understanding the threat well enough to ask sharp questions. Chapters 4 through 10 are what you come back to when you have to build something. Chapters 11 through 13 are for the team that has decided to build it - worked investigations, response playbooks and measurable readiness - and most readers will not need them until they do.
Read the thirteen chapters
- Chapter 1What You Are Actually Defending: AI Agents, for Security TeamsWhat an agent is, the one sentence that explains every attack, a real incident where nobody clicked anything, and the three risks that have no patch.
- Chapter 2AI Agent Security Glossary for DefendersEvery term you will hear, in plain English, each paired with the closest thing you already know.
- Chapter 3The Five Places an AI Agent Can Be AttackedContext, tools, memory, identity, orchestration — each with a real case and five steps you can run this week.
- Chapter 4The AI Agent Attack ChainEight stages, what you would see at each, and the three where breaking the chain is actually possible.
- Chapter 5What to Log for AI Agents — and What Each Platform Actually Gives YouSixteen event families, the spine that joins them, and what eight platforms actually record — including what they withhold.
- Chapter 6AI Agent Detections: What to Look ForThirty-four detections ranked by signal quality, each with its real false-positive cost and what it misses.
- Chapter 7AI Agent Security Controls, in Order of LeverageThe one control that changes the outcome, six more by leverage, and what to do if you only do three things.
- Chapter 8When the Model Changes Underneath YouPin it, record what was running, test it on a schedule, and treat a silent provider change as an incident.
- Chapter 9ISO 42001 for Organizations That Use AI but Did Not Build ItThe AI user role, the controls that matter, and what an auditor asks for when nobody can produce it.
- Chapter 10Your First 90 Days Securing AI AgentsThree stages, no budget, and the gate between them is evidence rather than the calendar.
- Chapter 11Three AI Agent Investigations, End to EndThree incidents worked from first alert to evidence package, showing which single field decides each one.
- Chapter 12Containing a Compromised AI AgentWhy killing the process is not containment, a four-rung ladder, and nine playbooks with the fields most omit.
- Chapter 13Measuring AI Agent Security ReadinessEleven measures, an acceptance test scored out of nine, and the implementation ninety days.
- Appendix CAI Agent Security: Framework CrosswalkMapped to every framework your auditor uses, with the four kinds of thing kept apart and five honest gaps.
When this guide changes
When this guide changes materially, I post a short update on LinkedIn explaining what changed and why it matters. Follow me there for update notices.
No newsletter or drip sequence. Only material updates to the guide and related defender resources.
How to read the evidence
Every numbered claim is sourced at the end of its chapter and includes the date it was last verified. The notes below explain how to interpret those sources, including early research, vendor references, documented gaps, and composite examples.
Where the research is early, the text says so. The false-positive range in Chapter 6's sixth detection is the clearest case: a published result that is genuinely strong on its own test data and genuinely unusable in a live queue. That tension is the finding, and hiding it would make this a worse document.
No vendor is named as the subject of a flaw. Not out of caution - because it does not matter. The incident in Chapter 1 was a flaw in how an assistant handles untrusted text, not in one company's engineering, and the same mechanism has been demonstrated against several products. Naming one invites the reader to conclude they are safe because they use a different one.
Vendors are named in Chapter 5, and that is a different thing. That section tells you which console to open and which setting to switch on, which is useless without the name on the door. Nothing there is a judgment about any platform; every one of them has real gaps, and the gaps are listed for all of them equally.
Where a vendor does not document something, Chapter 5 says so rather than guessing. Several entries are marked unconfirmed. That is a real state of the world - some of this is simply not published - and a guide that filled those gaps with plausible detail would be more comfortable to read and worth considerably less.
Some figures are narrower than their popular version, and the text says which. Two examples. The often-quoted “82% of MCP servers are vulnerable to path traversal” is not what the underlying report measured - it counted servers using file operations in that risk class, which is an argument for review rather than alarm. And the well-known collapse in code-generation quality between two model editions was, by its own authors’ account, largely a change in output formatting rather than a loss of reasoning. Where the careful version is less dramatic than the headline, this guide uses the careful version.
The examples in Chapter 1 have no fix, and that is the point. They are composites drawn from ordinary deployments rather than reports of single incidents. They are in the guide because a patched vulnerability is the easy case, and because these are what most organizations are actually carrying right now.