The deliberate or accidental contamination of a data source that influences system behaviour. In AI environments, poisoned content can alter retrieval results, generated answers, or downstream decisions, which makes write access, change monitoring, and source integrity part of the identity control problem.
Expanded Definition
Data poisoning is the insertion, alteration, or contamination of data that a system trusts for training, retrieval, ranking, or decision support. In AI environments, the impact can be subtle because poisoned content may look legitimate while shifting model behaviour, search relevance, or automated workflows. Usage in the industry is still evolving, but the core risk is consistent: an attacker, careless contributor, or compromised pipeline changes the inputs that shape outputs.
For NHI security teams, the issue is not only data quality. It is also identity, because the systems, agents, APIs, and service accounts that can write to the source become the real control plane. That is why guidance from NIST Cybersecurity Framework 2.0 matters here: integrity, access control, and continuous monitoring are part of the defence. In practice, data poisoning overlaps with prompt injection, source tampering, and supply chain compromise, but it is narrower than generic misinformation because it targets machine-dependent data paths rather than human readers. The most common misapplication is treating data poisoning as a model-only problem, which occurs when teams ignore write access to upstream datasets, indexes, or shared knowledge stores.
Examples and Use Cases
Implementing data poisoning controls rigorously often introduces friction in content pipelines, requiring organisations to weigh faster data ingestion against stronger review, approval, and rollback processes.
- A retrieval-augmented generation system ingests a contaminated policy document, and the assistant begins returning outdated or unsafe guidance because the index trusted the source without integrity checks.
- A compromised CI/CD service account writes malicious examples into a training set, causing the model to learn false associations that only appear after deployment.
- A third-party knowledge feed is altered upstream, so an internal agent cites fabricated facts during workflow automation; this is especially relevant given the third-party exposure patterns highlighted in the Ultimate Guide to NHIs — Key Research and Survey Results.
- An analyst upload folder is writable by too many service accounts, and a low-trust contributor overwrites reference data that downstream detection logic depends on.
- A poisoned vector store entry changes similarity search results, producing unreliable recommendations even though the model weights were never modified.
These scenarios align with the broader governance emphasis in NIST Cybersecurity Framework 2.0, especially where protect and detect functions depend on trustworthy inputs.
Why It Matters in NHI Security
Data poisoning is an NHI issue because the entities that write, sync, label, or enrich data often have broader privileges than the people who review the outputs. When those non-human identities are over-permissioned, poorly rotated, or left unmonitored, a poisoned record can persist long enough to shape multiple downstream decisions. That is why NHI governance has to include write-path controls, not just authentication for consumers.
The scale of the problem is easy to underestimate. According to Ultimate Guide to NHIs — Key Research and Survey Results, 96% of organisations store secrets outside secrets managers in vulnerable locations, which helps explain how compromised credentials can become a data-integrity event rather than a simple access issue. Once a poisoned source is replicated across caches, embeddings, reports, or agent memory, cleanup becomes difficult and audit evidence matters. Practitioners should pair source attestation, change logs, least privilege, and reviewable rollback paths with the monitoring expectations in NIST Cybersecurity Framework 2.0.
Organisations typically encounter the consequences only after an anomalous answer, corrupted workflow, or disputed decision exposes the bad input, at which point data poisoning 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 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and access weaknesses that let poisoned data be written by untrusted NHIs. |
| NIST CSF 2.0 | PR.DS | Data security and integrity controls directly address poisoned sources and tampered inputs. |
| NIST AI RMF | AI risk management includes data validity, provenance, and monitoring for harmful contamination. |
Restrict write access for NHIs and review source integrity controls before data reaches AI systems.
