OWASP Just Shipped the Agent Inventory Your Auditor Will Ask For

The OWASP GenAI Security Project put out a large release on 1 September 2026, and the coverage mostly landed on the wrong half of it. The headline was the 2026 Top 10 for LLM Applications, which passed ten thousand downloads inside forty eight hours and now carries expanded mappings out to NIST, MITRE ATLAS, CWE and the companion Top 10 for Agentic Applications. Alongside it came an expanded AI Security Solutions Directory, a GenAI Security Industry Framework Crosswalk, and a community that has crossed thirty thousand members. Buried under the list refresh was the debut of something newer and less familiar: the Agent Control Standard, donated to the project and published at version 0.1. The Top 10 is a ranking. The Agent Control Standard is a specification, and specifications are the things that end up in procurement questionnaires eighteen months later.

The ranking is still worth reading, because what moved says something about where incidents are actually happening. Prompt injection and sensitive information disclosure held first and second. Excessive agency made the largest jump on the list, from sixth to third. Misinformation moved from ninth to seventh. System prompt leakage was retired outright and replaced at eighth by hidden context exposure, a broader category that covers retrieved documents, agent memory, tool responses and application state rather than just the instructions you wrote at the top. The methodology changed too: for the first time the ranking weighted 6,639 real world incidents at twenty five per cent against seventy five per cent expert consensus, rather than resting on expert consensus alone. Read those three changes together and the story is consistent. The risk has moved off the model and onto the plumbing around it, which is where most organisations have the least visibility.

The Agent Control Standard addresses that plumbing directly, and it is structured differently from the guidance documents that preceded it. It describes an agent control system in which observed agents interact with guardian agent enforcement points that apply policy at runtime, an observability layer that emits event traces through OpenTelemetry and the Open Cybersecurity Schema Framework, and an Agent Bill of Materials, or AgBOM, that exposes the tools, models and reachable data of an agent in CycloneDX, SWID and SPDX formats. Underneath sit three stated properties an agent is meant to have: inspectable, traceable and instrumentable. In plain terms, you should be able to constrain what an agent may do before it runs, and reconstruct what it actually did afterwards. Existing agentic guidance covered risks, controls, identity, governance and testing. This is the first piece that tries to specify enforcement while the thing is running.

The AgBOM is the part compliance teams should care about, because it is the first credible answer to a question everyone has been fudging. Every framework now asks for an AI inventory. ISO 42001 wants systems recorded with their purpose, owner and approvals. ISO 27001 asks the same question through asset management and supplier management. SOC 2 asks whether changes to that population are governed and evidenced. What almost nobody has been able to produce is an inventory that describes what an agent can reach rather than merely that it exists. A spreadsheet row saying "customer support agent, owned by operations, approved March" tells an assessor nothing about whether that agent can call a payments endpoint. An AgBOM expressed in CycloneDX does, and it does so in a format your existing software supply chain tooling already parses. That is the same trick SBOMs pulled, and it worked because a machine readable list can be diffed. An inventory you can diff is an inventory that catches the week somebody quietly added a new tool to a running agent.

It also lands squarely on the problem we wrote about earlier this week, which is that agent actions arrive in your systems of record wearing somebody else identity. A manifest of reachable tools is only useful if the credential the agent presents is distinct, scoped and short lived per agent and per workflow. Give six agents one shared service account and the AgBOM tells you what each of them could touch while your audit log insists they were all the same actor. The same caveat applies to the third party surface. We have argued that an MCP server is a vendor and belongs in third party risk review, and an AgBOM is a reasonable place to make that concrete, because the tools an agent can call are precisely the list of external code paths it can trigger. The standard does not solve identity or vendor review for you. It gives you a structured place to record the answers, which is more than a policy document does.

The limits deserve stating plainly, because the gap between a published specification and something you can rely on is where a lot of compliance budget goes to die. The Agent Control Standard is version 0.1, with implementation samples and richer enforcement actions flagged for later releases. There is no certification against it, no accredited assessor, and no regulator that recognises it, so conformance buys you no presumption of anything. That should sound familiar: we made the same point about EN 18286 stalling, which left ISO 42001 certificate holders without the presumption of conformity many of them assumed they were buying. The guardian agent concept carries its own risk too, since an enforcement point that sits between an agent and its tools is a privileged component with a view of everything, and the 2026 list itself now ranks excessive agency third. Adopting the vocabulary now is cheap. Building your control design on a version 0.1 specification with no tooling behind it is not.

The compliance automation platforms will meet this halfway, and it is worth knowing which half. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof have all shipped AI governance modules, and each of them will happily hold an agent inventory, drive an access review against it and collect evidence on a schedule once somebody configures it. What none of them will do is discover an agent that was never registered, and unregistered agents are going to be the dominant failure mode in this category for the next two years. The population is easy to describe and hard to enumerate: an internal tool assembled in Bolt, v0 or Lovable that quietly acquired a tool call, a support flow wired to ChatGPT or Claude by a team that did not think of it as a system, a service scaffolded by Cursor or Devin with a handful of integrations attached, a booking front end running ElevenLabs voices that reaches into a calendar and a payment provider. None of those arrived through a process that would have produced an AgBOM, and every one of them is an agent by the definition the standard uses.

The work this week is small and mostly clerical, which is the best kind. Take the agent inventory you already have, if you have one, and add a column for reachable tools, models and data sources, because that column is the AgBOM in prose and it is the field that will be hardest to backfill later. Pick one production agent and try to answer the three properties honestly: could you constrain it before it ran, can you trace what it did afterwards, and is anything actually instrumented, or does the evidence stop at an application log written for humans. Check whether your observability stack already emits OpenTelemetry, because if it does, the tracing half of this standard is a configuration exercise rather than a project. Re read the 2026 Top 10 with the reordering in mind and ask specifically where excessive agency and hidden context exposure apply to what you are running now, rather than treating the list as background reading. And write the version number down next to any commitment you make, because the difference between adopting the vocabulary of a version 0.1 specification and promising a customer you conform to it is a distinction that will matter when somebody asks you to prove it.