What Is an Agent Action BOM?

When to create one

Create the first Agent Action BOM when a team is about to let an AI-assisted workflow move beyond local suggestions. The trigger is not "AI exists." The trigger is action authority: output is rising, review capacity is limited, and the team needs conditions of trust it can defend later.

• A coding agent can open or update pull requests.
• A workflow can modify CI/CD files, reusable actions, or release scripts.
• An agent or job inherits a token, service account, OAuth grant, or CI secret.
• An MCP server or tool call gives the workflow reach into another system.
• A security, platform, or audit reviewer asks for evidence of what happened.

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/proof

Why 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, which review applies, and what evidence survives afterward.

Core fields

Checklist version

If the artifact needs to fit into an AppSec review, security briefing, or platform standard, the minimum useful checklist is:

• Actor: agent, workflow, bot, assistant, or automation name.
• Owner: accountable human team, service owner, or platform owner.
• Location: repo, PR, branch, workflow file, config file, local setup, MCP declaration, or script.
• Tool path: APIs, MCP servers, package managers, shell, browser automation, cloud CLI, CI/CD jobs, or SaaS connectors.
• Credential: token, OAuth grant, service account, CI secret, deploy key, inherited user identity, or short-lived credential.
• Action classes: read, write, execute, change workflow, access secret, publish package, deploy, call cloud API, or modify data.
• Target systems: repo, branch, package registry, CI/CD system, cloud account, database, issue tracker, deployment path, or release workflow.
• Control rule: allowed, approval-required, or blocked.
• Proof: actor, owner, credential identity, action, target, approval decision, validation result, timestamp, 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.

A first-pass example

A useful first pass can be written in plain language before it becomes a system of record:

Workflow: AI-assisted PR repair
Owner: Platform engineering
Repo: payments-api
Credential: CI token scoped to repo and branch
Reachable actions: read repo, write branch, run tests, comment on PR
Approval-required actions: change workflow files, publish package, deploy
Blocked actions: access production secrets, delete branches, bypass required checks
Proof: PR link, workflow run, credential identity, policy verdict, approver, test result

The value is not the format. The value is that AppSec, platform, and engineering can now discuss a concrete action path instead of arguing over whether the tool is generally safe.

Team questions

• We are rolling out coding agents and security is nervous. Which workflows can write code, change CI/CD, or trigger deployment paths?
• AI-assisted output is rising faster than review capacity. Which actions need stronger validation or proof?
• We need audit evidence for AI-assisted SDLC. Which proof fields survive after the action?
• We do not want long-lived credentials in agent workflows. Which credentials are standing, inherited, or broader than the task requires?
• We need to approve risky actions, not every prompt. 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.