Introduction

Artificial Intelligence is rapidly moving beyond chatbots that simply answer questions.

Modern AI systems are becoming agents capable of accessing enterprise data, calling APIs, using external tools, connecting to other AI agents, executing commands, updating business applications, and even initiating automated workflows.

This creates an important security question:

Do we actually know everything an AI agent can see, trust, and execute?

For traditional software, organizations increasingly use a Software Bill of Materials (SBOM) to understand the libraries, frameworks, and third-party components included in an application.

But AI agents introduce a much larger dependency and trust ecosystem.

An AI agent may depend on:

• A foundation model
• System prompts
• Agent skills
• MCP servers
• Plugins
• APIs
• Enterprise data
• Vector databases
• Persistent memory
• Service accounts
• OAuth tokens
• Other AI agents
• External tools

Knowing only the application’s software libraries does not provide enough visibility into this new environment.

This leads to an emerging security concept:

Agent SBOM

An Agent SBOM can be thought of as an inventory of everything that influences an AI agent and everything the agent has the ability to access or execute.

The objective is simple:

What can the agent SEE?

What does the agent TRUST?

What can the agent EXECUTE?

As autonomous AI becomes more deeply integrated into enterprise applications, answering these three questions may become fundamental to AI security.

Understanding the Traditional SBOM

Before discussing an Agent SBOM, it is useful to understand the traditional Software Bill of Materials.

An SBOM provides an inventory of software components used by an application.

For example:

Application
│
├── Operating System
├── Web Framework
├── OpenSSL
├── Log4j
├── Database Driver
├── JavaScript Libraries
└── Third-Party Packages

If a security vulnerability is discovered in one of those components, organizations can search their SBOM inventory and identify affected applications.

For example:

Critical vulnerability discovered
            ↓
Affected library identified
            ↓
Search enterprise SBOM repository
            ↓
Identify applications using library
            ↓
Prioritize remediation

This became especially important following large software supply-chain incidents where organizations struggled to determine whether vulnerable components existed inside their applications.

Standards such as CycloneDX and SPDX provide structured methods for representing this information.

CycloneDX has also expanded beyond conventional software components and supports machine-learning BOM capabilities that include models, datasets, provenance, and related AI information. citeturn784713search0

But autonomous agents create additional dependencies.

Why Traditional SBOM Is Not Enough for AI Agents

Consider a traditional web application.

Its security boundary may look something like:

User
  ↓
Web Application
  ↓
Application Server
  ↓
Database

Now consider an enterprise AI agent:

                    User
                      │
                      ▼
                  AI Agent
                      │
        ┌─────────────┼─────────────┐
        │             │             │
        ▼             ▼             ▼
      Model         Memory        Skills
        │                           │
        ▼                           ▼
      Prompt                      Tools
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
                  APIs          MCP Servers       Database
                    │               │
                    ▼               ▼
               SaaS Systems    External Tools

This is a much broader trust boundary.

A traditional SBOM may tell us:

Python 3.x
FastAPI
Requests
Pydantic
PostgreSQL Driver

But it may not tell us:

Which model is being used?

Which prompt controls the agent?

Which MCP servers are connected?

Which skills are installed?

Which documents can the agent read?

Which API credentials can it use?

Can it execute shell commands?

Can it modify a production system?

Can another agent influence its decisions?

Those questions are increasingly important.

What Is an Agent SBOM?

For the purpose of this discussion, an Agent SBOM, or A-BOM, is:

A structured inventory of the components, identities, instructions, data sources, tools, permissions, and external dependencies that influence an AI agent or can be accessed by it.

Conceptually:

                     AI Agent
                        │
 ┌──────────────────────┼───────────────────────┐
 │                      │                       │
 ▼                      ▼                       ▼
Model                  Prompt                 Identity
 │                      │                       │
 ▼                      ▼                       ▼
Skills                 Memory              Credentials
 │                                              │
 ▼                                              ▼
MCP Servers                                   APIs
 │                                              │
 ▼                                              ▼
Tools                                        Data
 │
 ▼
Other Agents

The Agent SBOM therefore becomes more than a software-component inventory.

It starts becoming a trust and capability inventory.

What Should Be Included in an Agent SBOM?

A practical Agent SBOM could include several major areas.

1. Agent Identity

Every production AI agent should have a clearly defined identity.

Important information could include:

Agent Name
Agent ID
Agent Version
Environment
Business Owner
Technical Owner
Security Owner
Business Purpose
Risk Classification

For example:

Agent Name: Invoice Review Agent

Environment: Production

Business Owner: Finance

Technical Owner: AI Platform Team

Risk: High

This may sound basic, but it becomes essential when dozens or hundreds of enterprise agents exist.

If an incident occurs, the security team must immediately be able to determine:

Which agent performed the action?

2. Foundation Model

The model powering the agent should also be inventoried.

For example:

Provider

Model

Model Version

Hosting Location

Configuration

Region

Why does this matter?

Because changing the underlying model can change how the agent behaves.

Imagine:

Agent Version 1
     │
     ▼
Model A

later becoming:

Agent Version 1
     │
     ▼
Model B

The application code may not have changed.

But the behavior of the AI system potentially has.

For security investigations and compliance, knowing exactly which model was used can therefore be important.

3. System Prompts

System prompts are increasingly becoming part of the application’s security configuration.

For example:

You are an invoice-processing assistant.

You may read invoices.

You may validate vendor records.

You MUST NOT initiate payments.

Payment requests require human approval.

Now imagine one line changes:

You may initiate payments when validation succeeds.

No software dependency has changed.

But the security posture has changed dramatically.

Therefore an Agent SBOM should record:

Prompt Name

Prompt Version

Prompt Hash

Prompt Owner

Approval Status

Last Modified

This allows organizations to answer:

Which version of the system prompt was active when this action occurred?

4. Agent Skills

Agent skills can provide reusable instructions and workflows.

For example, a skill might tell an AI agent how to:

Review source code

Analyze invoices

Search databases

Create tickets

Deploy applications

Perform security scans

Skills can therefore influence agent behavior significantly.

An Agent SBOM should capture:

Skill Name

Skill Version

Publisher

Source Repository

Signature

Dependencies

Permissions

This becomes particularly important when skills are downloaded from public repositories.

A malicious or compromised skill could potentially affect the agent using it.

The security question changes from:

Do we trust the AI model?

to:

Do we trust every capability loaded by the AI agent?

5. MCP Servers

Model Context Protocol, or MCP, enables AI agents to connect to external systems and tools.

An architecture might look like:

AI Agent
   │
   ▼
MCP Client
   │
   ├── GitHub MCP
   │
   ├── Database MCP
   │
   ├── ServiceNow MCP
   │
   ├── Cloud MCP
   │
   └── File System MCP

This is very powerful.

But from a security perspective, every MCP server expands the agent’s attack surface.

An Agent SBOM should therefore contain:

MCP Server Name

Version

Source

Publisher

Authentication Method

Permissions

Tools Exposed

Network Location

Approval Status

For example:

GitHub MCP

Allowed:
repository.read

Not Allowed:
repository.delete
repository.admin

This supports the principle of least privilege.

6. Tools

Agents can have access to many different tools.

For example:

read_file()

search_database()

create_ticket()

send_email()

modify_record()

execute_command()

deploy_application()

These tools do not present equal levels of risk.

A simple risk classification could be:

Low Risk

Read document

Search internal knowledge

Read support ticket

Medium Risk

Create ticket

Draft email

Generate report

High Risk

Send email

Modify database record

Change permissions

Critical

Execute operating system command

Deploy production application

Delete cloud resource

Initiate financial transaction

The Agent SBOM should therefore record both the tool and its potential impact.

7. APIs

AI agents increasingly interact with enterprise APIs.

Examples include:

Customer API

HR API

Finance API

ServiceNow API

GitHub API

Microsoft Graph

Cloud APIs

The Agent SBOM should record:

API Name

API Owner

Authentication Type

Permission Scope

Read / Write Access

Environment

For example:

Finance API
   │
   ├── invoice.read
   │
   └── payment.submit

This immediately tells us that the agent has more than read-only capabilities.

Security teams could then query:

Which AI agents can submit a payment?

That is an extremely valuable security question.

8. Data Sources

AI agents may read information from many different locations.

Examples include:

Email

SharePoint

Google Drive

Internal Websites

Internet

Databases

PDF Documents

Knowledge Bases

Source Code

CRM Systems

But not all data should be trusted equally.

For example:

Internal approved policy
        ↓
HIGH TRUST

Internal employee document
        ↓
MEDIUM TRUST

External website
        ↓
UNTRUSTED

This matters because external data may contain malicious instructions designed to manipulate the AI agent.

This type of attack is commonly known as indirect prompt injection.

Therefore an Agent SBOM should also record the trust classification of data sources.

9. RAG and Vector Databases

Many enterprise agents use Retrieval-Augmented Generation.

A typical architecture may look like:

User Question
     ↓
AI Agent
     ↓
Vector Search
     ↓
Corporate Knowledge
     ↓
Relevant Documents
     ↓
LLM Response

An Agent SBOM should therefore identify:

Vector Database

Embedding Model

Knowledge Collections

Source Systems

Data Classification

Data Owners

Update Mechanism

This is important because compromised or poisoned RAG data can influence agent decisions even if the model itself remains secure.

10. Agent Memory

Some AI agents maintain memory across interactions.

For example:

Session Memory

User Memory

Long-Term Memory

Shared Agent Memory

Memory creates another trust boundary.

Suppose malicious information enters the agent’s memory today.

Could it influence a transaction tomorrow?

Potentially.

An Agent SBOM should therefore record:

Memory Type

Storage Location

Persistence

Retention

Encryption

Data Classification

User Isolation

A particularly important distinction is:

Session Only
     vs
Persistent
     vs
Shared

Shared persistent memory should generally receive greater security scrutiny.

11. Credentials and Machine Identity

AI agents may use:

Service Accounts

API Keys

OAuth Tokens

Managed Identities

Certificates

SSH Keys

Delegated User Credentials

These credentials determine the real authority of the agent.

An Agent SBOM should never store the actual password or token.

Instead, it should reference the identity.

For example:

Agent:
finance-agent

Identity:
finance-agent-prod

Credential:
Managed Identity

Permissions:
invoice.read
payment.submit

This gives security teams visibility without exposing secrets.

12. Permissions

Permissions may ultimately be the most important section of an Agent SBOM.

Consider:

AI Agent
   │
   ▼
Identity
   │
   ├── SharePoint.READ
   │
   ├── ServiceNow.WRITE
   │
   ├── GitHub.READ
   │
   └── Finance.SUBMIT

Now we can see the agent’s potential blast radius.

The Agent SBOM should ideally capture effective permissions, not only intended permissions.

That distinction matters.

The architecture diagram may say:

READ ONLY

while the actual identity may have:

READ
WRITE
DELETE
ADMIN

Security needs to know the second one.

13. Agent-to-Agent Communication

Future enterprise AI architectures are unlikely to contain only one agent.

Instead, we may have:

User
  ↓
Coordinator Agent
  │
  ├── Research Agent
  │
  ├── Finance Agent
  │
  ├── Security Agent
  │
  └── Procurement Agent

This introduces another important concept:

Transitive Trust

Suppose:

Agent A trusts Agent B.

Agent B trusts Agent C.

Agent C becomes compromised.

Could malicious information flow:

Agent C
   ↓
Agent B
   ↓
Agent A
   ↓
Business System

Potentially.

Therefore the Agent SBOM should record relationships between agents.

Static Agent SBOM vs Runtime Agent SBOM

One of the most useful ways to think about Agent SBOM is to separate configuration from actual behavior.

Static Agent SBOM

A static Agent SBOM describes what the agent is configured to access.

Agent
│
├── Model
├── Prompt
├── Skills
├── MCP
├── Tools
├── APIs
├── Data
├── Memory
└── Permissions

It answers:

What could this agent use?

Runtime Agent SBOM

A runtime Agent SBOM could record what the agent actually used during a specific execution.

For example:

Agent Execution
       │
       ├── Model Version
       ├── Prompt Version
       ├── Skill Used
       ├── MCP Called
       ├── Data Accessed
       ├── Credential Used
       ├── API Called
       ├── Other Agent Contacted
       └── Action Performed

Imagine a financial transaction:

Agent:
Invoice-Agent

Model:
Enterprise-Model-v4

Prompt:
Finance-Prompt-v18

Document Accessed:
Invoice-78425.pdf

MCP:
Finance-MCP

Tools:
vendor.lookup
invoice.validate
payment.submit

Identity:
finance-agent-prod

Human Approval:
YES

Now we can answer:

What exactly happened during this transaction?

This would be extremely valuable during incident investigation.

Declared vs Observed Agent Capabilities

Another useful concept is comparing:

DECLARED CONFIGURATION
         │
         ▼
      Compare
         │
         ▼
OBSERVED BEHAVIOR

For example:

Declared

MCP Servers

GitHub
ServiceNow

Observed

GitHub
ServiceNow
External-MCP

That should immediately generate an alert.

Another example:

Declared

GitHub.READ

Observed

GitHub.WRITE

Again:

🚨 Security investigation required.

This turns the Agent SBOM from documentation into a security-control mechanism.

Agent SBOM as a Trust Graph

A spreadsheet may work initially.

But AI agent relationships are naturally better represented as a graph.

For example:

                        Human
                          │
                     delegates
                          │
                          ▼
                       Agent
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
        ▼                 ▼                 ▼
      Model             Skills            MCP
        │                                   │
        ▼                                   ▼
      Prompt                               Tools
                                            │
                           ┌────────────────┼─────────────┐
                           ▼                ▼             ▼
                         APIs             Data       Other Agent

Then add authorization:

Agent
 │
 ├── READ ─────────► Customer Database
 │
 ├── CREATE ───────► ServiceNow
 │
 ├── EXECUTE ──────► Build System
 │
 └── CALL ─────────► Finance Agent

Now the Agent SBOM starts becoming a map of enterprise AI trust.

Example Agent SBOM

The following is a simplified conceptual example.

It is intended to demonstrate what such an inventory could contain.

agent_bom:

  agent:
    id: finance-agent-001
    name: Invoice Review Agent
    version: 3.4
    environment: production

  ownership:
    business_owner: Finance
    technical_owner: AI Platform
    security_owner: AI Security

  risk:
    classification: high

  model:
    provider: approved-provider
    model: enterprise-model
    version: "2026-07"

  prompt:
    id: finance-system-prompt
    version: "18"
    hash: sha256:xxxx
    approved: true

  skills:
    - name: invoice-validation
      version: "3.2"
      source: internal-registry
      signed: true

  mcp_servers:
    - name: finance-mcp
      version: "2.4"
      trust: internal

  tools:
    - name: invoice_lookup
      risk: low

    - name: payment_submit
      risk: critical
      approval_required: true

  data_sources:
    - name: finance-database
      classification: confidential
      access: read

  memory:
    type: session
    persistent: false

  identity:
    type: managed_identity
    reference: finance-agent-prod

  permissions:
    finance_database:
      - read

    payment_system:
      - submit_for_approval

  other_agents:
    - name: fraud-analysis-agent

  network:
    internet_access: false

  logging:
    tool_calls: enabled
    approvals: enabled

Even this relatively simple record gives the security team a much clearer picture of the agent’s security boundary.

How Agent SBOM Helps Vulnerability Management

Suppose a vulnerability is discovered in:

finance-mcp
Version 2.3

Without an inventory, security teams may need to contact:

AI Team

Development Team

Infrastructure Team

Application Owners

Cloud Team

and manually determine where the component exists.

With an Agent SBOM:

Query:

MCP = finance-mcp

Version = 2.3

Result:

12 Agents

5 Development
4 Test
3 Production

Then prioritize further:

Invoice Agent
Production
Finance Read Access
        ↓
HIGH


Payment Agent
Production
Payment Submission
        ↓
CRITICAL


Training Agent
Development
No Sensitive Access
        ↓
LOW

Now vulnerability management becomes contextual.

How Agent SBOM Helps Incident Response

Imagine the SOC receives an alert:

AI agent accessed confidential data and made an unexpected external API request.

The investigation immediately requires several answers.

Which agent?

Which model?

Which prompt?

Which user triggered it?

Which identity did it use?

Which data did it read?

Which tool did it execute?

Which MCP server was involved?

Which external API was contacted?

Did another agent influence it?

With an Agent SBOM combined with runtime telemetry:

Security Alert
      ↓
Agent Identity
      ↓
Agent SBOM
      ↓
Permissions
      ↓
Dependencies
      ↓
Runtime Trace
      ↓
Incident Timeline

Investigation becomes much faster.

Agent SBOM and Zero Trust

There is also a strong relationship between Agent SBOM and Zero Trust.

The basic principle of Zero Trust is:

Never trust implicitly. Verify explicitly.

Apply that to agents.

Agent Identity
      ↓
Authenticate
      ↓
Check Context
      ↓
Evaluate Permission
      ↓
Allow Specific Tool
      ↓
Execute Specific Action
      ↓
Log Result

An agent should not receive broad authorization just because it belongs to a trusted application.

Instead:

RIGHT AGENT

RIGHT IDENTITY

RIGHT TOOL

RIGHT DATA

RIGHT ACTION

RIGHT TIME

The Agent SBOM provides the inventory necessary to make those decisions.

---

Agent SBOM and the AI Supply Chain

Software supply-chain security traditionally looks at:

Developer
   ↓
Source Code
   ↓
Dependencies
   ↓
Build Pipeline
   ↓
Artifact
   ↓
Production

Agent supply chains may look more like:

AI Provider
      +
Prompt
      +
Skill
      +
MCP Server
      +
Tool
      +
RAG Data
      +
API
      +
Identity
      +
Other Agent
      ↓
AI Agent

Compromise any one of these components and the agent’s behavior may change.

That is why Agent SBOM should ultimately be considered part of AI supply-chain security.

---

Security Risks Agent SBOM Can Help Identify

An Agent SBOM can expose several security weaknesses.

Excessive Permissions

Customer Service Agent

Expected:
Customer.READ

Actual:
Customer.READ
Customer.WRITE
Customer.DELETE

---

Unapproved MCP Server

Approved:
GitHub MCP
ServiceNow MCP

Detected:
Unknown Internet MCP

---

Unapproved Skill

Skill:
database-helper

Source:
Public Repository

Publisher:
Unknown

Signature:
None

---

Excessive Internet Access

Finance Agent
     │
     ├── Confidential Data
     │
     └── Unrestricted Internet

Risk:
HIGH

---

Dangerous Tool Combination

Sometimes individual permissions look harmless.

But combinations create risk.

For example:

Read Confidential Data
          +
Send External Email
          =
Potential Data Exfiltration

Or:

Read Source Code
      +
Execute Shell
      +
Internet Access
      =
High-Risk Development Agent

This is another reason the Agent SBOM should represent relationships rather than simply lists.

---

Agent SBOM Security Lifecycle

Agent SBOM should become part of the development lifecycle.

Agent Design
     ↓
Create Agent SBOM
     ↓
Threat Modeling
     ↓
Permission Review
     ↓
Security Testing
     ↓
Deployment Approval
     ↓
Production
     ↓
Runtime Monitoring
     ↓
Agent SBOM Update

Whenever the security boundary changes, the inventory should change.

Examples include:

New Model

New Skill

New MCP Server

New API

New Data Source

New Credential

New Permission

Memory Enabled

Internet Access Enabled

New Agent Connection

Human Approval Removed

Any of these may require a security review.

---

Practical Implementation Approach

Organizations do not need to wait for every industry standard to mature.

Start with one important AI agent.

Document:

Agent

Owner

Model

Prompt

Skills

MCP

Tools

APIs

Data

Memory

Identity

Permissions

Other Agents

Allowed Actions

Store the information as:

JSON

or

YAML

Version-control it.

Then ask multiple security teams to review it.

Application Security

IAM

Data Security

Cloud Security

AI Engineering

Architecture

Finally ask one simple question:

Is there anything this agent can see, trust, or execute that we did not intend?

That is a very powerful first exercise.

---

Future of Agent SBOM

Today, organizations may have:

10 AI Agents

Tomorrow they may have:

1,000 AI Agents

Eventually, large enterprises could have:

50,000+ autonomous agents

At that scale, spreadsheets will not work.

Future AI security platforms may provide dashboards similar to:

AI AGENT INVENTORY

Total Agents               2,486

Models                        38

Skills                       564

MCP Servers                  148

Connected APIs               723

Data Sources                 412

Security findings:

27 Agents with Production Write Access

16 Agents using Unapproved MCP Servers

34 Agents with Unapproved Skills

11 Agents with Persistent Shared Memory

8 Agents combining Confidential Data + Internet Access

3 Financial Agents without Human Approval

This could become a major part of future AI Security Posture Management.

---

The Three Questions That Matter

Even if your organization does not build a complete Agent SBOM today, start by answering three questions for every important AI agent.

What Can It See?

Customer Data

Source Code

Email

Documents

Credentials

Databases

Internet Content

What Does It Trust?

Prompts

Models

Skills

MCP Servers

RAG Data

External Documents

Other Agents

What Can It Execute?

Send Email

Modify Records

Run Commands

Change Infrastructure

Deploy Software

Create Accounts

Initiate Payments

Delete Data

If the security team cannot answer these questions, the organization’s AI attack surface is probably not fully understood.

---

Best Practices for Agent SBOM

Organizations considering Agent SBOM should follow several principles.

Maintain Unique Agent Identities

Every production agent should be individually identifiable.

Follow Least Privilege

Agents should receive only the tools and permissions required for their business function.

Separate Read and Write Access

An agent that needs to analyze data may not require permission to modify it.

Version System Prompts

Treat important prompts like security-relevant configuration.

Approve Agent Skills

Do not allow arbitrary skills from public repositories into production agents.

Control MCP Servers

Maintain an approved MCP server inventory and review their permissions.

Protect Credentials

Store only credential references in Agent SBOM—not actual secrets.

Classify Data Sources

Agents should understand the difference between trusted internal data and untrusted external content.

Require Human Approval for Critical Actions

Actions such as:

Money Transfer

Production Deployment

Account Deletion

Privilege Change

Sensitive External Communication

should normally require additional authorization.

Monitor Runtime Behavior

Compare what agents are expected to do with what they actually do.

Conclusion

The Software Bill of Materials helped solve an important problem:

What components are inside our software?

AI agents introduce a much broader question.

An AI agent is no longer simply:

Application
+
Model

It may be:

Model
+
Prompt
+
Skills
+
MCP Servers
+
Tools
+
APIs
+
Data
+
Memory
+
Identity
+
Permissions
+
Other Agents

Every one of these components contributes to the agent’s trust boundary.

That is why organizations may increasingly need something like an Agent SBOM.

Not simply a list of AI components.

But an inventory capable of answering:

What can the AI agent see?

What does the AI agent trust?

What can the AI agent execute?

As AI systems become increasingly autonomous, the security industry will need much better visibility into their identities, dependencies, permissions, data flows and capabilities.

We learned an important lesson from software supply-chain security:

You cannot protect what you do not know you have.

The same principle will apply to autonomous AI.

Before giving an agent more intelligence, more tools and more authority, make sure you understand exactly what is inside its circle of trust.

That may ultimately be the real purpose of the Agent SBOM.

References

• OWASP — Agentic AI and AI Agent Security guidance
• SPDX — AI and AI-SBOM initiatives
• CycloneDX — Machine Learning Bill of Materials
• NIST — AI Agent Identity and Authorization
• OWASP — Agentic Skills Security guidance