Category · AI capability governance
AI Capability Inventory: Knowing What AI Can Actually Do Inside Your Company
You can list your models and your servers. Neither answers the question a board actually asks: what is AI able to do here, and who decided it could?
The short answer
An AI capability inventory records what AI systems in your organisation are able to do in business terms — issue a refund, modify a customer record, provision infrastructure, send external email — rather than which tools or servers exist. Each capability carries its consequence class, the systems it touches, who authorised it, which agents hold it, and what happens when it is exercised wrongly. The difference from a tool inventory is the difference between a parts list and a description of what the machine does.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸A capability is what AI can cause to happen in the business. A tool is one implementation of it. Three tools offering refunds are one capability with three implementations.
- ▸Capability is the right unit for governance because it is the unit the business understands, the unit consequence attaches to, and the unit that survives re-platforming.
- ▸Eight fields per capability: name, business description, consequence class, systems touched, data classes, holders, authorising decision, and reversal path.
- ▸The reversal-path field is the one that changes conversations. A capability with no documented way to undo it is a capability that should require approval, and most inventories have never asked.
- ▸Discovery combines the registry, agent configuration, actual traffic and business-process interviews. Only the last finds capabilities exercised through paths nobody registered.
Source: Mark Alex, Real Biz Digital — AI Capability Inventory: Knowing What AI Can Actually Do Inside Your Company (https://realbizdigital.net/insights/ai-capability-inventory/). Reproduce with attribution.
Key takeaways
- 01Name capabilities in business language. If a risk committee cannot understand the name, the inventory will not be used by the people it exists for.
- 02Classify by consequence and reversibility, not by technical risk. “Irreversible and externally visible” is a more useful class than “write operation”.
- 03Record who authorised each capability. Most inventories can say a capability exists; very few can say who decided it should.
- 04Document the reversal path or accept that there is none. That single field justifies the whole exercise.
- 05Reconcile the inventory against observed traffic monthly. Declared capability and exercised capability always differ, and the gap is where the interesting findings are.
- 06Keep it operational: if policy reads consequence class per call, a wrong class shows up as a wrong decision within days rather than at the next audit.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is an AI capability inventory?
- A record of what AI systems in your organisation can cause to happen in business terms, with consequence class, systems touched, holders, authorising decision and reversal path for each capability.
- How is a capability different from a tool?
- A capability is an effect in the business — issue a refund. A tool is one implementation of it. Several tools across several servers frequently provide the same capability.
- Why not just inventory the tools?
- Because tools change while capabilities persist, consequence attaches to capability rather than implementation, and a tool list cannot be read by the people who must approve the risk.
- What should each capability record contain?
- Eight fields: name, business description, consequence class, systems touched, data classes, current holders, authorising decision, and reversal path.
- How do I discover capabilities?
- Four methods: registry and tool schemas, agent configuration and prompts, observed traffic, and interviews with business-process owners. Only the last finds capability exercised through unregistered paths.
- What is the most valuable single field?
- The reversal path. A capability with no documented way to undo it should require human approval, and most organisations have never systematically asked the question.
- Who should own the capability inventory?
- Enterprise architecture or the platform team maintains it; risk and business owners approve consequence classifications and authorisations.
Capability is not tool, and the difference is the whole point
Every organisation that starts here begins by listing tools, and every one of them discovers the list cannot answer the questions being asked of it.
Both are necessary. Only one of them can be read aloud in a risk committee. And only one survives the re-platforming that will happen within eighteen months, because capabilities are stable while implementations are not.
The mapping is many-to-many and that is precisely why the distinction matters. One capability — issue a customer refund — might be provided by a payments server, a CRM server with a billing integration, and a general-purpose HTTP tool pointed at an internal API. Governing the three tools separately, with three different policies and three risk assessments, is how estates end up with one capability governed three inconsistent ways.
- ›Which servers exist
- ›Which tools each exposes
- ›What their schemas are
- ›Which credentials they use
- ›Which are unowned or unused
- ›What AI can cause to happen in the business
- ›Which of those effects are irreversible
- ›Who authorised each one
- ›Which agents currently hold it
- ›What the reversal path is, if any
payments.refund on the payments server — idempotent, ceiling enforcedbilling.credit_note on the finance server — different ledger effect, no ceilingcrm.case.resolve with a refund flag — triggers a refund as a side effecthttp.request pointed at the internal refunds API — no policy could see it as a refund at allImplementations two and three were not classified as payment operations by anybody, because nobody looking at tool names would call them that. Implementation four was invisible to policy entirely, since a generic HTTP tool carries no semantics.
That pattern — a governed primary path and two or three unrecognised side doors — is the single most common finding when organisations first inventory capability rather than tools.
The eight-field capability record
Key facts
- ▸The holders field is the most volatile and the most revealing. Reconcile it against observed traffic monthly; declared holders and actual callers diverge quickly.
- ▸The authorising decision field converts the inventory from a technical artefact into a governance record. Without it you can say a capability exists but not that anyone chose it.
- ▸If the reversal path field says “none” or “unknown”, that capability belongs in the approval-required set by default. Treat blank as unknown, not as fine.
| Field | Example | Why it exists |
|---|---|---|
| Capability name | Issue a customer refund | The unit a risk committee can discuss and approve |
| Business description | Return funds to a customer’s original payment method, reducing recognised revenue | Removes ambiguity about what is actually being permitted |
| Consequence class | C4 — financial, externally visible, partially reversible | Drives policy selection, approval requirements and monitoring |
| Systems touched | Payment processor, general ledger, CRM case record | Blast radius, and which teams must be consulted on changes |
| Data classes | Customer identity, payment instrument reference, transaction amount | Retention routing, privacy obligations and step-up requirements |
| Current holders | support-triage agent (ceiling £500), finance-recon agent (no ceiling) | Who can actually do this today, which is rarely what people assume |
| Authorising decision | Approved 2026-03-11, finance director, decision log #241 | The field auditors ask for and inventories almost never contain |
| Reversal path | Reverse-refund within 30 days by finance ops; not reversible after settlement | Determines whether pre-execution approval is necessary |
Eight fields is deliberately few. Inventories with thirty fields per record are abandoned within two quarters because nobody can maintain them, and an abandoned inventory is worse than none because it is trusted while being wrong.
Five consequence classes that actually change decisions
Classify on consequence and reversibility rather than on technical operation type. “Write” and “read” do not distinguish updating a display preference from wiring money.
| Class | Default policy posture | Approval | Monitoring |
|---|---|---|---|
| C1 | Allow, with sampling | None | Aggregate counts only |
| C2 | Allow with argument validation | None below thresholds | Per-call record |
| C3 | Allow with rate ceilings and content guardrails | Above volume threshold | Per-call record, daily review |
| C4 | Allow within ceilings; approval above | Business approver in domain | Per-call record, real-time alerting |
| C5 | Deny by default; approval always | Two approvers, one from the owning team | Per-call record, real-time alerting, post-hoc review |
The value of five classes rather than three is that C3 exists. Externally visible but non-financial actions — a message to a customer, a status update on a public ticket — are the ones organisations consistently under-govern, because they are neither money nor deletion and therefore fall between the usual categories.
Four discovery methods, and the one that finds the surprises
Key facts
- ▸Method four is the one that finds capability nobody registered, because it starts from business effect rather than from infrastructure. It is also the one teams skip because it requires calendars rather than queries.
- ▸The alarm list from method four is disproportionately useful: what a process owner would be alarmed to discover is, almost by definition, the capability that needs an authorising decision.
- ▸Reconciling methods one and three is the fastest route to a first finding. Declared capability and exercised capability differ in every estate we have examined.
Registry and tool schemas
Start with the registry: every tool, its schema, its declared effect. Cheap and incomplete, because tool names frequently describe implementation rather than effect and generic tools describe nothing at all.
Yield: the primary implementations of well-behaved capabilities. Blind spot: side effects and generic escape-hatch tools.
Agent configuration and prompts
Read what each agent is actually instructed to do, and which tools it is given. This is where you find that an agent has been granted a capability nobody remembers approving.
Yield: current holders, and capability grants that predate governance. Blind spot: what the agent does in practice versus what its prompt says.
Observed traffic
Ninety days of actual tool calls, grouped by effect rather than by tool. Reveals which capabilities are genuinely exercised, by whom and how often.
Yield: the gap between declared and actual. Blind spot: capabilities exercised rarely, including the dangerous ones exercised once a quarter.
Business-process interviews
Ask process owners what they believe AI is doing in their area, and what they would be alarmed to learn it could do. Slowest method, highest yield of surprises.
Yield: capabilities exercised through unregistered paths, plus the alarm list — which is effectively a pre-written policy backlog.
Run all four for the first inventory, then keep methods one and three continuous and repeat method four annually. Method two belongs in the agent-onboarding process rather than in a periodic sweep.
Four executive questions only this inventory answers
The inventory earns its maintenance cost by answering questions that a tool list demonstrably cannot. These four come up in almost every board or audit conversation.
- “What can AI do in this company today?”
- Answered by capability names and consequence classes, in business language. A tool list answers a different question and produces visible frustration when offered as a substitute.
- “Who decided it could do that?”
- Answered by the authorising decision field. This is the question that most frequently has no answer, and its absence is a finding in its own right.
- “What is the worst thing that could happen?”
- Answered by the C5 set plus reversal paths. A defensible answer is: these eleven capabilities are irreversible, here is who authorised each, here is the approval control on each.
- “If we switched off all AI tomorrow, what would stop?”
- Answered by capability holders crossed with observed traffic. Also the honest measure of dependency, which is usually higher than leadership expects and lower than vendors claim.
Notice that all four are questions about capability and authority, not about technology. That is the argument for maintaining this artefact separately from the technical registry, even though the two share data.
Keeping it true: making the inventory operational
Every inventory decays. The only reliable defence is to make it load-bearing, so that inaccuracy produces a visible operational symptom rather than a quiet divergence.
- 01Policy reads consequence class per call. A misclassified capability then produces a wrong decision within days, which someone reports. Documentation-only classification decays invisibly for quarters.
- 02Capability grants flow through the inventory. Granting an agent a capability updates the holders field as a side effect of the grant, rather than as a documentation task afterwards.
- 03Monthly reconciliation against traffic. Automated: compare observed effects against declared holders and flag differences. This is where you catch a capability spreading beyond its authorisation.
- 04Consequence class review on schema change. A tool gaining a parameter can change its class — adding a
forceflag can move a C2 to a C5 — so schema change should trigger reassessment automatically. - 05Annual re-interview of process owners. The only method that finds newly created side doors, and the only one that keeps the business language current.
- 06Retire capabilities explicitly. When the last holder loses a capability, mark it retired with a date rather than deleting the record. Retired-with-history is auditable; deleted is not.
A capability inventory that policy actually consults is worth an order of magnitude more than one maintained as documentation, and it costs less to keep accurate, because the estate itself tells you when it is wrong.
Next step
Inventory capability, then make policy read it
Barzel Central Gateway holds the capability graph, the risk classification and the per-call policy that consumes them — which is what keeps a capability inventory accurate instead of decorative.
Honest limits of a capability inventory
This is a governance artefact, not a control. Three limits.
- 01It records what is possible, not what will happen. A complete inventory beside no enforcement is a well-documented risk, which is better than an undocumented one and considerably worse than a governed one.
- 02Capability boundaries are judgement calls. Is “send external email” one capability or three? There is no correct answer, only a consistent one — so write the convention down and apply it, because inconsistency here undermines every classification built on top.
- 03It cannot see capability provided outside your estate. An agent using a browser or a generic HTTP tool can reach effects no inventory anticipated, which is why restricting generic tools matters more than cataloguing specific ones.
Frequently asked questions
What is an AI capability inventory?
A record of what AI systems in an organisation are able to cause to happen, expressed in business terms — issue a refund, modify a customer record, provision infrastructure — with consequence class, systems touched, data classes, current holders, authorising decision and reversal path for each entry.
How is an AI capability different from an AI tool?
A capability is an effect in the business; a tool is one implementation of that effect. A single capability such as issuing a refund is frequently provided by several tools across several servers, sometimes including a generic HTTP tool that carries no semantics at all.
Why is a tool inventory not enough?
Because tools change while capabilities persist, because consequence and authorisation attach to capability rather than implementation, and because a tool list cannot be read by the risk committee that has to approve the exposure. The most common finding on first inventory is a governed primary path alongside two or three unrecognised side doors.
What fields should a capability record contain?
Eight: capability name, business description, consequence class, systems touched, data classes involved, current holders, the authorising decision with date and decision-maker, and the reversal path. Records with thirty fields are abandoned within two quarters.
What is the most important field in a capability record?
The reversal path. A capability with no documented way to undo it should require human approval by default, and most organisations have never systematically asked the question for each capability they have granted.
How do I discover what AI can do in my company?
Four methods: read the registry and tool schemas, read agent configurations and prompts, group ninety days of observed traffic by effect, and interview business-process owners about what they believe AI does and what would alarm them. Only the last finds capability exercised through unregistered paths.
How should AI capabilities be classified?
By consequence and reversibility rather than by operation type, using five classes: internal read, reversible internal write, externally visible, financial or contractual, and irreversible or systemic. Five classes rather than three matters because externally visible non-financial actions are consistently under-governed.
Who should own the AI capability inventory?
Enterprise architecture or the platform team maintains it. Risk and business owners approve consequence classifications and authorisations, since those are business judgements rather than technical ones.
How do I stop the inventory from going stale?
Make it load-bearing. If policy reads consequence class on every call, a misclassification produces a wrong decision within days. Reconcile declared holders against observed traffic monthly, reassess class on schema change, and re-interview process owners annually.
What questions does a capability inventory answer that nothing else does?
What AI can do here today, who decided it could, what the worst realistic outcome is, and what would stop if AI were switched off tomorrow. All four are questions about capability and authority rather than about technology.
How does a capability inventory relate to a capability graph?
The inventory is the authoritative list of capabilities with their governance attributes; the graph adds the relationships — which agents hold which capabilities, which servers implement them, and which business processes depend on them. The inventory is the prerequisite.
Can a schema change alter a capability’s consequence class?
Yes, and this is a routinely missed trigger. Adding a single parameter such as a force or cascade flag can move a reversible internal write into the irreversible class, which is why schema change should automatically queue a reassessment rather than waiting for a periodic review.
Glossary
- AI capability
- An effect an AI system can cause in the business, described independently of which tool implements it.
- Consequence class
- A classification of a capability by the severity, external visibility and reversibility of its effect.
- Reversal path
- The documented procedure and time window for undoing an exercised capability, or an explicit statement that none exists.
- Capability holder
- An agent or user currently able to exercise a capability, with any ceilings that apply.
- Authorising decision
- The recorded decision, date and decision-maker who approved a capability’s existence in the estate.
- Side door
- An unrecognised implementation of a governed capability, frequently a side effect or a generic tool.
- Alarm list
- Capabilities a business-process owner would be alarmed to learn exist, functioning as a pre-written policy backlog.
- Declared versus exercised
- The gap between capability recorded as granted and capability observed in traffic.
- Capability retirement
- Marking a capability as no longer held, with a date, rather than deleting its record.
- Generic escape-hatch tool
- A tool such as raw HTTP, SQL or shell that can provide many capabilities while declaring none.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · Center for Internet SecurityCIS Critical Security Controls ↗Control 1 and 2 — inventory of assets and software — restated here for MCP servers and tools.
- 02 · NISTNIST AI Risk Management Framework ↗Govern-map-measure-manage; the vocabulary most enterprise AI risk programmes are written against.
- 03 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
- 04 · EU AI Act (unofficial consolidated text)EU AI Act — full text ↗Obligations around logging, human oversight and traceability for higher-risk systems.
- 05 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 06 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 07 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 08 · ISACACOBIT 2019 Framework ↗Governance and management objectives, including segregation of duties.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). AI Capability Inventory: Knowing What AI Can Actually Do Inside Your Company. Real Biz Digital. https://realbizdigital.net/insights/ai-capability-inventory/
Try the mechanics on a live server
To watch a real tools/list response, and see how much surface one server exposes, before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so an evaluation costs an afternoon rather than a purchase order.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Community | Free | 1,000 tool calls/mo · full policy engine, registry, routing, audit | Evaluating the estate, or one team proving the path works |
| Starter | $10/mo | 10,000 calls/mo · everything in Community | One or two production agents against a handful of servers |
| Team | $79/mo | 100,000 calls/mo · routebooks, simulation, change impact | A platform team governing an estate of 5–20 servers |
| Business | $149/mo | 250,000 calls/mo · estate-wide evidence export | Multi-team governance with SIEM obligations |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.