LLM04: Data and Model Poisoning
Adversarial training data, fine-tune material, or RAG corpora inject harmful behaviour into the model.
Last reviewed October 2026
Why LLM04 evidence is hard
Poisoning is an integrity problem with a long fuse: the corpus is contaminated once and the behaviour surfaces much later, in front of a customer. Read this control's coverage with the numbering in mind. The probes filed against the LLM04 id are resource-exhaustion tests, carried over from the 2023 list where LLM04 was model denial of service, while the trigger-recall and memorisation probes that actually test poisoning sit under the supply-chain control. Whether your training pipeline is sound is evidenced upstream, by its own controls.
How Penaxtra maps to LLM04
The LLM04 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
LLM04 capabilities
Findings tagged with the OWASP LLM Top 10 LLM04 identifier
Penaxtra severity for this control (high)
Cross-framework identifiers attached to the same finding where controls overlap
PDF and JSON evidence export with the control identifier attached
LLM04 control coverage
Findings for LLM04 carry the OWASP LLM Top 10 LLM04 identifier along with the corresponding control identifiers in the other frameworks Penaxtra maps, so one result is reflected across each mapped framework.
Frequently asked
What is LLM04 (Data and Model Poisoning)?
Adversarial training data, fine-tune material, or RAG corpora inject harmful behaviour into the model. It is an OWASP LLM Top 10 control; Penaxtra assesses it at high severity.
How does Penaxtra test for LLM04?
The LLM04 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
Does a finding for LLM04 help with an audit?
Each finding is tagged with the OWASP LLM Top 10 LLM04 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.