Independent research and operating notes on AI Software Delivery Control.
Reference / Approval control
Approve Actions, Not Prompts
Teams do not need a human approval for every prompt. They need clear approval rules for the moments where an AI-assisted workflow can change state: write code, modify CI/CD, use credentials, invoke tools, publish packages, deploy, delete, or touch production-adjacent systems.
Prompt review is too early and too broad for most software-delivery controls. Action approval belongs at the execution boundary, where the system can decide whether an action is allowed, approval-required, or blocked.
Last updated: May 6, 2026
On this page
Short answer
Approve actions, not prompts. Classify each AI-assisted workflow action as allowed, approval-required, or blocked based on what it can touch or change. Keep low-risk assistance fast. Require approval before high-risk actions execute. Preserve proof after the decision.
Why prompts are the wrong unit
A prompt is intent. An action is impact. In software delivery, the control question is not only what the user asked for. It is what the workflow can execute with the surrounding repo permissions, credentials, tools, and CI/CD context.
Reviewing every prompt creates noise and delay without necessarily controlling the action that matters. A harmless prompt can lead to a privileged action if the workflow has broad credentials. A risky prompt may remain harmless if the workflow has no authority to execute the action. Approval should follow authority.
Action classes
Start by naming the action classes that matter in your environment.
- Read repository, issue, documentation, or dependency context.
- Write code, branch, pull request, issue, or documentation content.
- Modify workflow files, policy files, scripts, or reusable actions.
- Invoke MCP tools, APIs, package managers, or internal services.
- Use credentials, secrets, service accounts, or inherited identities.
- Publish packages, deploy, restart services, or change infrastructure state.
- Delete, disable, bypass, or perform destructive actions.
Decision table
The first decision table should be simple enough for engineering and security to use without a new committee.
Allowed:
- Read repo context
- Suggest code locally
- Run tests without secrets
- Comment on PR with narrow credential
Approval-required:
- Write branch from unattended workflow
- Modify CI/CD or policy files
- Invoke MCP write action
- Publish package or deploy
- Use credential for production-adjacent target
Blocked:
- Bypass required checks
- Access production secrets without approved path
- Delete artifacts without recovery plan
- Execute high-risk action without proof trailApproval packet
An approval packet should be smaller than a full governance report and more specific than a yes/no tool approval.
Action: modify workflow file
Workflow: AI-assisted PR repair
Owner: Platform engineering
Credential: repo-scoped CI token
Target: .github/workflows/pr-repair.yml
Policy verdict: require_approval
Approver: AppSec reviewer
Validation: workflow syntax check and required tests
Proof: PR link, workflow run, policy verdict, approver, test result
Re-review trigger: broader credential, new target environment, deploy step addedChecklist
- List action classes before writing approval rules.
- Map each action class to allowed, approval-required, or blocked.
- Base approval on action authority, credential context, target system, and blast radius.
- Require approval before high-risk actions execute, not after the run completes.
- Keep proof fields attached to the action path.
- Review the table when credentials, targets, tools, or execution context changes.