Human approval for AI infrastructure changes: what should be reviewed?

Which infrastructure changes deserve review?

An approval policy is useful when it directs attention to decisions that matter. A new temporary environment from an approved template can fit within a delegated limit. Deleting a production database, opening a network boundary or granting a broad identity changes the risk substantially, even if the API call is small.

Classify work using customer impact, data impact, privilege expansion, financial exposure and recovery difficulty. Use those criteria to define a few clear rules. Avoid a policy that requires identical review for every action; it can create fatigue without helping a reviewer notice the consequential change.

Give the reviewer enough context

Show the destination account or project, affected resources, additions, updates, deletions and expected service impact. Include the reason for the change and evidence that required checks passed. Summaries should link to the underlying plan so a reviewer can inspect replacements or permission changes that a short description may omit.

Explain how to recover and where recovery has limits. Reverting a configuration file does not recover deleted data. A cost estimate can depend on traffic and consumption. Label assumptions rather than presenting uncertain impact as a guaranteed outcome.

Bind approval to the exact proposal

Store approval against an immutable plan identifier or digest, the target environment and the approver's identity. Define expiry and what changes require re-evaluation. If the resource plan, destination or material dependency changes, the original approval should no longer authorize execution.

Terraform can produce an execution plan for review, but using a plan is only one part of the workflow. The surrounding system still needs to control who may execute it, protect the artifact and verify that the selected execution is the reviewed one. Plan files can contain sensitive information and need appropriate access controls.

Reference: source 1

Enforce the decision in the executor

An agent saying that a person approved the change is not an approval record. The service that performs the mutation should look up the decision, check its scope and freshness, and refuse work outside it. Review policy should remain effective if the agent receives misleading text from a log, ticket or repository file.

Keep denied actions visible. A useful denial explains which requirement was unmet and how to obtain a valid decision, without suggesting ways to bypass policy. Separate the right to request a change from the right to approve it when your operating requirements call for independent review.

Define emergency access before an incident

Some incidents require a faster path, but that path needs an owner, a limited scope and an audit trail. Define who can authorize emergency access, how long it lasts and which follow-up review is required. Make it possible to revoke the temporary privilege without waiting for the original agent session.

Rehearse both normal and emergency workflows in a non-production environment. Attempt an expired approval and a modified plan. Confirm that the execution service rejects both and preserves enough evidence to explain why. Latifold's governance design ties approval to the precise plan and policy revision. Verify that behaviour for supported operations, and retain a named owner for application incidents.