I was at home on the couch over Christmas vacation in December 2021, scrolling LinkedIn, when I came across an article about a new vulnerability in a logging library called Log4j. I sent the link to my Chief Architect as a casual heads-up. "Hey, check this out."
I woke up the next morning to chaos. I worked at a large financial services company, and it had pulled together a SWAT team with three streams, Infrastructure, Applications, and Vendors. Of the three, Applications was mine to run.
Infrastructure and Vendors had to begin with spreadsheets, manual scanning, chasing people down, and meeting after meeting. That isn't a knock on anyone, since that's what discovery by hand looks like.
My stream had an instrument, and it came out of three months of quiet work. We had moved the scanning that lists every application's open-source libraries off an on-premises tool and onto a hosted platform. Then we had brought our source code repositories into it, one after another. I also had early access to the vendor's enterprise-wide reporting, which at the time was just another feature on a roadmap. Our source of truth for what each application was built from had already moved from what developers told us to what the scans showed.
I logged in to the reporting console and ran a single query, asking which of our applications depended on Log4j. The answer was about 300 rows long. Each row carried an application's name, the repository that held its source code, and the person who owned it. I remember how calm I felt.
Because every row had an owner, every team on that list heard from me within a day or two, and I could tell each one which library was vulnerable and where it sat in their code. Every day after that, I pulled the report again, and the number still vulnerable kept falling. Two weeks in, it read zero, and the SWAT team's leadership got the formal report-out for my stream. The other two streams were still at work a month after that.
The query was fast, but speed isn't what got my stream to zero. Every row tied an application to the place its code lived and to a human who answered for it.
What the Query Knew
A record is that three-way link, a system tied to where it lives and to who owns it. Underneath my rows, the scanner's inventory did the job a software bill of materials does. It listed what every application was built from.
Your organization has an AI estate, every model, agent, and assistant it runs. Now try to answer what my query answered. Which AI systems do you have, where does each one run, and who owns each one? From what I've seen, almost no organization can answer all three, because AI lives in more places than a repository.
It sits on laptops, in browser extensions, inside the software the company rents, in the access people grant when they sign in to a new tool with a work account, and in meetings. No single console holds all of that, so there's nothing to query. The estate has to be discovered.
I call that work Map, and its whole job fits in two lines. See the estate. One record per system, an owner on every line. Map is the first step in the AI Security Posture Framework, which I built to work through an AI estate in five steps, Map, Measure, Rank, Govern, and Prove.
You can run the framework at two scales, the estate and the single system, and this chapter is Map at estate scale. Discovery ends in the inventory, all of those records together, and in one estate-scale read that sets the whole estate against the security program you already run. If you ship one agentic system, the section just before this chapter's close is yours.
The AI Security System Map
Before discovery starts, you need a picture of the ground. My name for that picture is the AI Security System Map, and it covers the whole estate.
The map follows a single request from the person who makes it to the model that answers it. The request starts on a device, inside a chat window or a code editor, and from there it reaches an agent, the tools that agent can call, and a model. Somewhere along that path there may be an AI gateway, a checkpoint between the people or applications and the models, tools, and agents they call, where traffic can be logged and rules applied.
The map also shows the data and the context the AI is handed, everything it can read and remember. It shows the systems where its output turns into an effect, like a ticket opened or code merged. Some things cross the whole picture, including identity, the build pipeline, and third and fourth parties (your vendors and the vendors behind them).
A public chatbot open in a browser tab belongs on this map. So does the assistant your own teams built on company data, and so does the agent that arrived inside software the company rents.
I haven't found anyone who lists this whole path as one set, so I put it together myself. Discovery works through five sources, and together they cover this picture.
Five Sources, in Order
The sources run in a fixed order that follows the map, from where a person touches AI, inward to the agents and models, and then out to the vendors. Each source draws on several instruments and shows the same estate from a different side, so the sources overlap by design. On a first pass I work from reports the owning teams pull from the instruments they already run, paired with interviews.
The first source is the endpoints, where I find out which desktop AI apps, browser AI extensions, local models, and coding agents in code editors and terminals are running on company devices. I ask the device team for the device-management inventory, endpoint security telemetry, software asset lists, and the configuration files on those devices that connect AI apps to outside tools.
The second source is the network, where I'm after the AI traffic, the calls out to model APIs and to AI tools sold as software-as-a-service (SaaS), sanctioned or otherwise. SaaS is software the company rents rather than runs. I also check whether an AI gateway exists at all. I ask the teams that run the network for web proxy and cloud-app logs, outbound traffic analytics, and the firewall's website categories.
The third source is identity and access, starting with the identities that agents and other workloads run under and what their credentials allow. I also look at what those identities can reach, meaning the data the AI can touch, the applications and pipelines that embed AI, and the cloud AI platforms. I ask the identity team for its inventory of sign-on grants, the access people hand a tool when they sign in with a work account. The same team holds the access-review records and the service principals, the accounts that software signs in with. Data classification, inventories of cloud accounts and API keys, and build pipeline configurations come from the data governance, cloud platform, and build teams.
You'll want that grants inventory the day attackers compromise a tool that one employee signed in to. In its April 2026 security bulletin, Vercel wrote, "The incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee." Vercel also published one app's identifier and added, "We recommend that Google Workspace Administrators and Google Account owners check for usage of this app immediately." The way I read it, every company on Google Workspace got an inventory query to run first, a search of its own sign-on grants.
The fourth source is the AI components, and I cover it with the owning team, platform by platform. We go through the AI systems themselves, meaning the models, the prompts, the agent frameworks they're built on, the retrieval stores they search, and the tools each agent can reach. In its 2026 AI report, Netskope wrote of the Model Context Protocol (MCP), "MCP, the open-source standard for connecting AI models to external data sources and tools, has experienced a surge in use, with users increasing by 250% and transactions by 375% over the past 10 weeks alone." Netskope's numbers come from its own customers' telemetry. I also ask for repository scans that find AI libraries, MCP configuration files, and agent configuration files, and for the platform team's list of deployed models.
The fifth source is the vendors, where the question is which of them process your data with AI, under what terms, and through which vendors of their own. I ask the third-party risk team for the vendor inventory, recent AI assessments, privacy impact assessments, and procurement records, and I get the expense records from finance. Chapter 20 of Agentic-Oriented Development showed procurement asking vendors for evidence artifacts, and that's what this source asks for. That December response had a Vendors stream of its own. Of the five sources, this is the one where everything I ask for is a document somebody wrote.
An AI notetaker often gets adopted one attendee at a time. Then it's a third party nobody procured, and none of those documents names it. It turns up under identity and access, among the sign-on grants and calendar integrations, because the sources overlap.
In August 2026 a security researcher published his findings on tl;dv, an AI meeting notetaker, and by his account he saw "181,874 meeting records belonging to 84,312 unique users across 35,003 email domains." The vendor said the vulnerable data "was strictly limited to metadata" and listed it as "meeting identifiers, conference IDs (the links used to join Google Meet or Microsoft Teams calls) and participant email addresses and domains." He reported using those links to join two live meetings uninvited.
The records sat in a cloud database service the vendor used, a fourth party one layer behind it, though the access rule that failed was the vendor's own. Could you list the notetakers in your own meetings, and whose account sent each one?
What Asking Misses
If answering that question means asking around, you're standing where the Infrastructure and Vendors streams stood in December 2021. I know my stream was easier, since all we had to do was scan our code. It was also an example of security preparedness. We had all the source code repositories in one location, used the same tool to scan them, and had a single report that showed every repository with the newly uncovered vulnerability.
Ask people what AI they use, and they'll tell you in good faith about the tools the company gave them. A personal account never comes up, and neither does the feature a vendor switched on or the notetaker a colleague's account sent. Discovery has to run on instruments, because asking people finds the sanctioned half of an estate.
The rest is shadow AI, the AI at work in your company that nobody approved. You find it in outbound traffic logs, sign-on grants, service principals, and expense records, down to the subscription somebody put on a corporate card. None of those depends on anyone remembering to tell you. I still do the interviews, and they run beside the instruments at every source.
A Cloud Security Alliance survey commissioned by Token Security came out in April 2026, and its announcement says, "While 68% of organizations believe they have strong visibility, the high number of undiscovered AI agents contradicts this perception."
Before I pull traffic logs, endpoint telemetry, sign-on grants, or expense records, I bring in privacy and legal. Discovery reports tools and counts rather than the names of the people using them, and I tell people up front that it's looking for systems. When discovery turns up sensitive data leaving through a personal account, that's an incident, not a count, and it goes to incident response.
And instruments only help when you know what you're looking for. The authors of the same Netskope report wrote that "shadow AI discovery priorities have expanded from gaining visibility and implementing controls for personal AI app use to include AI agents, MCP servers, and local AI infrastructure."
I sort the shadow AI in an estate into seven categories. They're general assistants on personal tiers, coding and build agents, embedded SaaS AI, and meeting and research agents. The rest are workflow and browser agents, direct API calls and local models, and security's own AI. That last one is there because security teams adopt AI too, and it goes through discovery like everything else. The grid below shows which of the five discovery sources turns up each one.
Once you know how a system got in, you know which gate failed. I count four entry mechanisms. The first is an unapproved app, and app approval is the gate somebody walked around.
An unapproved tier of an approved app comes second, as when the company pays for the business tier and someone signs in to the free one with a personal email. Account binding, which ties an app to a work login, is the gate that failed. Harmonic, a vendor reporting on AI use across a panel of enterprise organizations, wrote that "64.5% of activity on personal accounts is business use, not personal."
In the third, an AI feature arrives inside an approved app without a review of its own, because the re-review trigger, the rule that sends a changed app back for another look, never fired. The fourth is autonomy bolted onto any of those, where the AI now acts on its own and nobody ran the autonomy review. Three of the four can happen to an app the approved-tool registry already lists. A tier, a feature, or new autonomy can arrive long after the approval, so every record carries the date it was last confirmed.
Guardrails at Every Layer
Go back to the System Map. During discovery, you find where the AI is, and at each place you also find where a control could sit. The map as I first drew it showed one checkpoint, the AI gateway. An estate needs more than one. A control point is a place where a guardrail can sit between a request and its effect, and the System Map marks one at every placement a request crosses.
A guardrail is any control around the AI, whether that's a technical control, a policy a system enforces, or monitoring. It runs as code or configuration and never as a prompt, and the bare word never tells you how strong one is.
Guardrails come in two strengths. 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. A soft guardrail, a term I owe to Chris Hughes, watches for trouble by reading text an attacker may have written, so it can be fooled.
A request crosses control points at the endpoint and the browser, the application, the network (with its AI gateway and other proxies), and the cloud platform. Then it reaches the agents and their tools, where output turns into an effect. It also reaches the data and the context, and the model. Identity crosses all of them, and the build pipeline is where build-time guardrails sit.
An estate can run several AI gateways, in more than one cloud and in its own data center, with their rules set from one console, an AI control plane. It enforces nothing itself, so it isn't a control point. It's where the rules for many control points get written, and a compromise there can rewrite them all.
At each control point I record two facts. One is whether a guardrail exists there, and the other is whose it is, yours, a vendor's, or nobody's. That second fact depends on whether the system runs in-house, inside software the company rents, or hosted by a vendor. An assistant built into a SaaS product sits inside rented software, and a model your own code calls is vendor-hosted. At the endpoint it also depends on whether anyone manages the device. For the AI control plane, I record whether there is one and whose it is.
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. For an agent built in-house, your organization holds the control points in the code and configuration it runs, from the application inward. The ones at a model or tool somebody else hosts go to whoever hosts it, which is you if you run it yourself. For AI inside a SaaS product, your organization holds fewer control points and the vendor holds the rest, so the ones you do hold carry more weight.
Chapter 1 showed layering in two places, inside one system and inside one control point. The System Map adds a third place, every layer of the estate. Each layer assumes the others might fail. Layers of the same kind fail together, so a second soft guardrail at a layer can fail along with the first.
Read the vendors, and each one puts control where its own product sits. CrowdStrike writes, "The endpoint is the control point for AI agent security." A customer's security chief, quoted in a Palo Alto Networks release, said the browser will stay "the single control point." Amazon Web Services describes its AgentCore Gateway as "a single, secure entry point for agentic traffic." Okta shifts agent authorization to a company's central sign-in service, and Microsoft's Purview, a data security posture tool, centers on "the data itself." I lined the five up myself, and each is partly right.
A gateway on its own leaves gaps. The Open Worldwide Application Security Project (OWASP) warns that a gateway guardrail "may miss multi-turn prompt injection attacks," where the hostile instructions arrive over several messages. Cloudflare's own documentation says a blocked user can still reach an MCP server "by using its direct URL."
A tool running beside the agent on the same machine never crosses a network gateway, since that traffic stays on the machine. The tool's own outbound calls can still cross a proxy. The MCP specification's authorization rules cover only servers the agent reaches over the network. A tool the agent launches directly is told to read its credentials from local settings instead, so its control point sits on the machine.
A May 2026 joint guide from the cybersecurity agencies of Australia, the United States, Canada, New Zealand, and the United Kingdom states the general rule outright. "Avoid reliance on a single security mechanism by implementing multiple, overlapping layers of security controls." No government or standards body I've found names the endpoint or the browser as a control point for AI, so I chose to put those two on the map.
This chapter only locates control points. Chapter 6 takes up how the guardrails found there count toward a verdict of tight, thin, or absent, based only on the coverage that actually exists. Chapter 12 asks whether each control point holds a hard boundary or only a soft guardrail.
The Map Has Shadows
The framework holds every step to an honesty rule, which is to name what was covered and what was not, and Map is where it starts. The System Map also draws its shadows, the places discovery can't reach, and the grid has a column for what no source finds.
Local models on devices nobody manages are one shadow. The download may cross the network once, but running the model leaves no network trail. Only device management would see the model run, and those devices have none, so no source does. The other is a personal account on a personal device, which sits outside all five sources.
In May 2026 a bank holding company filed a report with the Securities and Exchange Commission about an internal incident. Certain non-public customer information, it said, was handled using "an unauthorized artificial intelligence-based software application." The filing doesn't say whose account or whose device. American Banker later reported that an employee used a personal account, and the bank's chief operating officer told the paper the employee accessed the data from a personal device. Discovery would never have seen any of that, so the control that matters there is on the data and on which devices can reach it.
Nobody should read an inventory as complete, so my inventory carries a line that says which sources were covered, which instruments the owning teams could produce, and which they couldn't.
One Record per System
The map puts every place AI runs on one picture, and it still can't tell you what any one of those systems is or who answers for it. Both answers live in a record, one for every system discovery found.
The inventory isn't my idea. The National Institute of Standards and Technology (NIST) asks for it in its AI Risk Management Framework. One entry under its Govern function reads, "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." Nothing in that entry tells you how to find what nobody declared, and that's what discovery is for.
A record answers five questions, where it came from, what the system is, who owns it, what it's made of, and what makes it exposed.
Two fields say where the record came from. The first is how the system was found, whether somebody declared it or an instrument turned it up. It also names the instrument and the date the system was last confirmed. Dates matter, because you run discovery again, and anything you report from these records has to say how old it is.
The second is registry status, meaning the system is in the approved-tool registry, absent from it, or has no registry to be in. No registry is itself a finding. An app can be listed and still bring in AI nobody approved, through a personal tier, a new AI feature, or autonomy somebody bolted on, so "registered" never means "known."
Your company may already run an AI governance program on the business side, and if it does, its register of approved AI systems is usually the same list as that registry. That register is the sanctioned half. It lists what somebody asked permission for, and the estate is always bigger than the register.
That program is a partner and the natural home for the inventory, with a register that tracks what the company uses. Uses AI is not the same as secures AI.
The fields about the system itself carry the name, the use case, the models and versions behind it, and the deployment home, where the thing runs. Deployment home also settles who holds each control point, you or a vendor.
The record should be able to produce Chapter 2's placard, a one-sentence description of the agent. Three more fields build it. They hold the agent type, its deployment domain, and its lifetime. The domain is the business problem the agent serves, like healthcare or finance, and the lifetime is whether it's permanent or ephemeral.
One field names the accountable business owner, a human being with a name, rather than a security team that inherited the system. A separate group of fields covers what the system is made of. That group says whether AI-generated code reaches the system's pipelines. For any MCP server in use, it records whether integrity evidence exists, meaning something that shows the server is still the one you approved.
The group also tracks the system's AI bill of materials, the list of what an AI system is built from. In July 2026 the Cybersecurity and Infrastructure Security Agency (CISA) and its partner agencies updated their voluntary minimum elements for a software bill of materials. CISA's announcement says the revision applies to "all software, including open-source software, AI software, and software-as-a-service (SaaS)." For elements specific to AI, it points to separate guidance CISA released with its Group of Seven partners in May 2026.
The record also has to say what makes a system exposed, and four fields hold that. The first is privilege and blast radius, meaning whether the agent can act at all, with what tools and credentials, and whether it can spend money or send data and messages out. Data sensitivity is the classes of data it touches, input trust is which untrusted inputs reach it, and regulatory surface is the regulation that applies. You fill in the privilege field from what Chapter 6 of Agentic-Oriented Development called the Agent Composition Model, an agent's instructions, guardrails, and tools. None of the four carries a score.
A regulated system, like software that ships as a medical device, also carries a validation status. Unvalidated and regulated is a compliance finding on its own, and it goes to the compliance team alongside what security finds.
Banks have inventoried and validated their models under supervisory guidance on model risk for more than a decade. In April 2026 the US federal banking regulators replaced that guidance. The new one says, "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." It adds that a bank's own risk management and governance practices "should guide the determination of appropriate governance and controls." Under the new guidance, the bank decides for itself whether an agent counts as validated, and the record is where that decision gets written down.
One record covers one deployment with its own owner, its own data reach, and its own ability to act. If any of the three differs, I write a second record. A company-wide assistant rollout is one record with its use cases listed inside it, and an agent built on top of that assistant, with different tools or credentials, gets a record of its own.
This record asks for three things NIST's entry doesn't. It says whether each system was found or declared. It names one accountable owner rather than a list of contacts, and it carries the exposure fields that feed the ranking. NIST files the inventory under Govern, and this framework does it at Map. I borrowed Govern from NIST, along with Map and Measure.
In September 2026 OpenAI described a program it runs to find and fix vulnerabilities in its own software, starting with an inventory. By OpenAI's own account on the program's web page, its agents inventory the company's services and "connect exposed endpoints to code and owners, preserving evidence and gaps so discovery starts with a clearer scope." That's a record's three-way link, a system tied to its code and to its owner, built by agents.
OpenAI has an interest in the story, its numbers are its own, and what it built is an inventory of software and services, not an inventory of AI systems. The program shows that inventory and named owners come first, even at machine speed, and it proves nothing about an AI inventory. Map is where you build the record and get an owner named on it.
An Owner on Every Line
When a vulnerability in a common logging library hit in December 2021, the list of affected applications I pulled already carried a person's name on every row, and that's why reaching every owner took a day or two. Chapter 0, where I set out the framework, made a promise about where that name comes from. "Instruments find the systems, and somebody with authority assigns the humans, which is the part most teams skip."
An instrument can read an owner off a system of record, because somebody already put the name there. Naming a human for a system nobody has claimed takes authority that no instrument has.
OpenAI names the ownership bottleneck on that program's page. "Findings wait for an owner." OpenAI reports that it turned the service and ownership information it had into inputs its agents could use, and that this "improved our accepted ownership assignments to 90.6%," with people "handling ambiguous cases." I take that to mean the agents looked owners up in records OpenAI kept, and people decided the cases those records didn't settle.
In July 2026 Microsoft reported from its roundtables with 150 identity professionals that "Nine in 10 roundtables raised the ownerless-agents problem," with agents "tied to their creator's identity." One participant, in Microsoft's telling, said, "I was doing a demo one day, I looked at our corporate tenant, and we had like 44,000 agents. I just couldn't believe it, after so little time."
Who names the owner? My working answer is the executive sponsor of that business-side AI governance program, since the program keeps the company's register of AI systems. The person they name is the head of the business unit that funds or benefits from the system.
Until somebody is named, the record reads "none." No owner is a finding. After each round of discovery, whoever owns the security program gets a set of counts, and one of them is how many still have no named owner. Security never becomes the owner by default.
The owner field is the first rung of the accountability ladder Chapter 16 of this book lays out, and here it's mandatory. Chapter 30 takes up the board conversation, and its first question, what the company's agents can do and who approved each one, starts in this record. Registry status says whether a system was ever approved, and the date it was last confirmed says whether that still holds. For the shadow half, the honest answer is nobody. I still don't have a clean answer for the system nobody will claim. It stays unowned, and it stays in the count.
How the Record Feeds the Ranking
An owner on every line still doesn't tell you which system to read first. The four exposure fields go to Measure, which weighs them when it judges whether the guardrails around each system are tight, thin, or absent. Exposure is scored from the verdicts Measure produced. Rank does that scoring without collecting anything a second time, and Chapter 14 takes up its rubric. A strip on the record card names which step reads which field.
You do make one judgment when you write the record. A system that can act or send data out, touches sensitive data, and takes untrusted input goes to the top by definition. That's Simon Willison's lethal trifecta, widened so that acting counts as well as sending data out. I'd rather be wrong about the order than slow about the worst system on the list.
Chapter 6 of this book sets the triage every system goes through, and the systems at the top get the full read first while the rest queue behind them. Write the queue on the list itself, so everyone can see which systems are still waiting.
Don't wait for a finished inventory. OpenAI says its own teams didn't. "In parallel, teams tackled urgent issues even before the inventory and ownership model were complete."
The Record Is Reconnaissance
In Measure, you turn these records into a verdict map, which grades the guardrails on each system tight, thin, or absent. The inventory and the verdict map together are strong reconnaissance for anyone attacking the estate, and I treat them that way. Classify both, and the exports you pulled to build them, 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.
The first reconnaissance technique in MITRE's public catalog of attacks on AI systems (ATLAS) has attackers search published research to learn "how and where AI is used within a victim organization." That's a description of an inventory.
Governments that keep AI registers already split them by reader. For some high-risk systems the European Union's AI Act puts registration in "a secure non-public section of the EU database." Even that registration leaves out the description of "the information used by the system (data, inputs) and its operating logic," though the intended purpose stays in. The White House budget office has most federal agencies inventory their AI use cases and "post a public version on the agency's website."
Two questions sort every field. Does someone need it to decide who answers for the system and how much it matters? Then it goes up, to the governance side. Does it tell a reader where the system is, what it's made of, or how to reach into it? Then it stays down. When both answers are yes, a coarser version goes up and the detail stays down. I built that test myself, because nothing I read tells a company which fields of its inventory go to which people inside it.
The full record holds every field, one record per system. It lives with the owner of the vulnerability program. The security staff working the estate read it, and each owner reads their own. A change to an owner or a registry status needs sign-off from the executive sponsor who names owners. Log every change, and make sure incident response can read the full record at any hour.
The summary copy is one line per system, and it lives in the governance program's register, where the business owners read it with compliance and legal, who judge the regulatory surface. That copy is how the register finally gets the half nobody asked permission for. The roll-up names no system. It goes up to whoever owns the security program after every round of discovery, and it is a count, never an average, because an average hides the worst systems.
Each line of the summary copy carries the owner's name, and deployment home only as its class, whether in-house, inside rented software, or vendor-hosted. The full record keeps the models and versions, the exact location, and whether a guardrail exists at each control point and whose it is, because a list of places with no control is an attack plan.
The Estate-Scale Read
Every record so far covers one system. The last thing each round of discovery produces is a single read for the whole estate. It sets what you found against the security program you already run.
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. Like data, network and application appear on both axes, because a layer is where a control sits and a domain is what the control is measured against.
This book calls those seven the classical domains, the ones an enterprise program is already organized around. On this fabric a cell is one security layer on one classical domain. In Measure, a cell is one domain on one system.
Findings from the five discovery sources fill those cells. Vendors are the exception, because a third party sits outside your own domains, so its findings go beside the fabric instead of into a cell. Each of those findings still ends as a record, one per vendor system, with the fourth parties behind it written into its deployment home.
Defense in Layers carries a Layer Gap Analysis, and I run it on the AI estate. It asks which layers are under-protected, which are over-protected, and which postures are missing altogether. Discovery answers two of those from findings it already produced.
If no checkpoint stands between your people and the models they call, the network layer is under-protected. If there's no list of approved tools, nothing can say a system is missing from one, and that's a posture missing altogether. Over-protection is a judgment about strength, so it waits for Measure. And a personal account on a personal device sits outside every cell, so it terminates in the inventory, on its line about what discovery can't reach.
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. Map produces both termination points. In every later round of discovery, I read the fabric again and compare it with what I found the time before.
Map at the Scale of One System
If you ship one agentic system, all of this runs much smaller. As Chapter 0 put it, "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."
You're filling in the same record, field for field. The repository and the deployment configuration hand you the models and the versions you've pinned, the tools the agent can call, the data it reaches, and, if your commits mark it, whether AI-generated code lands in your pipeline. The owner is still a named human, never a team. Write the placard, the one sentence that says what this agent is, straight off the record.
Then trace one request through your system, from wherever a user or a trigger starts it, out to the model and back, and mark every control point it crosses. At each one, note whether a guardrail is there and whose it is. The ones sitting in code you can edit or configuration you can change are yours to secure, and for the rest you can only ask the vendor what it enforces. If you host the model yourself, that control point is yours too. Add the build pipeline your system shipped through, which is yours even though no request crosses it.
Chapter 0 also tells anyone who ships one system, "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."
Where the Rest of the Work Starts
Chapter 1 drew the three layers every agentic system has, Chapter 2 put a placard on each agent, and Chapter 3 showed the attack surface moving under the layers and the agents alike. This chapter goes out and finds the systems themselves. When discovery is done, you're holding a list of the AI your company runs, each system with a named owner or an honest "none." The list also carries a line that admits what no source could see.
The inventory is where the rest of the work starts, because every step after it assumes a list of agents exists. No committee meeting ever produced that list. I've watched programs open with a policy and a register and stall there, because nobody could say which systems the policy covered.
Map costs the owning teams their time, a report request and a walkthrough at each source, and it needs one executive with the authority to name owners. It costs no new tooling on a first pass, because that pass runs on instruments those teams already operate. If a source needs an instrument no team has, that gap goes in the read. At the scale of one system, it costs an afternoon. This round of discovery is a first pass, though, and an estate doesn't hold still, so Chapter 22 takes up running it again to keep the inventory current.
This chapter closes Map, the step where you find out what you are actually running. Chapter 5 opens Measure, which reads the posture of everything on the list with two instruments. Every security team already knows the first one. The industry uses the second one's name three different ways, and no standard I've read defines it, so it needs a definition before any domain gets scored.
The list I pulled that December came back with a person's name on every line. Your AI inventory has to come back the same way.