What Security Leaders Should Ask Before Approving AI in Delivery Workflows

The approval meeting often arrives with a familiar sentence: "We want to roll out coding agents, but security is nervous." The packet may include a polished demo and an urgent delivery ask. What is often missing are the runtime facts security needs to approve the path responsibly. Once an AI system can change code, approvals, credentials, or delivery behavior, the useful review question is narrower: what exactly can it do, under what boundary, with what proof left behind?

In this piece

The approval problem The five questions that matter What an approval packet should contain Why platform should want the same answers How to improve the review loop

Series home | All field notes

The approval problem

The typical AI approval request arrives with too much of the wrong information and too little of the right kind. Security gets vendor positioning, product screenshots, and broad claims about guardrails. What the team actually needs is much more specific: action classes, execution boundaries, approval mediation, environment assumptions, and evidence outputs. Without those, the review becomes a debate about comfort rather than a decision about control.

That is why so many reviews drag. The team is not refusing to move. It is trying to infer the runtime consequences from a surface-level packet. Any approval model that depends on inference instead of explicit design inputs will be slow and inconsistent.

The five questions that matter

First: what can this system actually do? Reading, drafting, writing, approving, restarting, merging, calling external tools, and changing CI behavior are not the same risk category.

Second: what can it access, inherit, or invoke through surrounding systems? In many enterprise workflows, the dangerous part is not the model itself but the privileges attached to the environment around it.

Third: where is the boundary before execution? If policy, approval, or human review only exist after the tool call, security is being asked to bless an advisory system as though it were a preventive one.

Fourth: what evidence will remain after the action? Approval records, policy verdicts, validation outputs, and change evidence should be explicit before rollout, not improvised during the first incident.

Fifth: how is this path shut down, narrowed, or rolled back if the assumptions prove wrong? A serious approval posture needs revocation, not just onboarding.

What an approval packet should contain

A useful approval packet is small and concrete. It should describe the action classes in scope, the execution environment, the policy verdict model, the validation path, the review path, the evidence outputs, and the rollback or disable path. If those elements are not present, the tool is not ready for a meaningful approval discussion.

A minimal packet should include: owner, repo or workflow, credential source, reachable action classes, target systems, approval rule, validation command, evidence output, rollback owner, and re-review trigger. The Agent Action BOM covers the action-path fields; the CI/CD control guide covers delivery behavior and proof.

Workflow: AI-assisted dependency update
Owner: Platform engineering
Repo: customer-api
Credential: CI token scoped to repo and branch
Action class: write branch, open PR, run tests
Approval rule: pre-approval required for workflow-file changes, package publish, or deploy
Evidence: PR link, workflow run, policy verdict, credential identity, approver, test result
Rollback owner: platform on-call
Re-review trigger: new secret access, new deployment path, broader repo scope

The meeting should not be used to discover those fields live. It should be used to decide whether the written action class, boundary, evidence path, and rollback plan are good enough for the requested scope.

This is not a paperwork preference. It is what lets a security leader explain later why the approval made sense, what assumptions it rested on, and what would cause the decision to change.

Why platform should want the same answers

Platform teams sometimes experience these questions as drag. In reality they are the design inputs that make later scale easier. A tool that cannot explain what it can do, how it is bounded, and what evidence it leaves behind is not being slowed down by review. It is arriving unprepared for the environment it wants to enter.

The best approval conversations happen when platform and security are already using the same language. That keeps the review focused on a few meaningful decision points instead of a long improvisation over ambiguous control claims.

How to improve the review loop

Turn the five questions above into a standard intake form for any AI tool that touches delivery workflows.
Require action class and evidence outputs before the first security review meeting.
Classify controls as preventive, detective, or advisory so the approval language stays honest.
Set explicit re-review triggers: expanded permissions, new environments, new write paths, or reduced human review.
Track how often approval packets arrive incomplete. That metric will tell you where the operating model is still weak.

A strong approval posture is not built from stronger opinions. It is built from better questions, asked early enough that the path can still be designed well.