Actor and owner
Agent or workflow name, type, human owner, purpose, repo, PR, branch, and source location.
CAISI
Independent research and operating notes on AI Software Delivery Control.
Reference / AI Software Delivery Control
What Is an Agent Action BOM?
An Agent Action BOM is an inventory of AI-assisted software delivery action paths. It maps the actor, owner, repo, workflow, credential, reachable actions, target systems, approval rule, and proof coverage.
Last updated: May 5, 2026
On this page
Definition
An Agent Action BOM answers a narrow operational question:
What can this AI-assisted engineering workflow touch or change?
The artifact follows the action path rather than only the model or code artifact:
agent/workflow -> repo/PR -> credential -> action -> target -> owner -> approval/proofWhy it exists
AI coding agents and automations can cross boundaries that are usually reviewed separately: repository permissions, CI/CD workflows, secrets, package managers, MCP tools, cloud APIs, release workflows, and production-adjacent systems.
A normal inventory can show that a tool exists. An Agent Action BOM should show what the tool or workflow can do.
Core fields
Credential
Token, service account, OAuth grant, CI secret, inherited identity, or short-lived credential.
Reachable actions
Read, write, deploy, delete, execute, secret access, package publish, cloud API, or database write.
Control and proof
Allowed, approval-required, or blocked actions plus evidence of approval, credential use, target system, and outcome.
How it differs from an SBOM and an AI inventory
An SBOM lists software components. An AI inventory may list models, prompts, tools, datasets, providers, or approved applications.
An Agent Action BOM maps action authority. It is about what an AI-assisted workflow can touch or change across software delivery.
Buyer questions
- Which AI-assisted workflows can write code, change CI/CD, or trigger deployment paths?
- Which credentials do those workflows inherit, and are they broader than the task requires?
- Which actions should be allowed automatically, require approval, or be blocked?
- Could an AppSec, platform, or audit reviewer reconstruct what happened after a privileged action?
- Who owns each action path when the agent, workflow, repo, credential, and target system span different teams?
How to use it
- Start with two or three repos or workflows where AI-assisted actions can affect delivery.
- Map the actor, credential, action, target, owner, approval rule, and proof trail.
- Classify each action as allowed, approval-required, or blocked.
- Fix standing broad credentials before expanding write authority.
- Use the artifact in AppSec review, platform standards, and CISO reporting.