An approval policy is a governance rule that requires one or more human reviews before an infrastructure change can execute. In Terraform workflows, it adds a control point before apply runs, helping teams slow down risky changes and keep high impact modifications visible and accountable.
Expanded Definition
An approval policy is a governance control that inserts a human decision point before a privileged infrastructure action executes. In Terraform and similar infrastructure-as-code workflows, it typically gates apply, but the exact shape varies across platforms, pipelines, and risk tiers.
In NHI governance, approval policies are not the same as simple change logging. They are designed to slow execution until a reviewer can assess blast radius, identity scope, environment sensitivity, and rollback readiness. That makes them part of broader control design, not just a workflow convenience. The most useful mental model is to treat approval policies as a preventive control that supports separation of duties, especially when service accounts, API keys, or automation agents can alter production state. This aligns with the intent of the NIST Cybersecurity Framework 2.0, which emphasizes governance and controlled change. NHI Management Group also places approval decisions in the larger lifecycle context described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
The most common misapplication is using approval policy as a substitute for least privilege, which occurs when teams approve broad changes without constraining what the automation identity can actually do.
Examples and Use Cases
Implementing approval policies rigorously often introduces release friction, requiring organisations to weigh deployment speed against reduced change risk and stronger accountability.
- A production Terraform plan that opens a database security group requires two reviewers before apply, because the change could expose data paths.
- A CI/CD pipeline that rotates a high-value API key pauses for approval when the target workload is customer-facing or regulated.
- An infrastructure change that modifies IAM bindings needs a human review to confirm the service account does not gain broader privileges than intended.
- A break-glass remediation flow uses an approval policy to ensure emergency access is time-bound and later audited.
- A shared platform team routes high-impact changes through Top 10 NHI Issues guidance so reviewers can check for secret exposure, privilege creep, and unsafe automation paths, while NIST Cybersecurity Framework 2.0 helps frame the control as part of a managed governance process.
Why It Matters in NHI Security
Approval policies matter because many NHI incidents begin with a valid automation path that was too powerful, too fast, or too poorly reviewed. When changes can execute without human oversight, misconfigurations, secret exposure, and privilege escalation can move straight into production. That is especially dangerous in environments where NHI sprawl is already high and oversight is weak. NHI Management Group reports that only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot reliably judge whether an approval is sufficient because they do not fully know what the automation identity can reach.
Approval policy is also a governance signal for audit and accountability. The Regulatory and Audit Perspectives section shows why change controls, evidence trails, and reviewer responsibility become important after an incident or compliance review. In practice, approval policy helps prove that high-impact NHI actions were not left to unchecked automation. Organisations typically encounter the need for approval policy only after a production change, credential misuse, or access drift triggers an incident review, at which point the control becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Approval policies help constrain risky NHI changes before execution. |
| NIST CSF 2.0 | GV.OC, PR.AC | Governance and access control practices include approval gates for high-impact changes. |
| NIST Zero Trust (SP 800-207) | RA-3, AC-6 | Zero Trust requires explicit verification and least privilege before sensitive actions proceed. |
| NIST SP 800-63 | IAL/AAL (conceptual) | Human reviewer assurance matters when authorizing sensitive automation changes. |
| OWASP Agentic AI Top 10 | AGENT-04 | Agentic systems need approval checkpoints before tool use or execution escalation. |
Require human review for privileged NHI actions and verify the automation identity cannot self-approve changes.
Related resources from NHI Mgmt Group
- Who should own approval policy for autonomous agent actions, IAM or application teams?
- What is the difference between policy drafting and policy approval?
- What breaks when AI agents can make network policy changes without explicit approval?
- Why do approval based authorization patterns need to keep policy and workflow separate?
