Security teams should place approval gates at the point where infrastructure changes become executable, not after deployment. Use namespace or stack level policies, keep the number of approvers aligned to change risk, and reserve stricter controls for production. The goal is to stop unsafe configuration from reaching apply time while preserving a predictable release flow.
Approval Gates Should Block Execution, Not Every Commit
Security teams get the best balance when approval gates sit at the last safe control point before infrastructure changes can execute. That preserves developer flow during drafting and review, while still preventing an unsafe plan, template, or policy change from reaching apply time. The practical question is not whether to add approval, but where to place it so it changes the failure mode without turning every routine change into a manual queue.
For infrastructure-as-code, that usually means gating namespace, stack, or environment promotion rather than every file edit. It also means varying the gate by change risk: low-risk changes can move with lighter review, while production-impacting changes need stronger scrutiny. The OWASP Non-Human Identity Top 10 is relevant where the approval path depends on machine credentials or automation identities, because those identities often become the real enforcement point for who can execute infrastructure changes.
In practice, many security teams discover the bottleneck only after approvals are attached too early in the delivery chain, when merge queues and release cadence have already slowed.
How Approval Gates Fit Into Delivery Pipelines
The most effective approval design distinguishes between code review, policy review, and execution authority. A pull request may confirm intent and detect obvious mistakes, but it does not by itself stop a risky change from being applied through another path. A gate at execution time closes that gap by requiring the change to satisfy policy before a deployment tool, orchestration system, or automation identity can carry it out.
That is why environment scoping matters. Many teams use a lighter gate for development and test, then introduce additional approval or policy checks for shared staging, regulated workloads, or production. The approval itself should be tied to something meaningful, such as a change class, blast radius, data sensitivity, or target environment. If every change needs the same number of approvers, teams tend to either overload reviewers or bypass the process when urgency rises.
A workable pattern is:
- Allow low-risk changes to auto-advance when policy checks pass.
- Require human approval when a change affects privileged access, network exposure, identity trust, or production state.
- Use policy-as-code to make the approval trigger predictable and auditable.
- Keep the approver set small enough that review remains timely, but broad enough that one person does not become a single point of failure.
Where automation identities can execute infrastructure changes, the gate must cover those credentials as well as the change request itself, otherwise the control exists on paper but not at the point of enforcement. This approach breaks down when teams cannot reliably classify change risk or when multiple deployment paths bypass the same control plane.
When Fast Delivery and Stronger Review Pull in Different Directions
Tighter approval controls often increase coordination overhead, so organisations have to balance assurance against release friction. That tradeoff becomes sharper in production, in regulated environments, and around changes that affect shared services, because the cost of a bad change is higher than the cost of an extra review step.
There is no universal consensus on the exact approval threshold for every change type. Some teams prefer one approver for routine operational changes and two for sensitive systems; others use policy thresholds that trigger approval only when the blast radius crosses a defined boundary. The better model is the one that matches real risk, not organisational habit.
Two edge cases matter most. First, emergency changes: teams need an exception path that is fast, documented, and reviewed after the fact, otherwise urgent work will bypass the control entirely. Second, highly automated platforms: if a single automation identity can deploy broadly, then the approval gate must be coupled with credential scope and environment restrictions, or delivery speed will simply move the risk elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Approval gates reduce unsafe infrastructure drift before it is applied. |
| Recommendation — Enforce change approval at apply time for configuration changes that alter system state. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Execution gates depend on limiting who can authorize or run changes. |
| PR.IP-3 — Configuration Change Control Processes | The question is directly about controlled infrastructure change processes. | |
| Recommendation — Restrict change execution to authorized identities and require approval for higher-risk changes. Define change-control workflows that scale review depth with infrastructure risk. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Automation identities often enforce the gate that applies infrastructure changes. |
| NHI-06 — Authorization and Least Privilege | Approval gates are strongest when execution privileges are tightly scoped. | |
| Recommendation — Control automation credentials so only approved pipelines can execute infrastructure changes. Scope infrastructure execution privileges so approval is required before sensitive changes run. | ||
| MITRE ATT&CK | T1219 — Remote Access Software | Deployment and admin tooling can be abused to execute changes outside intended review. |
| Recommendation — Monitor administrative execution paths for change activity that bypasses normal approval. | ||
Practitioner Guidance
What to prioritise: Put the strongest gate on the smallest number of changes that can create outsized harm, especially production changes that alter access, exposure, or shared infrastructure. Do not make every modification equally expensive to approve.
What to verify: Confirm that the gate is enforced where execution happens, not only where code is reviewed. If a change can still reach apply time through another tool, service account, or pipeline path, the control is incomplete.
Decision rule: If a change is reversible, low blast radius, and non-production, use a lighter approval path; if it changes trust boundaries, credentials, or customer-facing infrastructure, require stronger human review and tighter policy checks.
Common mistake: Teams often add approvals to slow delivery as little as possible, then discover the gate is too weak to stop the changes that actually matter. The right design is selective friction, not blanket friction.
Practitioner takeaway: The most durable approval model is one that makes risky infrastructure changes harder to execute without making routine delivery feel like governance theater.
Related resources from NHI Mgmt Group
- How should security teams build AI systems to meet EU AI Act requirements without slowing delivery too much?
- How should security teams produce SOC 2 evidence for cloud infrastructure changes without slowing down delivery?
- How should security teams add application security testing into Azure DevOps CI/CD pipelines without slowing delivery?
- How should security teams add application security testing into a CircleCI pipeline without slowing delivery down?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
