The plan phase is the stage where an Infrastructure as Code tool shows the changes it intends to make before any infrastructure is modified. It gives teams a chance to review impact, compare expected versus actual state, and apply policy checks before execution.
Expanded Definition
In infrastructure as code workflows, the plan phase is the reviewable preview that shows what a tool intends to create, change, or destroy before execution. For NHI and agentic systems, that preview is more than a convenience. It is a control point where teams can inspect secret usage, permission drift, dependency changes, and unintended access paths before any state change is applied. In practice, the plan phase supports policy-as-code checks, separation of duties, and change approval workflows aligned to the NIST Cybersecurity Framework 2.0. Definitions vary across vendors on how much drift detection, provider simulation, or policy evaluation is included, so organisations should treat the term as workflow-specific rather than universally standardised.
Within NHI governance, the plan phase is especially useful for identifying when an AI agent, service account, or automation pipeline is about to receive broader access than intended. NHI Management Group treats this as a pre-execution checkpoint for verifying that the intended state matches access policy and operational intent, as discussed in the Ultimate Guide to NHIs. The most common misapplication is treating a plan as a harmless report, which occurs when teams approve changes without reviewing secret exposure, privilege escalation, or downstream identity impact.
Examples and Use Cases
Implementing the plan phase rigorously often introduces review overhead, requiring organisations to weigh faster delivery against stronger assurance that the change will not expand NHI risk.
- A platform team reviews a Terraform plan and catches a service account policy that would grant write access to an entire storage bucket instead of a single path.
- A CI/CD pipeline blocks execution when the plan reveals a new API key would be injected into a runtime environment without an approved secrets manager.
- An identity engineer compares the plan output with the intended IAM model to confirm an AI agent only receives the tool permissions needed for one task.
- A security reviewer uses plan output to spot drift between the declared state and live cloud permissions before a deployment window closes.
- A governance workflow requires sign-off when the plan shows infrastructure changes that would expose sensitive automation endpoints to a broader network segment, consistent with guidance in the Ultimate Guide to NHIs and the review-oriented change controls described in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
The plan phase matters because NHI failures often begin as small configuration changes that later become standing access, secret sprawl, or unintended automation authority. In the NHI Management Group research base, 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage. That makes pre-execution review critical for spotting privilege expansion before it becomes an incident. A strong plan review also helps enforce Zero Trust expectations by validating that each infrastructure change preserves least privilege and avoids unnecessary trust propagation.
This is where the plan phase supports governance over service accounts, API keys, certificates, and agent tool access, not just cloud resources. It provides a practical checkpoint for catching secret placement in code, permission inheritance, and unintended federation changes before they are live. The discipline aligns well with the risk-based approach in NIST Cybersecurity Framework 2.0 and the broader NHI governance guidance in Ultimate Guide to NHIs. Organisations typically encounter plan-phase urgency only after an unapproved change has already expanded access or exposed a secret, at which point the term 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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Plan review helps catch secret exposure and access drift before infrastructure changes land. |
| NIST CSF 2.0 | PR.AC-4 | Plan phase supports least-privilege validation before access or infrastructure changes are executed. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification, and plan review is a pre-change verification point. | |
| CSA MAESTRO | Agentic workflows need pre-execution policy checks before tools or permissions change. | |
| NIST AI RMF | AI risk management emphasizes mapping and evaluating changes before deployment and use. |
Inspect planned changes for secret handling, privilege growth, and unintended NHI exposure before approval.
Related resources from NHI Mgmt Group
- How should security teams plan a SAML to OIDC migration?
- How should security teams phase out password-based authentication without disrupting operations?
- How should security teams phase out SMS OTP without breaking access?
- What is the difference between containment and recovery in an incident response plan?
