A developer pastes a snippet of production code into a public chatbot to debug it faster. A marketing analyst connects a spreadsheet to an AI browser extension to summarize it. Someone on the sales team wires up a personal AI agent to draft follow-up emails from the CRM. None of this goes through procurement. None of it shows up in an asset inventory. All of it can touch real data.
This is shadow AI, and most organizations that think they have a handle on their AI exposure actually have a handle on the AI tools they approved, which is a different and usually much smaller list.
Why shadow AI is a harder problem than shadow IT
Shadow IT, an employee signing up for an unsanctioned SaaS tool, is a known problem with known controls. Shadow AI is a bigger surface for a few specific reasons.
The entry point is everywhere. An AI capability can arrive as a standalone chatbot, a browser extension, a plugin inside an already-approved tool, an API key pasted into a script, or an autonomous agent someone built over a weekend. Most of these never touch a procurement form.
Agents and MCP servers multiply the surface. Model Context Protocol servers and AI agents are increasingly built and connected ad hoc, often by engineers wiring a capability together quickly. An unregistered agent with access to internal systems is a shadow IT problem and a standing automation with its own permissions, running with nobody tracking what it can reach.
The reach is the risk, not the tool itself. The question that actually matters isn’t “how many AI tools are in use.” It’s which of those tools can reach personal data, proprietary code, or regulated information, and whether that reach exists before anyone has typed a single prompt into them.
What an AI bill of materials actually is
The fix borrows a concept security teams already trust: the software bill of materials. An AI bill of materials, or AI-BOM, is the same idea applied to AI: a complete, exportable inventory of every model, tool, agent, and MCP server in use across the estate, sanctioned and unsanctioned alike.
A working AI-BOM needs to answer a few concrete questions for every entry:
- What is it, and is it an approved tool or a shadow one?
- Is it a registered agent or MCP server, or an unregistered one nobody signed off on?
- Can it reach personal data, and does that reach exist before any prompt is sent?
- What signal sources actually cover this part of the estate, and which parts have no coverage at all?
That last point matters more than it sounds. A governance tool that implies full visibility while actually covering a fraction of the estate is worse than one that’s honest about its blind spots, because a false sense of complete coverage is itself a risk.
Discovery before judgment
The instinct with any new risk category is to jump straight to policy: block this, restrict that. Discovery has to come first, for a simple reason. You cannot govern a tool you do not know exists, and a policy built on an incomplete inventory just pushes usage further underground.
A sound discovery approach keeps a few principles separate rather than collapsing them into one confident-looking score:
Observed facts stay separate from conclusions. An asset being present in the estate is not the same statement as that asset being a confirmed risk. Treating every discovered tool as equally dangerous burns credibility with the teams you need cooperation from.
Coverage gaps stay visible. If a signal source, say, AI sign-up and billing email, or endpoint AI software, isn’t onboarded for a given environment, that gap should show on the same screen as what is covered, not get quietly absorbed into a lower total.
Correlation requires real evidence. An inventory asset or a relationship between two systems should be backed by an independently observed identifier, not inferred because two things look related.
From discovery to governance
Once the inventory exists, governance becomes a tractable problem instead of a guessing game. In practice that means a few recurring workflows:
Triaging unregistered agents and MCP servers by risk, rather than trying to shut all of them down on day one. Some unregistered agents are genuinely low-risk internal tools; others have standing access to sensitive systems and need attention immediately.
Mapping data exposure before mapping usage policy. Knowing which discovered tools can reach personal data is more urgent than knowing how often employees are using them, because exposure doesn’t require frequent use, it just requires one bad prompt or one misconfigured connector.
Keeping the inventory evidence-led, not scanner-invented. Findings from an external scanner should never be allowed to manufacture an inventory asset that wasn’t independently observed. That discipline is what makes an AI-BOM defensible under audit rather than just a long list a tool generated.
Treating this as a living inventory, not a one-time audit. New agents, new MCP connections, and new AI-enabled features inside already-approved SaaS tools appear continuously. A shadow AI snapshot from six months ago tells you almost nothing about today’s exposure.
Why this is now a compliance question, not just a security one
Under India’s DPDP Act, a data fiduciary is expected to exercise real oversight over how personal data is processed, including by automated systems. An AI agent or MCP server with unmonitored access to personal data is exactly the kind of gap that oversight obligation is meant to close. For the current state of the law’s rollout, see our DPDP Act compliance timeline. The same logic extends to frameworks like GDPR, HIPAA, and SOC 2, all of which assume an organization actually knows what’s touching its regulated data.
Shadow AI as part of the exposure surface
An unregistered agent with access to a production data store is exposure in exactly the sense a misconfigured cloud bucket is. It belongs on the same priority list as any other exposure finding, not in a separate “AI risk” conversation that security leadership revisits once a year. Our guide to continuous threat exposure management covers the broader model this fits into.
What to ask before you trust an AI governance claim
- Does it discover shadow tools, or only track the ones already sanctioned?
- Does it flag unregistered agents and MCP servers specifically, not just chatbot usage?
- Does it show which discovered tools can reach personal data, before any prompt is sent?
- Does it display coverage gaps honestly, rather than implying complete visibility?
- Can every inventory entry and relationship be traced back to independently observed evidence?
- Is the inventory exportable as an actual AI-BOM, or trapped in a dashboard only one team can see?
Where Rainier and Denali fit
Rainier’s AI Governance module builds an AI-BOM directly inside the same SOC console already running alert triage and case investigation: every AI tool discovered across the estate, sanctioned and shadow, registered and unregistered agents and MCP servers flagged by risk, and a data-exposure map showing which tools can reach personal data before a prompt is ever sent. It shows coverage transparently, naming exactly which signal sources are and aren’t onboarded for a given environment rather than implying complete visibility.
For the deeper, evidence-backed inventory layer behind the AI attack surface itself, Denali traces agents, models, MCP servers, pipelines, and the identities and data stores connected to them, keeping observed facts, inferred relationships, and security conclusions permanently separate so every claim in the inventory can be opened and checked rather than taken on faith.
Want to see what AI tools, agents, and MCP servers are actually running in your environment? Talk to Network Intelligence.
