Rebuild the pipeline so the object under review is the object under execution, or add integrity gates that verify every generated file before use. Where that is not possible, remove write access from non-build identities and shorten artefact lifetime as much as practical.
Why This Matters for Security Teams
When runtime artefacts can be changed after review, the control you approved is no longer the control that executes. That gap undermines code integrity, deployment trust, and incident response, especially in build and release pipelines where a signed-off package can be replaced, patched, or reconfigured before launch. NIST guidance on integrity, configuration management, and least privilege in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because the real issue is not review alone, but preservation of the reviewed state.
Security teams often miss this because the artefact looks “approved” in change management, while execution happens elsewhere through a mutable deployment step, shared file system, or orchestration layer. That creates a practical trust problem: the review record says one thing, but the system may run another. In practice, many security teams encounter artefact tampering only after a failed audit, an unexplained production change, or a compromise that used the deployment path rather than the source repository.
How It Works in Practice
The safest pattern is to make the object under review identical to the object under execution. That usually means building once, storing an immutable artefact, and promoting that same artefact through test, staging, and production without rewriting it. If transformation is unavoidable, then each generated file needs an integrity check before use, with a verifiable hash, signature, or policy gate that blocks execution when the artefact has changed.
Operationally, teams should treat artefact mutability as a privilege issue as much as a build issue. Only trusted build identities should be able to create or publish release artefacts, and non-build identities should have read-only access wherever possible. A practical implementation often includes:
- immutable artefact repositories with retention aligned to rollback and audit needs
- cryptographic signing of build outputs and verification at deployment or startup
- separation between build, release, and runtime identities
- policy checks in CI/CD that reject unsigned, altered, or untracked files
- short-lived artefacts for sensitive environments so stale files cannot be reused quietly
For containerised and cloud-native systems, this also means checking the final image or manifest that actually runs, not just the source that generated it. Guidance from the CISA Secure by Design initiative aligns with the same operational principle: make insecure post-build change harder by design, not by after-the-fact review. Best practice is evolving for agentic and AI-assisted pipelines, but the core control remains the same: execution should be bound to verified state, not mutable convenience. These controls tend to break down when shared storage, manual hotfixes, or late-stage configuration injection are allowed because the last write wins over the reviewed build.
Common Variations and Edge Cases
Tighter artefact control often increases build friction and release overhead, requiring organisations to balance deployment speed against tamper resistance. That tradeoff is especially visible in environments that rely on generated configuration, ephemeral jobs, or third-party packaging steps.
There is no universal standard for every delivery model yet. In highly automated platforms, teams may accept limited runtime mutation if each change is revalidated and logged before use. In regulated or high-risk environments, current guidance suggests avoiding mutable release artefacts altogether and using immutable promotion paths instead. The more sensitive the workload, the less acceptable it is for a runtime system to rewrite what was reviewed.
Edge cases often appear in blue-green deployments, serverless builds, and cluster bootstrap workflows, where the “artefact” is spread across image layers, templates, secrets, and init scripts. In those cases, the review boundary has to include every executable or loadable component, not only the primary binary. If a process can fetch or alter dependencies at launch, then the integrity control must cover that last-mile behaviour as well.
The practical question is not whether an artefact was reviewed, but whether execution can still be tied to that exact reviewed state. Where that cannot be guaranteed, the safer answer is to narrow write access, shorten lifetime, and force verification before use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least-privilege limits who can alter artefacts after review. |
| NIST AI RMF | AI governance matters when pipelines generate or modify execution artefacts. | |
| MITRE ATT&CK | T1027 | Obfuscated or altered artefacts can hide malicious changes in delivery pipelines. |
Restrict write access to release artefacts and separate build, release, and runtime permissions.
Related resources from NHI Mgmt Group
- What should teams do in the first 24 to 72 hours after discovering a compromised AI agent runtime?
- What should identity teams review after a deception hit is confirmed?
- What should identity and security teams review after a DNS record change?
- What should IAM teams review after an AI agent is granted access to Slack?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
