The record connects an AI-assisted change to its repository, CI/CD job, credential, target system, approval, and retained run evidence. Engineering and security can review the same path without reconstructing it from separate tools.
What an Agent Action BOM should contain
Actor and owner
Agent, agent team, workflow, CI bot, MCP-connected tool, review bot, 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.
Credential and access
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.
Risk tier
Whether the path is read-only, reversible, privileged, customer-facing, or able to affect production.
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 the team can review.
| Field | Example value | Why reviewers care |
|---|---|---|
| Actor | AI-assisted PR workflow | Shows which automation introduced the change. |
| Credential or role | Package registry token in CI | Shows where normal code review becomes credentialed action. |
| Reachable action | Publish package after merge | Shows where approval is required before the package is published. |
| Evidence gap | Approval reason and token scope not recorded | Shows what would be hard to prove in audit or incident review. |
Use the BOM to separate low-risk code assistance from workflows that can write, deploy, publish, use credentials, or affect production.
See the redacted sample
The fastest way to understand the artifact is to see one. The redacted sample shows scan scope, path counts, a control-first path, standing credential context, missing owner and approval evidence, and recommended next actions.
Open the sample pageWhat decisions it supports
- Which workflows can stay allowed without extra approval.
- Which actions need approval because they use credentials, deploy, publish, delete, or affect production.
- 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 be compared across repositories and teams.
Build a cross-repository view
Connect the same fields across repositories, workflows, credentials, tools, and approvals to see where AI-assisted delivery can write, publish, deploy, or affect production, and which open check to address 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 workflow-mapping artifact.
Clyra maps selected repos or workflows and produces a redacted Agent Action BOM, graph, and evidence packet your engineering, platform, and security reviewers can use.
Map one workflow