AI Coding Agents Are Moving From Suggestions to Actions

A first row

A first Agent Action BOM row can be ordinary and still useful:

Actor: AI PR repair workflow
Owner: Platform engineering
Repo/path: payments-api/.github/workflows/pr-repair.yml
Credential: CI token scoped to repo and branch
Reachable actions: write branch, run tests, comment on PR
Approval-required: workflow-file changes, package publish, deploy
Proof: PR link, workflow run, credential identity, policy verdict, approver, test result

This is the level where the conversation gets useful. The team can now decide whether the token is too broad, whether workflow changes need pre-execution approval, and whether the proof packet would be good enough during an audit or incident review.

The shift

A coding assistant that suggests a function is a productivity tool. A coding agent or workflow that can open a pull request, modify a GitHub Actions file, use a service token, call an MCP tool, publish a package, or trigger CI/CD is something else.

It has entered the software delivery path. From that point, the useful governance question is not only whether the code is correct. It is whether the workflow had authority to take the action and whether the team can defend the action later.

The missing artifact

Most teams already have artifacts for adjacent problems. An SBOM lists software components. A cloud inventory lists assets. An IAM review lists identities and permissions.

AI-assisted software delivery needs a different artifact because the risk crosses several systems at once:

agent/workflow -> repo/PR -> credential -> action -> target -> approval/proof

That is what an Agent Action BOM should capture. It is not a report about whether AI exists. It is a map of action exposure, review discipline, and proof.

What belongs in it

A useful first version does not need to be complicated. It should let a security, engineering, or platform reviewer answer these questions without a meeting:

• Which agent or workflow is acting?
• Who owns it?
• Where was it introduced: repo, PR, workflow file, config, or script?
• Which credential or inherited identity does it use?
• What action classes are reachable: read, write, deploy, delete, secret access, package publish, cloud API, database write?
• Which target systems can it touch?
• Which review or approval applies?
• Which actions are allowed, approval-required, or blocked?
• What proof exists after the action?

Where to start

Start with two or three workflows where blast radius is plausible: a PR workflow that can run CI, a GitHub Actions job with secrets, a release workflow, an MCP-connected engineering tool, or a package publishing path.

Do not try to govern every AI interaction on day one. Map the action path first. Then decide which actions can be allowed, which need approval, which should be blocked, and what proof should remain.