Security teams already have tools for dependencies, code findings, identity inventory, and runtime events. The missing artifact is often the action path: how an AI-assisted workflow reaches a repo, credential, CI/CD job, cloud command, package publish step, or release workflow, and whether that action was approved and supported by an evidence pack.
What an Agent Action BOM should contain
Actor and owner
Agent, workflow, CI bot, MCP-connected tool, or internal automation, plus the human or team accountable for it.
Location
Repo, PR, branch, workflow file, config, script, tool declaration, or release path where the action path appears.
Authority
Credential source, identity, scope, standing versus short-lived access, owner, and revocation path.
Reachable actions
Read, write, workflow change, CI execution, secret access, package publish, cloud API call, deploy, delete, or egress.
Targets
GitHub, GitHub Actions, package registries, cloud accounts, databases, MCP tools, internal APIs, or release systems.
Approval and evidence
Allowed, approval-required, or blocked actions, plus where approval, credential use, validation, and outcome evidence lands.
Example action path
A useful Agent Action BOM turns scattered delivery evidence into a path security can review.
The point is not to label every AI-assisted change as high risk. The point is to separate low-risk code assistance from paths that can write, deploy, publish, use credentials, or affect production-adjacent systems.
What decisions it supports
- Which workflows can stay allowed without extra approval.
- Which actions need approval because they carry credential, deploy, publish, destructive, or production-adjacent risk.
- Which paths should be blocked until credentials, owners, or evidence gaps are fixed.
- Which standing credentials should move toward scoped or short-lived access.
- Which evidence should be retained for customer security review, SOC 2, ISO 27001, or incident review.
- Which action paths should become part of the team's action-control graph.
How it becomes an action-control graph
The Agent Action BOM is the first artifact. When the same fields are connected across repos, workflows, credentials, tools, and approvals, the team gets an action-control graph: a living view of where AI-assisted authority enters software delivery and which path to govern first.
What it does not replace
An Agent Action BOM does not replace SAST, SCA, SBOMs, secret scanning, IAM, PAM, NHI inventory, or runtime agent gateways. Those controls answer important adjacent questions. The Agent Action BOM answers the software delivery action question: what can act, with which authority, against which target, and what evidence exists?
Source notes
- GitHub Copilot cloud agent docs describe pull-request workflows, a GitHub Actions-powered environment, and branch limitations.
- Claude Code permissions docs describe tool permissions, approval modes, allow/ask/deny rules, and why permissions and sandboxing are complementary.
- MCP security best practices describe risks such as confused deputy conditions and token passthrough.
Use the BOM as the first assessment artifact.
Clyra maps two to three repos or workflows and produces a redacted Agent Action BOM, action-control graph, and evidence pack your security and platform teams can review.
Request assessment