Quantifying Shadow AI Risk With an Asset Inventory Framework

Shadow AI is the normal result of AI spreading through companies faster than any office can track it, and most organizations are already living inside that gap. A Cloud Security Alliance study found that most employees use AI tools their organizations never approved, while few enterprises have any AI governance policy [1][23][12][11][13][22][45]. The same research found that generative AI is now the single largest channel moving data from corporate systems into personal ones, and most enterprise AI use happens where security teams can't see it. Vectra's analysis found that the shadow AI economy, made up of free-tier tools, browser extensions, code assistants, and AI features buried inside other software, now outweighs the AI tools companies actually sanctioned and deployed.

The move toward AI agents makes this worse in a specific way. An unauthorized chatbot exposes whatever an employee types into it. An unauthorized agent authenticates to systems, queries databases, calls outside APIs, and sends emails on its own. The risk shifts from a person leaking data by mistake to a piece of software taking real action on a company's behalf, often with no one watching.

The law has caught up to this. The EU AI Act's high-risk obligations, covering Articles 8 through 17, 26, 27, and 73, take effect December 2, 2027 for standalone Annex III systems, after regulators pushed the date back from the original target of August 2, 2026. Once that date arrives, a company with no clear picture of what AI it runs is in violation of the law, and the penalties reach 3% of global annual revenue. That number is what turns shadow AI from an IT headache into something a board has to answer for.

Why Shadow AI Is Harder to Discover Than Shadow IT

Older governance programs were built to catch unauthorized software through network traffic, approved vendor lists, and data loss prevention tools that watch for files leaving the company. None of that was built for how AI tools actually enter a workplace, and none of it catches most of what's happening now.

AI shows up through at least four doors, and each one skips procurement and skips the network controls built to watch for it. Employees sign into consumer chatbots with personal accounts, so there's no purchase order and no tie to a corporate identity. Software vendors quietly add AI features to tools a company already approved, so a platform cleared last year is now processing records nobody reviewed it to handle. Employees build their own automations, wiring an agent to a spreadsheet and an email inbox with credentials no one scoped or tracked. Browser extensions and plugins read whatever is on the page by design, and when that page is an internal company application, the extension reads company data along with it.

Kiteworks' 2026 analysis points to the real flaw in how older programs think about this: AI doesn't sit still the way a normal application does. It constantly pulls in data, generates new material, stores results, and acts on what it's given, so the instant when someone "accesses" an AI tool tells a security team almost nothing about what happened to sensitive information after that. A single sensitive record can move through a prompt, get rephrased in a response, get pasted into a second tool for formatting, and end up screenshotted into a slide deck. No single step in that chain looks like a data breach, so no data loss prevention rule catches it.

Agents connect to other tools and services through standardized integration protocols, and that makes the problem harder still. As of early 2026, most enterprise AI activity happens outside what security teams can monitor, and unregistered MCP servers process data entirely outside any managed environment, with no authentication and no record of their existence. Most organizations have no way to even detect that category of risk, let alone manage it. Finding these assets can't happen by watching traffic go by. It takes an active, deliberate search, built on a structured inventory process.

AI assets in the agentic era

A working AI asset inventory has to track more than most companies currently bother to count, and the rise of agents means each entry has to capture not just what a tool is, but what it's capable of doing and who it's doing it for.

The baseline list of what belongs in that inventory includes foundation models and large language model integrations, whether a vendor hosts them, a company reaches them through an API, or an employee runs one locally on a laptop. It includes AI features built into software a company already approved, often switched on by the vendor with no IT review or separate sign-off. It includes standalone AI apps and browser extensions, from consumer chat tools to code assistants, writing aids, and translation tools, reached through personal or company accounts. And it includes AI agents and automations, whether employees built them or vendors supplied them, that hold credentials, reach outside systems, and act without a person approving each step.

Agents need a stricter bar than the rest. A complete record for an agent needs three things: an entry in the registry, a named person who owns it, and a managed identity tied to that owner. If any one of those three is missing, the agent counts as a shadow agent and gets flagged as a critical finding by definition. The Cloud Security Alliance's research found that most organizations have already seen AI agents exceed the permissions they were given [1][23][12][11][13][22][45]. That permissions gap is already causing incidents inside companies today.

How to surface AI assets that were never declared

AI doesn't come through a purchase order, so you have to combine several signals at once, because passive monitoring alone misses too much.

Akamai's 2026 Enterprise AI Usage Risk Report found that a small group of heavy users drives a disproportionate share of shadow AI adoption inside a company. If you start discovery with those high-volume users, you turn up the most risk the fastest, giving you a practical place to start. Combining that signal with network and SaaS audit data builds a fuller picture than any single source could on its own.

What comes out of this phase is a raw asset register: every AI system, every agent, every tool, and every MCP connection found, whether or not anyone approved it. That register is a list, not yet a risk assessment. The next job is turning it into one.

Dimensions to record for each asset to support risk scoring

A list of assets that can feed a risk calculation is a governance tool. What turns a raw register into something useful is the set of fields recorded for each entry, because those fields decide whether a company can actually quantify its risk or just describe it.

Every asset record needs an identity: its name, its type (model, tool, agent, MCP server, or embedded feature), who made or supplies it, and its version or the date it was deployed. It needs a sanction status, marked approved, unapproved, or under review, along with the date and scope of approval if it has one, or the date it was first detected if it doesn't. It needs an owner: a named person and team, and for agents specifically, a note on whether a managed identity exists and what that identity is scoped to do. It needs a record of data access scope, covering what kinds of data the asset can reach or has already touched, whether that's personal information, financial records, source code, customer data, or categories regulated under the EU AI Act's high-risk rules, since this field is what drives how an asset gets classified under that law. It needs a record of action capability, distinguishing a tool that only reads information from one that can write, execute commands, hold credentials, or call other tools on its own, since that's the line between a passive tool and an agent that can move laterally through other systems. It needs a record of authentication and credential posture: whether the asset logs in through managed corporate identity systems, through a personal account, or through no authentication at all, whether its credentials are scoped narrowly or left wide open, and whether each call it makes leaves an audit trail. It needs a connectivity record: which MCP servers or outside APIs the asset talks to, and whether those connections are registered and encrypted. And it needs an incident history: any past case of the asset behaving oddly, exceeding its permissions, or breaking policy.

The authentication and identity fields carry particular weight. Akamai's 2026 analysis found that nearly half of all enterprise AI activity runs through identity that no one manages, so a company can require corporate logins and still have no real control over what's happening. The inventory has to capture the actual identity posture of each asset, not just whether it appears on an approved list. For assets connected through MCP, the same logic applies with sharper teeth: agents should never hold raw credentials for the services they call. The inventory field should state whether an asset holds a scoped OAuth token to invoke a tool, or whether it holds the underlying service credential outright, and the latter is a critical finding no matter what the asset's sanction status says.

The EU AI Act's Article 12 requires logging "over the lifetime of the system," so the inventory also has to record what logging infrastructure sits behind each asset. A logging setup that resets every time an asset gets redeployed doesn't meet that bar, and the inventory record should flag it when it doesn't. Finally, the U.S. Treasury Department's GV-1.6 control objective calls for inventories that stay current rather than freezing at a single point in time, so every record needs a last-verified date and a review schedule. That way, an entry going stale becomes something the system itself can score and flag.

How inventory data converts into defensible risk scores

A risk score is only as solid as the inventory feeding it. Once a company has the right fields recorded, turning that data into a score means combining two axes: how likely an incident is, and how bad it would be if one happened.

Likelihood draws on an asset's exposure posture, pulling from its sanction status, its authentication posture, whether its credentials are scoped or raw, whether it connects to unauthenticated MCP servers, whether an audit trail exists, and its incident history. Impact draws on what the asset can reach and what it can do: the sensitivity of the data it touches, whether it only reads information or can write, execute, and hold credentials, which regulatory category it falls under (EU AI Act high-risk status, HIPAA, financial services rules), and whether it has a named owner at all, since an asset with no owner has no clear path to containment if something goes wrong.

Some combinations of these fields produce critical findings on their own, without needing a judgment call from an analyst. An agent with no registry entry, no owner, and no managed identity is a shadow agent, rated critical. If an agent holds a raw downstream credential instead of a scoped OAuth token, you rate it critical no matter whether it was ever sanctioned. An MCP server connection with no client authentication and no encryption on its traffic is rated critical, and this case is common rather than rare: only 8.5% of MCP servers use OAuth, so unauthenticated connections are the norm across exposed infrastructure, not the exception. If an asset falls under the EU AI Act's high-risk categories but has no logging infrastructure able to survive a redeployment, you count it as a regulatory violation and rate it critical. And a record whose last-verified date has passed its review cadence gets flagged as stale and routed back for re-discovery.

Once scored, these findings roll up into the metrics that boards and regulators actually want to see: the share of discovered assets that were never sanctioned, the share of agentic assets with a managed identity versus those without one, the share of high-sensitivity assets with no audit trail, and the gap between what discovery efforts find and what the approved register actually contains. OWASP's LLM Top 10 names this kind of risk directly under LLM03: Excessive Agency, covering over-functionality, over-permissions, and over-autonomy, and that classification maps straight onto the action-capability and permission-scope fields already in the inventory. If a company scores against a named, publicly recognized category like that, it gets a risk score it can defend to an outside auditor, not just one it generated internally. The NIST AI RMF, the ISO 42001 standard, and the EU AI Act all call for transparency and traceability, though each does it differently: NIST's framework is voluntary guidance, ISO 42001 works through management system controls, and the EU AI Act's obligations apply specifically to high-risk systems and in broader terms than a record of every single action. The inventory's audit-trail field is what a company points to when it has to show it meets these standards. Without that field, the score is just an estimate, not something a company can stand behind in front of a regulator or a board.

Why the inventory must be continuous

An AI asset inventory taken once and left alone goes stale faster than any other IT record a company keeps, because the ground it's standing on keeps shifting faster than any technology category that came before it.

The sheer number of tools in play makes this unavoidable. Analysts have identified hundreds of distinct generative AI tools running across enterprise environments in a single pass, and new ones keep arriving between audit cycles, not waiting for the next scheduled review. Vendors add AI features to approved software on their own update schedules, separate from a company's review calendar, so a platform cleared three months ago may now run an AI capability no one at the company has ever seen.

The EU AI Act's Article 12 logging requirement, which covers a system "over the lifetime" of its use, carries real weight here: the logging infrastructure behind an asset has to survive model updates, redeployments, and moves to new infrastructure, and a system that resets its logs on redeploy fails that requirement. The same logic applies to the inventory record itself, which has to survive those same changes rather than getting reset or forgotten along with them. The gap in MCP authentication is just as restless: the official MCP registry keeps growing, new servers appear on the public internet in the space between scans, and a server's authentication setup can change without warning. A static inventory, checked once a quarter or once a year, cannot keep pace with that.

Keeping an inventory current in practice means a few things working together: automatically tracking agent identities as they change inside a company's directory systems, watching MCP connections down to the level of individual tool calls, catching alerts when a vendor ships a new AI feature into existing software, and giving employees a clear channel to report a new AI tool the moment they start using one, which then triggers a fresh round of discovery. The companies closing this gap fastest built their inventory into how their systems run from the start, tying identity to every action as it happens, rather than trying to reconstruct what occurred from logs after the fact.