Independent research and operating notes on AI Software Delivery Control.
Field Note / AI Software Delivery Control
AI Coding Agents Are Moving From Suggestions to Actions
The missing artifact is not another model inventory. It is an Agent Action BOM: a practical record of what AI-assisted engineering workflows can touch, change, approve, and prove.
The practical shift shows up in ordinary delivery paths: a workflow opens a PR, changes a CI file, inherits a token, calls a tool, or starts a release job.
Last updated: May 5, 2026
In this field note
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.
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/proofThat is what an Agent Action BOM should capture. It is not a report about whether AI exists. It is a map of action exposure.
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 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.