A dry run is a preview execution that tests the full release workflow without creating durable changes. In SDK automation, it can generate code, run checks, and stream build results while avoiding pull requests or publication, giving teams a safe way to inspect outcomes before release.
Expanded Definition
A dry run is a controlled preview of an automated release or deployment path that exercises the workflow without committing durable changes. In NHI and agentic automation, it is used to validate execution logic, permissions, generated artefacts, and policy gates before anything is published or activated.
Definitions vary across vendors, but the operational intent is consistent: prove that the pipeline behaves as expected while avoiding side effects such as creating a pull request, pushing code, rotating secrets, or provisioning live resources. That makes a dry run different from a test execution that only checks a single function, and different again from a full staging deployment that writes to non-production systems. In governance terms, it is a pre-change assurance step, not a substitute for runtime controls. The concept aligns closely with NIST Cybersecurity Framework 2.0 principles for validating change and reducing execution risk before production impact. NHIMG’s guidance on identity visibility and lifecycle management in the Ultimate Guide to NHIs is especially relevant when the dry run touches service accounts, tokens, or release credentials.
The most common misapplication is treating a dry run as harmless when the workflow still authenticates with production-grade NHI credentials or can trigger downstream side effects through connected tools.
Examples and Use Cases
Implementing dry runs rigorously often introduces extra pipeline complexity, requiring teams to balance release confidence against the cost of maintaining duplicate execution paths and tighter environment isolation.
- A release bot generates deployment manifests in preview mode and validates them against policy without submitting a pull request or publishing a package.
- An AI agent rehearses a remediation workflow against a sandboxed target, confirming tool calls and approval steps before any real ticket change is made.
- A secrets rotation job performs a simulated run to verify scope, sequencing, and rollback logic before touching live API keys or certificates.
- A CI/CD system executes build, lint, and signing steps in preview mode so operators can inspect the release outcome without producing a distributable artefact.
- A platform team uses a dry run to confirm which service account would be used, which permissions would be exercised, and whether the action would violate Zero Standing Privilege expectations.
For lifecycle and exposure context, NHIMG notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts. That makes preview execution especially useful when teams need to see which identities a workflow depends on before promoting it. The concept also maps to broader validation practices described by NIST Cybersecurity Framework 2.0, where verifying change outcomes is part of reducing operational risk.
Why It Matters in NHI Security
Dry runs matter because NHI failures often begin as automation mistakes, not obvious breaches. A workflow that appears safe in code review can still access secrets, overstep privilege boundaries, or call production systems if the preview mode is poorly implemented. That is why dry runs are useful for catching identity, policy, and release issues before they become incident response problems.
NHIMG research in the Ultimate Guide to NHIs shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges. Those conditions make preview execution a governance control as much as a delivery convenience, because it exposes where an automated process would reach, what it would change, and whether the identity behind it is already over-permissioned. In practice, dry runs help confirm least privilege, environment separation, and change approval logic before a release path becomes irreversible. Once a misfire creates an unwanted pull request, rotates the wrong credential, or publishes a broken artefact, the organisation has already crossed from planning into incident containment. Organisations typically encounter the true value of a dry run only after an automation failure or secret exposure, at which point the preview path becomes operationally unavoidable to reconstruct what would have happened.
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 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 | Dry runs help expose secret handling and identity misuse before release. |
| NIST CSF 2.0 | PR.IP-1 | Change management requires validating workflows before production impact. |
| NIST Zero Trust (SP 800-207) | PL-2 | Zero Trust planning depends on proving identity and policy behavior before trust is granted. |
| NIST SP 800-63 | AAL2 | Assurance levels shape how strongly automated actors must be authenticated. |
| CSA MAESTRO | TRM-01 | Agentic systems should be tested for tool-use and execution risk before release. |
Confirm preview tooling uses appropriate authentication assurance before any sensitive action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
