The shift from a manual plan‑review step to a flood of agent‑generated pull requests has turned the approval gate into a routine queue‑clearer rather than a safety check. This is a classic case of plan review saturation, where reviewer capacity is outpaced by change velocity, causing the four original purposes of the gate—policy compliance, blast‑radius assessment, intent verification, and audit evidence—to collapse, exposing production environments to unchecked change.
Why Plan Review Saturation Breaks Governance
Plan review originally bundled four distinct responsibilities:
- Policy compliance: confirming the change matches organizational rules.
- Blast‑radius assessment: estimating how far a faulty change could spread.
- Intent verification: checking that the change implements the requested outcome.
- The record: creating an audit trail that a human evaluated the change.
All four depend on a finite resource—reviewer attention. As automated agents begin opening dozens of pull requests before lunch, the volume exceeds capacity. Reviewers resort to “queue‑clearing” approvals, which generate the same audit event as a thoughtful review but contain no evaluation. Generated code also removes the familiar shape that humans use to spot anomalies, further degrading the quality of the check.
Move Compliance Checks Into the Run
Compliance can be expressed as a deterministic match between a proposed plan and a rule set. By shifting this match to the execution phase, the system can reject non‑conforming plans before they are applied. A practical approach is to:
- Run policy evaluation when the IaC plan is generated.
- Reject any plan that has changed state since the last evaluation, forcing a re‑plan.
- Configure a default‑deny stance for high‑impact resource classes—identity and access management, networking, and data stores.
- Auto‑approve changes to lower‑risk resources, reserving human sign‑off for the cases explicitly routed by policy.
This reduces reviewer load and ensures that the audit log records a policy decision rather than a superficial approval click.
Replace Blast‑Radius Estimation With Hard Constraints
Estimating potential damage is the weakest of the four functions, especially for unfamiliar, AI‑generated code. Instead of guessing, impose concrete limits:
- Assign a time‑to‑live (TTL) to experimental infrastructure and automatically destroy it on expiry.
- Enforce budget caps on resource creation.
- Restrict creation of certain resource types to non‑production accounts.
- Adopt a two‑path model: a governed production path (IaC/GitOps) where every change is traceable, and a fast‑path for experiments where constraints replace review.
When a change cannot exceed predefined limits, the need for a probabilistic blast‑radius estimate disappears.
Because the audit log now records the policy engine’s decision rather than a human click, the evidence of evaluation is tied directly to the enforcement action. This eliminates the false equivalence between a queue‑clearing approval and a genuine review, and it provides a tamper‑evident trail for auditors.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Actionable steps:
- Audit your current plan‑review workflow to quantify approvals per reviewer per day.
- Instrument your policy engine to emit detailed audit records that include rule name, input data, decision, and timestamp.
- Implement deny‑by‑default policies for IAM, networking, and data resources, and configure auto‑approval for the rest.
- Define fast‑path constraints (TTL, budget caps, account segregation) for any agent‑generated changes.
- Ensure agents operate under scoped identities and that their actions are logged as the actor.
- Deploy drift detection that measures mean time to repair (MTTR) rather than raw drift count, focusing on how long an environment remains in an unintended state.
By treating compliance as an automated enforcement point and constraining experimental work, teams can restore the safety guarantees that plan review once provided, even at AI‑driven change velocities.
