Deployment-only controls miss earlier risk points such as plan review, access scoping, and change approval. That creates a gap where risky infrastructure changes can be prepared and queued without sufficient oversight. Effective governance needs controls before, during, and after deployment so teams can detect issues before they reach production.
Why Deployment-Only Guardrails Fail Terraform Governance
Terraform changes are often treated as safe until the apply step, but the real risk begins earlier. A risky plan can be generated, reviewed too late, or approved by someone without enough context to judge blast radius, secret exposure, or privilege escalation. That is why deployment-only controls miss the decision points that matter most for infrastructure as code.
Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes governance and risk treatment before execution, not just after. In NHI-heavy environments, the same pattern appears in secret handling and CI/CD compromise. NHIMG research on the GitHub Action tj-actions Supply Chain Attack shows how secrets can be exposed well before deployment, which means apply-time checks arrive too late to prevent misuse.
Terraform workflows fail when teams confuse change execution with change control. In practice, many security teams discover that a bad infrastructure decision was already queued, reviewed superficially, and chained into CI/CD before anyone asked whether the plan itself was acceptable.
How It Works in Practice
Effective Terraform governance needs controls at three layers: plan creation, approval, and apply. At plan time, teams should validate whether the proposed infrastructure aligns with policy, whether sensitive resources are being created, and whether any module or variable introduces secrets or privileged attachments. At approval time, the reviewer should assess intent, not just syntax. At apply time, the pipeline should enforce the final policy decision rather than re-litigate it.
That means integrating policy-as-code checks into the workflow, but not relying on them only at deployment. Tools such as OPA or Cedar can evaluate context such as workspace, environment, resource type, and identity of the actor requesting the change. Where Terraform touches secrets, short-lived credentials, or service accounts, the safer pattern is to bind approval to workload identity and issue access just in time rather than letting long-lived credentials persist across pipelines. This is especially important when infrastructure changes can create new NHI attack paths.
- Validate plans before merge, not only before apply.
- Separate who can author a change from who can approve a change.
- Use ephemeral credentials for pipeline execution and revoke them after the task.
- Require drift detection and post-deployment verification so approved changes match reality.
- Block resource creation that would expand secrets exposure or privilege scope without explicit review.
NHIMG guidance on DeepSeek breach reinforces the broader lesson: exposed credentials and uncontrolled infrastructure paths are exploitable long before a final deployment gate is reached. The practical failure point is environments where Terraform plans are treated as advisory, because then the apply step becomes a rubber stamp for decisions already made elsewhere.
Where the Standard Control Model Breaks Down
Tighter approval control often increases pipeline friction, requiring organisations to balance delivery speed against the risk of hidden infrastructure drift. That tradeoff becomes sharper in large, multi-account environments, where a single Terraform repo may manage separate blast radii, multiple business owners, and different policy requirements.
Best practice is evolving, but there is no universal standard for how much logic should live in pre-merge checks versus pre-apply enforcement. The safest approach is to treat deployment-time guardrails as the last line of defense, not the primary one. If a team waits until apply to reject a change, it may already have exposed variables, planned secret mounts, or queued privilege expansions that should have been blocked earlier. This is exactly where governance on paper diverges from operational reality.
The model also breaks down when human reviewers cannot understand the full dependency chain in a generated plan. Large module stacks, remote state, and shared service principals can hide the actual effect of a change. That is why deployment-only review is weakest when the infrastructure change can alter identity scope, secret reach, or cross-environment connectivity.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Terraform often exposes or rotates NHI secrets too late in the workflow. |
| OWASP Agentic AI Top 10 | A1 | Policy failures mirror autonomous workflow abuse when actions are approved too late. |
| CSA MAESTRO | MAESTRO focuses on controlling agentic execution paths and tool-driven change. | |
| NIST AI RMF | AI RMF governance applies to change decisions made before infrastructure execution. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is undermined when Terraform can queue changes unchecked. |
Review Terraform for long-lived secrets and replace them with short-lived NHI credentials.
Related resources from NHI Mgmt Group
- How should security teams handle failed validation steps in Terraform deployment workflows?
- What breaks when Terraform changes are not surfaced to the team in real time?
- What breaks when secure access controls do not support common administrator workflows?
- What breaks when smart card issuance is not integrated with identity and access workflows?
