A software package, build output, or dependency reference that has been altered so consumers receive malicious or untrusted code while believing they are installing a legitimate release. The danger is highest when the artifact is fetched automatically through normal update flows.
Expanded Definition
A poisoned artifact is not just a bad package; it is a trust break in the software supply chain. The artifact may look versioned, signed, or otherwise legitimate while its payload, metadata, or dependency pointer has been altered to deliver code the consumer did not intend to install. In NHI and agentic environments, this matters because software agents, CI/CD jobs, and automation runners often fetch artifacts without human review.
Definitions vary across vendors on whether the term applies only to directly distributed packages or also to tampered build outputs, container layers, provenance records, and dependency locks. NHI Management Group treats the term broadly when the consumer relies on normal update flows and the artifact can influence runtime behaviour, credential use, or privilege boundaries. That makes it adjacent to software provenance, dependency integrity, and release-signing controls, but not identical to them. A poisoned artifact becomes especially dangerous when trust is inferred from source name, repository location, or update channel instead of cryptographic verification and build attestation. The most common misapplication is treating any malicious dependency as a poisoned artifact, which occurs when the package was never altered in transit or at release but was simply chosen by mistake or dependency confusion.
For formal control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls is often used to anchor provenance, integrity, and change-control requirements.
Examples and Use Cases
Implementing poisoned-artifact defenses rigorously often introduces release friction, requiring organisations to weigh fast automated delivery against stronger verification and provenance checks.
- A package manager fetches a dependency from a trusted registry, but the published tarball was replaced with a backdoored build that preserves the original version number.
- A CI pipeline consumes a build artifact from object storage, but the artifact was overwritten after signing and before deployment.
- A container image is updated through an automated manifest reference, yet the digest points to a tampered layer that introduces hidden credential theft logic.
- An AI agent downloads a plugin or tool bundle for execution, and the bundle has been altered to exfiltrate tokens once the agent grants it tool access.
- A release artifact is distributed through a mirror or cache, but the consumer verifies only the package name, not the checksum or provenance statement.
These cases are easier to detect when teams compare artifact identity, checksum, signature, and provenance rather than trusting repository context alone. The Ultimate Guide to NHIs is useful background because poisoned artifacts frequently become the delivery vehicle for compromised service accounts, API keys, and automated workflows. In standards-driven environments, NIST SP 800-53 Rev 5 Security and Privacy Controls helps map this risk to integrity and configuration-management expectations.
Why It Matters in NHI Security
Poisoned artifacts are particularly damaging in NHI security because non-human identities are designed to act without pause, prompting, or hesitation. If the artifact they install or execute is compromised, the resulting exposure can cascade into token theft, lateral movement, poisoned automation, or unauthorized access to downstream systems. This is one reason NHI Management Group reports that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, while 80% of identity breaches involved compromised non-human identities. When artifacts are the delivery path, the blast radius is often wider than a single host because build systems, deployment agents, and service accounts may all trust the same source chain.
That risk becomes more acute in environments where automation inherits broad privileges or where secrets are stored outside hardened managers. The Ultimate Guide to NHIs shows why supply chain integrity is inseparable from identity governance: if a poisoned artifact is executed by a privileged automation path, the compromise becomes an identity event, not just a malware event. Organisations typically encounter the operational impact only after a compromised release has propagated through CI/CD or agent execution, at which point poisoned artifact controls become 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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 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 | Covers artifact and secret integrity risks tied to non-human identity supply chains. |
| NIST CSF 2.0 | PR.DS-3 | Integrity protection maps to safeguarding software and data from unauthorized modification. |
| NIST Zero Trust (SP 800-207) | AC-4 | Trusted-path assumptions are challenged by poisoned artifacts in zero trust flows. |
| NIST SP 800-63 | Identity assurance principles inform how systems trust build and release actors. | |
| NIST AI RMF | GV.3 | AI risk governance includes supply chain and dependency integrity concerns. |
Verify artifact provenance and restrict automated pulls to trusted, signed sources.
Related resources from NHI Mgmt Group
- What breaks when AI coding agents automatically install poisoned npm packages?
- How should teams respond after a poisoned package is detected in their pipelines?
- How should security teams reduce risk from fake AI tool downloads and poisoned search results?
- Why do poisoned chat templates matter if the model weights are unchanged?
