Approved inventories only reflect tools that went through formal intake, so they miss anything adopted informally or built outside central review. That leaves blind spots around consumer AI accounts, browser extensions, business-built copilots, and local MCP servers. In practice, the inventory looks complete while actual usage keeps expanding beyond it.
Why approved inventories fail as soon as AI adoption gets informal
An approved inventory is only as complete as the intake process behind it. Once staff can sign up for consumer AI services, add browser extensions, or copy a local copilot into their workflow without going through that process, the inventory stops being a true picture of use. The gap is not just missing entries, it is a false sense of coverage.
That matters because “approved” often becomes a governance label rather than a visibility control. A tool can be absent from the register and still be actively processing prompts, files, and business context. If the organisation only measures what was formally approved, it will miss the operational reality of how AI is actually being used.
Approved inventories also tend to capture products, not behaviours. The same employee may use a sanctioned chatbot one day, a personal account the next, and a workflow embedded in a browser add-on the day after that. The risk is that the inventory looks neat while the real control problem shifts to unmanaged access paths, unmanaged data exposure, and shadow workflows outside review.
What blind spots appear when usage moves beyond central review?
The first blind spot is discovery. Consumer AI accounts and self-installed browser extensions rarely arrive through procurement or security review, so they fall outside the normal lifecycle. Business-built copilots create a second blind spot because they may be internal, but still bypass the same review and documentation path as third-party tools.
The third blind spot is local or lightly governed infrastructure. A local MCP server, for example, can become part of an AI workflow without appearing in a central inventory if teams treat it as a developer convenience rather than an approved service. That kind of shadow expansion is hard to see when the organisation equates “known to procurement” with “known to security.”
Once the inventory is incomplete, downstream controls become less reliable. Data handling rules, prompt logging, access restrictions, and review obligations are all harder to enforce when the organisation cannot reliably tell which tools exist, who uses them, or what data they touch.
For a practical way to close that gap, use an explicit discovery-and-governance approach such as the Shadow AI and AI Agent Discovery Guide, which is built around finding unsanctioned tools through the signals they leave behind rather than trusting the inventory alone.
How do teams shift from “approved list” thinking to actual control?
The right response is to treat the inventory as one input, not the source of truth. Teams need a control model that can see adoption from multiple angles: procurement, browser and endpoint signals, identity and consent artefacts, and usage telemetry. A strong AI Governance Guide matters here because it frames inventory, use case approval, oversight, and decommissioning as connected governance functions rather than one-off approvals.
Approved use should also be defined with enough precision that the organisation can tell when a tool is being used outside its intended bounds. If employees are allowed to use a specific AI service for low-risk drafting, that does not mean they can start feeding it customer data, regulated content, or production credentials. The control objective is not to approve more tools, but to keep usage inside defined boundaries.
Policy also has to be operational, not ceremonial. A useful AI Acceptable Use Policy Template should support decisions about what can be used, what cannot be used, what must be reviewed, and what evidence employees must retain when they use AI in work.
Risk and Threat Considerations
When organisations rely on approved inventories as if they were complete, they create a visibility gap that attackers and careless users can both exploit. The organisation believes it has governed AI usage, but unmanaged accounts, extensions, and local services can still move data outside approved boundaries.
Failure mechanism: Intake-based inventories miss shadow adoption, so the control plane never sees the tools, prompts, or data paths that matter. That leaves gaps in review, monitoring, and restriction enforcement, especially where AI use is embedded in browsers, personal accounts, or locally hosted services.
Impact: Sensitive data can be exposed, unapproved workflows can persist undetected, and governance decisions can be made on an incomplete picture. Over time, the inventory becomes a reporting artefact instead of a control mechanism.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, OWASP ASVS and NIST AI RMF set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | AI tools and extensions must be inventoried beyond formal intake. |
| Recommendation — Track AI software usage from discovery signals, not only procurement approvals. | ||
| NIST CSF 2.0 | ID.AM-01 — Identities and access are inventoried | AI usage blind spots arise when tool and access inventories are incomplete. |
| Recommendation — Reconcile AI inventories with actual usage telemetry and discovery signals. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Approved AI inventories need asset visibility that includes shadow usage paths. |
| Recommendation — Maintain an inventory that reflects real AI assets and usage paths, not only approved entries. | ||
| OWASP ASVS | V13 — Configuration | Unapproved AI extensions and local services are configuration and deployment blind spots. |
| Recommendation — Validate AI-related configuration paths that can bypass central review. | ||
| NIST AI RMF | GV — Govern | AI inventory gaps are a governance failure requiring ongoing oversight and accountability. |
| Recommendation — Govern AI usage as a living control, with continuous oversight and update cycles. | ||
Practitioner Guidance
What to prioritise: Treat discovery as a standing control, not a one-time cleanup exercise. If the organisation cannot detect consumer accounts, browser add-ons, or local AI services, the inventory will drift immediately after it is published.
What to verify: Check whether the inventory is reconciled against actual usage signals, not just procurement records. A good test is whether security can explain why a tool is present, who uses it, and what data it touches.
Common mistake: Teams often assume the approval workflow is the control. In practice, approval only proves a review happened once, not that usage stayed inside the approved boundary afterwards.
Practitioner takeaway: The useful unit of control is not the approved tool list, it is the organisation’s ability to detect and govern real AI usage as it changes.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on surveys or spreadsheets to track AI and MCP usage?
- What breaks when organisations rely only on SSO, CASB, or DLP to govern AI usage?
- What breaks when organisations only track approved SaaS apps and ignore shadow AI usage?
- What breaks when organisations rely on invoices and manual exports to manage AI consumption?