AI-BOM for AppSec: Trace Vulnerabilities to Affected Agents

When a component breaks, which agents break with it?

‍

A security advisory lands for an MCP server your teams use. The first thing AppSec has to answer is which agents connect to it. In most organizations nobody can answer that fast, because no single record ties AI components to the agents built on them.

‍

Agents are assembled from various components. One agent might run on an open source agent framework, call a hosted model through an AI service, and connect to several MCP servers, each exposing its own tools. Those parts are shared. The same MCP server can sit behind four agents owned by three different teams, and the same tool can be reused across a dozen workflows. A vulnerability in one shared component becomes exposure in every agent that depends on it.

‍

Software teams addressed a version of this problem with the SBOM. An AI-BOM applies the same idea to the agentic stack. Lasso's AI-BOM goes a step further and links every asset back to the agents that use it, which is the piece AppSec needs when a vulnerability shows up.

‍

Every AI building block, discovered from code, cloud, and runtime

‍

The AI-BOM inventories the building blocks your agents are made of, including the models they call, the MCP servers and tools connected to them, the vector databases they retrieve from, and the frameworks and AI services they run on.

‍

Lasso discovers these components from code, cloud, and runtime. Each component shows which of those sources found it, when it was first discovered, and when it was last seen. A tool found in a repository but never observed in production carries a different risk than one that runs on every request, and the AI-BOM keeps that difference in view.

‍

New components show up every week as teams ship agents. The AI-BOM flags each one as new so AppSec can review it before it spreads to more agents. A spreadsheet inventory built last quarter has already missed them.

‍

From a vulnerable component to the agent that runs it

‍

Each row in the AI-BOM lists the component, its type, how many agents use it, how it was discovered, the vulnerabilities found in it, and their severity. Vulnerabilities are categorized against the OWASP Top 10 for Agentic Applications, so each finding carries a standard category such as ASI05 Unexpected Code Execution or ASI04 Agentic Supply Chain Vulnerabilities.

‍

Open a component and the detail view showcases two main aspects: the agents that use it and the vulnerabilities found in it.

‍

‍

The findings are specific to how the component is built. For this MCP server, the AI-BOM flags analytics tools that accept a caller-supplied tenant ID without checking that the authenticated user belongs to that tenant. It flags a single shared database credential with query access across all tenants. It also flags an MCP framework dependency pinned with a caret range, where a compromised minor release could remove guard enforcement without any change to application code. Each finding names the code or configuration responsible, so the developer who picks it up starts at the root cause.

‍

The Used by list is what connects a finding to real exposure. Click through to an agent and Lasso opens its AI-SPM graph with the path from the component highlighted. In the example below, a run_python tool carries a critical ASI05 finding because it executes LLM-generated code without a sandbox. The graph shows that the Analytics Agent calls it and that the tool reads from the PostgreSQL warehouse database. The full path runs from the user request, through the supervisor agent and the Analytics Agent, to the tool and the data store behind it.

‍

‍

Run the same lookup on a component used by four agents and you get four exposure paths, each naming an agent that can be compromised.

‍

What the mapping changes for AppSec

‍

Prioritization

‍

A vulnerability list without agent context leaves AppSec ranking findings by severity alone. Severity describes how bad a flaw is in isolation, and the Used by count describes how far it reaches. A high-severity flaw in a model used by 23 agents belongs ahead of a critical flaw in a tool that one internal prototype calls, provided you can see both numbers. The AI-BOM puts severity and reach in the same row, so teams rank work by actual exposure.

‍

Mitigation

‍

A fix to a shared component takes time. The maintainer has to patch it and every consuming team has to update. Until that happens, the affected agents need compensating controls. Because the AI-BOM names those agents, AppSec can tighten runtime guardrails on that specific set and leave the rest of the environment untouched.

‍

Remediation

‍

Remediation stalls when nobody knows who owns the fix. The AI-BOM ties each vulnerable component to the agents that use it, which turns one finding into a scoped work item for the teams that own those agents. The finding itself describes the cause in concrete terms, such as an unpinned dependency range or a missing tenant check, so developers can act on it without a separate investigation.

‍

Where the AI-BOM fits

‍

The AI-BOM is part of discovery in Lasso's AI Security Platform. Discovery is the first stage of a continuous loop that runs through AI risk management, Automated AI Red Teaming, and runtime protection, and the component inventory and agent mapping are what the later stages work from.

‍

Watch the 40-second walkthrough here:

‍

‍

Book a demo to see the AI-BOM on your own agents.