OWASP LLM09:2025 Misinformation is the risk that a language model produces false or misleading content that looks credible, and people or systems act on it. Engineering leads reduce it by grounding answers in trusted sources, validating key outputs automatically, labeling AI content, and keeping humans in the loop for high-stakes decisions.
What does OWASP mean by misinformation?
OWASP describes misinformation as false or misleading output that appears credible. The main cause is hallucination: when the model lacks the facts, it fills the gap with statistically plausible text. Bias in training data and incomplete information add to it.
The second cause is on your side of the screen. OWASP names overreliance, where users trust output without checking it. A model that is wrong 5 percent of the time is a small problem if everyone verifies and a large one if nobody does.
Where does it show up in engineering work?
OWASP lists four common examples. Each maps to something you can inspect in your own team.
- Factual inaccuracies. A support bot states a refund policy that does not exist.
- Unsupported claims. A summarizer adds a conclusion the source never made. OWASP flags health and legal contexts as especially sensitive.
- Misrepresented expertise. The model sounds sure about a topic it handles poorly, so users skip a second opinion.
- Unsafe code generation. The model suggests insecure code or a library that does not exist. If a developer installs a name the model invented, they have added an unvetted dependency by accident.
That last one is the case security teams feel first, because it lands in the build. A package name from a chat window should go through the same checks as any new dependency: does it exist, who maintains it, what does it pull in, does it have known vulnerabilities.
How do you reduce it?
OWASP lists eight mitigation strategies. Here they are as decisions a lead can make.
Ground the answers. Retrieval-augmented generation pulls from verified sources at answer time, so the model quotes instead of recalling. It narrows the gap but does not close it, so the sources themselves need an owner and a review date.
Validate automatically. For outputs that feed other systems, such as generated configs, SQL or dependency lists, add machine checks before anything runs. A schema check or a package registry lookup costs little and catches a real class of error.
Keep a person on critical calls. OWASP recommends cross-verification and trained human review for critical information. Decide up front which outputs count as critical, and write the list down.
Say what the tool cannot do. Label AI-generated content, state reliability limits and the intended use in the interface, and teach users that independent verification is expected.
Tune the model with care. Fine-tuning and embeddings can improve quality for a narrow domain. Treat them as one layer, not the fix.
What to do
- List every place an LLM output reaches a user, a customer or a system. Include internal chat tools.
- Mark each as low, medium or high stakes. High means money, health, legal exposure, or code that ships.
- For high stakes outputs, require a named human reviewer or an automatic validator before use.
- Route any package, image or action name suggested by a model through your normal dependency checks before install.
- Add a visible label and a one line limitation note to each AI feature.
- Give the answer sources an owner and a review date if you use retrieval.
- Run a short training session for users on what these tools get wrong in your domain.
- Test with a set of questions you know the answers to, and rerun it after each model or prompt change.
Where does a dependency scanner fit?
Only in one corner of this risk: the unsafe code and phantom library case. If a model suggests a package, scanning the resulting dependency tree for known vulnerabilities and checking whether a flagged function is actually reachable from your code tells you what the suggestion cost you. It does not tell you whether the model's prose was true. Everything else on the list needs process and review.
Quick check
Is a hallucination the same as misinformation?
Not quite. Hallucination is the model behavior, the fabrication of plausible content. Misinformation is the resulting risk to your application when false output is trusted and acted on.
Does retrieval fix the problem?
It helps, because answers are tied to trusted sources, but OWASP lists it alongside human oversight and automatic validation, not as a replacement for them.
Why is this a security issue and not only a quality issue?
OWASP notes consequences including security breaches, reputational damage and legal liability. A fabricated library name or insecure code suggestion is a direct path into your software.
Sources
Last reviewed: 18 October 2026.
