Attack Surface Management for AI Agents: Score the Inventory First

Name every agent that holds a credential in your environment. No asking around, no waiting on the platform team: just name them. Most security functions cannot, and that silence is the finding.

What follows is a scored self-check for attack surface work on agent systems. There are eight questions. Each one is worth nothing, one point, or two, for a total between zero and sixteen. Score only the agents that run in production, and claim the full two points only when you can hand a colleague an artefact: an exported register, a log query, an IAM policy, a config file under version control. If the answer lives in somebody's head, it is worth one point at most.

Eight questions, artefacts only

Score each row before you read the bands. Every question below is answerable from something you can export, open or query.

#	What to ask	0 points	1 point	2 points, with an artefact
1	Is there a register naming every autonomous process that acts for the business, including agents shipped inside purchased SaaS and agents living in engineering tooling?	No register, or one assembled from recollection	Covers only what your own platform team shipped	A per-agent record exported from a system of record, carrying a last-reviewed date
2	Does each record name an accountable team and a route that reaches a human out of hours?	No owner recorded	Named individuals, no team and no rota	Team plus an on-call route, both resolvable in your paging tool
3	Is every channel of text that reaches the agent enumerated and labelled trusted, semi-trusted or hostile?	No input list anywhere	Listed for a handful of agents	A per-agent input table, with public forms, inbound mail and scraped pages marked hostile
4	Does each record list the tool set, the credential presented by each tool, and the records the agent can alter or export?	Nothing recorded	Tool names only, credentials unmapped	Tools, credentials and write reach recorded against the live config
5	Is there a written ordering rule that combines reach for hostile text with the power to change or move data?	No ordering at all	An informal sense of which agents matter	A dated ranked list, with the top entries queued for review first
6	Do you hunt for agents nobody registered: fresh consent grants to AI vendors, agent frameworks appearing in lockfiles, server entries in developer config, traffic to model endpoints from unexpected hosts?	No hunting	One sweep, run once, never repeated	A scheduled sweep with a named signal source per check and a queue of findings
7	At the top of the ranking, have unused tools been withdrawn and shared credentials split so reads and writes present different identities?	One broad key and the full tool set, unchanged	Done for a few agents	Done for every top-ranked agent, visible as a diff in config and in the secret store
8	Does the register refresh on events, meaning a new agent, a new tool, a model swap or a new data source, as well as on a calendar, with a rule for records whose owner has left?	Never refreshed	Refreshed when somebody remembers	Event triggers and a scheduled review both documented, plus an orphan rule

Reading the total

• Zero to five, unlit. There are almost certainly agents in your estate that no team claims. Any product you buy at this point will defend a system you have not listed.
• Six to eleven, drifting. The agents your platform team built are known and the rest are not. Questions six and eight are where this band usually loses its points.
• Twelve to sixteen, held. The register survives change. The remaining work is reducing reach and rehearsing a response, not writing more rows.

These cut points are our own working heuristic. No standards body publishes a pass mark for agent inventory, and reading sixteen as a certificate would be a mistake.

Where to start, band by band

Unlit: build the register

1. Ask every engineering and operations team one question in plain language: what acts on our behalf without a person approving each step? Record each answer as given, including the ones that sound trivial.
2. Open one record per answer. Purpose, owner, model and provider, where it runs, which credential it carries, and the date it last changed. A spreadsheet beats nothing, provided it is exported from somewhere and dated.
3. Pull out the agents that read anything a stranger can write and can also change data. Those are your first review targets.

Drifting: add discovery and an ordering rule

1. Schedule the hunt from question six. Consent grants in the identity provider, package manifests, developer config files and egress logs each surface a different class of unregistered agent. Our walk-through of shadow agents and what posture tooling can actually see takes the signals one at a time.
2. Commit the ordering rule to writing and date it, so the ranking can be challenged on its logic rather than defended from memory.
3. Separate credentials at the top of the ranking: a read identity, a write identity, and an expiry on both. Most of that work lands in the lifecycle of a non-human identity, not in the agent code.

Held: shrink reach, then rehearse

1. Trim egress for the high-ranked agents to the destinations they genuinely use. Removing a path beats detecting traffic on it.
2. Aim the alerting at what remains. The guide to what to log and what to alert on sets out which signals repay their storage cost.
3. Test freshness instead of asserting it. Stand up a disposable agent in a low-stakes corner and measure how long the register takes to notice it.

The source behind each question

The NIST glossary entry for attack surface, drawn from SP 800-53 Rev. 5, describes the points on a system boundary "where an attacker can try to enter, cause an effect on, or extract data from, that system, component, or environment" (NIST CSRC Glossary, attack surface). Questions one and three come straight out of that phrasing. An agent's boundary is not a list of hosts and ports. It is the set of places where text and tool results arrive.

Anthropic's engineering team explains why that boundary cannot be read off the code path. Agents suit "open-ended problems where it's difficult or impossible to predict the required number of steps" (Building effective agents). If the sequence is unpredictable by design, then the thing worth cataloguing is the input, not the itinerary. That is the reasoning behind asking for an input table per agent rather than a flow diagram.

Questions four, five and seven trace to the OWASP entry for Excessive Agency, which defines the vulnerability as one "that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" and attributes it to excessive functionality, excessive permissions or excessive autonomy (OWASP LLM06:2025). A reach column tells you which of the three you are carrying for a given agent. Question seven is the only row on the list that asks you to change something rather than write something down.

Questions two, six and eight have no standard behind them. They are editorial judgment, and they are also the three that fail first. A register with no accountable team rots within weeks. With no hunt, it only ever holds what somebody filed a ticket for. With no refresh rule, it describes the estate as it stood on the day it was written. For the hosts, domains and services outside the agent estate, the older method for mapping an attack surface still applies unchanged.

The ordering rule earns its keep on a concrete case. Consider an invoice-matching agent: it reads supplier mail, queries the ledger, and can assemble a payment run through a single service account. Hostile text reaches a component that can move funds, so it sits at the top of the ranking. Split the service account, enforce the payment ceiling in the API rather than in the prompt, and route anything above the ceiling to a named approver. None of those three fixes depends on the model resisting a crafted instruction, which is precisely why they are worth doing first.

Two Published Lists That Give the Register Its Columns

The register above has a field problem, invisible until somebody asks you to map it onto a control set. Two published documents fix it cheaply.

NIST's Control Overlays for Securing AI Systems project is building overlays that apply the SP 800-53 catalogue to specific AI use cases, and the five it names include single-agent systems and multi-agent systems as separate cases, alongside generative AI assistants, predictive AI and controls for AI developers. The concept paper is dated 14 August 2025 and an annotated outline for the predictive AI overlay followed on 8 January 2026, with feedback requested by 13 February 2026. The overlays are planned as interagency reports rather than a revision to the catalogue, and no initial public draft had appeared when this was written. The practical consequence for question one: add a use-case field to every record now and populate it from that list of five. When a draft lands, applying it becomes a filter on your register rather than a re-survey of your estate.

The second is a risk vocabulary for the ordering rule in question five. The OWASP GenAI Security Project published the Top 10 for Agentic Applications for 2026 on 9 December 2025, aimed at the risks that arise from autonomy, delegation, memory and multi-agent coordination, with the numbered categories inside the downloadable document. Tag each top-ranked agent with the categories you believe apply to it. A ranking defended with a published category identifier survives a challenge from someone who did not write it, which an internal severity word does not.

Question Six Has a Signal Problem Worth Knowing About

The hunt in question six leans on developer configuration files, and that signal is weaker than it looks. Claude Code's security documentation states plainly that reviewing a project's checked-in server file does not reveal every server a session can load, because servers configured at other scopes, connectors and plugins all add their own from outside the repository. The same page describes managed configuration that restricts which servers an organisation permits at all.

Read that as a correction to the sweep. Scanning repositories for configuration entries will under-report, and the under-reporting is silent, which is the worst kind. Pair the file scan with a signal the agent cannot opt out of: egress to model and tool endpoints, consent grants in the identity provider, and the organisation-level configuration itself, which is the only place that knows the complete permitted set. Where a platform offers managed configuration, the register should cite it as the authority for question six rather than quoting a repository.

Buy the Discovery, Build the Register

Most teams get this backwards, and it is an expensive inversion. They write discovery scripts themselves, because scanning files and querying an identity provider looks like a weekend of work, and then they go shopping for somewhere to keep the register, because a table with owners in it looks like a product problem. Both halves are the wrong way round.

Discovery is the part that is provably incomplete when hand-rolled, and the paragraph above is the evidence: the first signal most people reach for cannot see servers added from outside the repository, and a scanner nobody maintains decays into a cron job grepping for last year's filename. That work wants somebody else's maintenance budget. The register, by contrast, is a dated table with an owner column, a use-case field and a last-reviewed date. No vendor can own it, because the thing that makes it valuable is a human being prepared to be named in the owner column, and that cannot be installed.

So spend money on seeing the estate, and spend engineering time on the rows, the ownership and the refresh rule. Teams that invert it end up with a licensed inventory product holding a confident, stale list, which is worse than a spreadsheet nobody trusts, because the spreadsheet still gets questioned.

A smaller estate changes the answer: if your whole estate is one platform team with a handful of agents on a single stack, a dated table plus the event triggers in question eight beats any purchase, and the discovery problem is small enough to solve with a query. The logic runs the other way once agents start arriving inside purchased software, where you are no longer discovering your own work.

The limits of a sixteen-point total

A high total means you know what you own and who answers for it. It does not mean those agents are safe. Nothing in this check exercises a control, measures whether a model holds up under a crafted instruction, or proves the register is complete, because completeness is the one property you cannot verify from inside the register. Read the total as a readiness signal and never as an audit result, and put production risk decisions in front of a qualified security professional before launch.

The useful output is the shape of the gap rather than the number. Low scores are usually an ownership problem wearing a tooling costume. High scores usually mean the next unit of risk reduction is sitting in reach, not in detection.