The Shadow AI in Your Codebase — and Why You Need an AI Bill of Materials

The scenario: a payments team that moved fast

A mid-size fintech ships a new "smart support" feature. Over two quarters, three different squads add AI on their own schedules: a customer-support agent built on LangGraph, a data-analysis agent that talks to the warehouse, and a couple of MCP servers wired up so agents can read files and hit internal APIs. Each shipped through normal code review. Each looked reasonable in isolation.

Then the security team gets a simple question from their auditor: "List every AI agent in production, what it can do, and what data it can reach."

Nobody can answer it. Not because the team is careless — because there was never an inventory. AI capability is spread across repos, frameworks, and config files, described in code that reads like ordinary Python. The risk isn't a single obvious mistake; it's that no one has the whole picture.

This is shadow AI, and it's now the default state of most engineering orgs.

Why AI risk hides so well

Traditional dependency scanners look for known-vulnerable packages. But the risky part of an AI system usually isn't a CVE — it's what an agent is allowed to do. A support agent with a delete_customer_record tool and no human-in-the-loop is a serious excessive-agency risk, and it will pass every SCA scan you own, because there's no vulnerable library involved. The danger is the wiring, not the version.

The same goes for MCP servers. An MCP filesystem server scoped to / hands any prompt-injected agent your whole disk. A shell server gives it command execution. These are single lines in a config file, and they are invisible to every tool built for the pre-AI world.

What an AI Bill of Materials gives you

An AI Bill of Materials (AI-BOM) is the AI equivalent of an SBOM: a complete, machine-generated inventory of every AI component in a codebase. ScopeSafe AI builds one with the open-source aibom scanner — static analysis only, nothing executed:

• Agents across LangChain, LangGraph, CrewAI, AutoGen, and LlamaIndex, including the graph and factory idioms most tools miss, with cross-file resolution of the tools and models they actually use.
• Models — every LLM client and the provider behind it.
• Tools — decorated functions, tool objects, and imported tool lists, each tagged with coarse capabilities: filesystem, exec, network, delete, payments.
• MCP servers — parsed from config, with scope classified as broad, scoped, or unknown.

Back to the fintech. The security lead runs aibom against the monorepo and, in seconds, has the answer the auditor wanted — plus a set of findings mapped to the OWASP LLM Top 10:

• AGENT-001 (HIGH) — the support agent holds a destructive delete_customer_record tool with no human approval gate. Excessive Agency (LLM06).
• MCP-001 (HIGH) — a filesystem MCP server scoped to /. Broad, over-permissioned access.
• SECRET-* (CRITICAL) — a provider key hardcoded in a config module.

None of these would have surfaced in a normal review, because each looked fine on the line it lived on.

From inventory to enforcement

Discovery is the first win; the second is making sure it never regresses. ScopeSafe AI tracks findings across scans with a Snyk-style lifecycle — new, recurring, resolved — so you always know what changed. Wire the scanner into CI, and a pull request that introduces a new critical or high finding fails the build before it merges:

pip install scopesafe-aibom
aibom . --upload --project payments-service
# gate: fail — 1 new high finding: AGENT-001: agent has destructive
# tools without human approval

A known, accepted risk stays quiet; a brand-new one stops the merge. That's the difference between an inventory you generate once for an audit and a control that holds the line every day.

Why this benefits your organization

• Answer the AI governance question on demand. When a regulator, auditor, or board member asks what AI is running and what it can do, you produce a current AI-BOM instead of a Slack thread.
• Catch excessive agency before production. The highest-impact agentic risks — destructive tools, over-scoped MCP servers, injection blast radius — are exactly what the scanner is built to flag, mapped to a standard your team already reports against.
• Shift AI risk left without slowing teams down. Engineers keep shipping; the CI gate only intervenes on genuinely new, genuinely serious findings.
• Standardize on OWASP LLM Top 10. Findings arrive in the language your security program and auditors already speak.

Shadow AI isn't a hypothetical. It's in your repos right now, shipped by people doing their jobs well. The only question is whether you can see it. Start with a scan: pip install scopesafe-aibom.

ScopeSafe AI is powered by the open-source aibom scanner. Explore AI Security →