Misinformation

Misinformation is the entry OWASP explicitly asks readers to slow down on, and the reason is a disagreement in their own data. Community voters placed it near the bottom of the list. The incident record placed it near the top. That is the widest gap in the 2026 process, and it runs in the direction that hurts: practitioners under-rate a failure the evidence says lands often. The final list seats it in the middle: the vote carries three-quarters of the weight, the incident data the remaining quarter, and the evidence pulled it up without overturning the vote.

OWASP’s framing of why is worth quoting in substance: when a model’s fluent, confident output drives a decision or a tool call, a wrong answer turns into a wrong action.

What the risk actually is

Misinformation occurs when an LLM or LLM-enabled application produces incorrect, incomplete, unsupported, or misleading information that appears credible enough to influence a human decision, an automated workflow, or an agent action. The core risk is that the incorrect output is trusted and acted upon. Output that nobody acts on is a quality problem. Output that authorises a refund, blocks a network segment, or installs a package is a security problem.

This is why the entry is not a subset of “hallucination”. Hallucination is one cause. In modern systems, model outputs drive tool calls, generate code, infer system state, authorise actions, and coordinate across agents, so the same false statement becomes a system-level failure with financial, security, safety, or operational consequences. In agentic systems it usually manifests as incorrect state, reasoning, or evidence consumed by a downstream component, which then acts.

Where it comes from

OWASP lists the causes without ranking them, and they are not all adversarial:

• hallucination
• incomplete or stale context
• weak grounding
• ambiguous prompts
• biased or corrupted data
• misleading summaries
• unvalidated tool outputs
• deliberate inducement by an attacker

The last one has a routing rule attached. Where the root cause is prompt injection, poisoning, or supply chain compromise, those risks should be referenced separately: see Prompt Injection and Data and Model Poisoning. LLM07 owns the resulting failure mode: a false representation that drives a harmful decision or action.

The over-reliance dynamic

OWASP names over-reliance as a key factor and states the mechanism plainly: humans and systems often treat fluent, confident, or well-structured outputs as authoritative. Fluency is a property of the generator, not of the claim. Structure (a neat table, a cited-looking reference, a JSON object with every field populated) reads as diligence and is produced at no additional cost whether the content is right or wrong.

The important part is the second sentence: in agentic architectures, this over-reliance is frequently embedded in system design. It is not a user-training problem when the pipeline itself has no step at which a claim could be rejected. If agent A’s output is agent B’s input and nothing sits between them, the architecture has asserted that A is reliable. Nobody made that decision explicitly.

Package hallucination and slopsquatting

The concrete supply-chain consequence of hallucination, and the one with a working exploit path.

Coding assistants hallucinate plausible but non-existent package names at scale (Spracklen et al., 2025). The name looks right: correct naming convention, plausible scope, plausible purpose. Attackers pre-register those hallucinated names in public registries, so an AI-suggested dependency that should have failed to resolve instead resolves to attacker-controlled code. OWASP uses the term “slopsquatting” for this, distinguishing it from typosquatting: there is no typo. The developer installed exactly the package the assistant named.

What makes it effective is that every normal check passes. The install succeeds. The import resolves. There is no misspelling for a reviewer to notice, and the suggestion came from a tool the developer trusts more than a random search result.

The chain crosses three entries, and it is worth being precise about the split:

Practically: pin and verify dependencies against an allow-list resolved from a curated registry, and do not let an assistant’s suggestion be the first point at which a package name enters your build. Verifying that a package exists is not verification - existence is what the attacker supplies.

Common examples of risk

1. Unsupported or false decision support. Incorrect or unsupported information influences business, legal, healthcare, financial, or operational decisions.
2. Incorrect state inference in workflows. The model infers that a condition has been met when it has not, triggering unintended actions. This is the agentic failure in its purest form: the model is asserting a fact about the world that the system could have checked and did not.
3. Incorrect or fabricated code and dependencies. Incorrect code recommendations, or references to non-existent packages (Spracklen et al., 2025).
4. Misleading summaries and critical omissions. Summaries omit key constraints, exceptions, timestamps, or risks. Omission is the hardest class to detect because the output contains no false statement. Everything present is true; the failure is in what is absent.
5. Adversarially induced misinformation. Attackers craft inputs that cause false claims or the omission of critical facts.
6. Cross-agent misinformation propagation. Incorrect outputs propagate across agents and workflows.
7. Forged or misattributed evidence. Fabricated or manipulated content is presented as authoritative evidence.

Mitigations

OWASP’s ten strategies are, unusually, mostly architectural, not model-level. There is no listed control that makes the model stop being wrong; every control assumes it will be and constrains what follows.

Separate claiming from acting. Claim-check-act is the central pattern: separate generation from execution and verify claims before acting. Ground claims in authoritative and current sources before any action is taken. Validate tool calls by checking arguments, authorisation, preconditions, and current state before execution. That last item defeats example 2: the workflow checks the condition itself instead of accepting the model’s inference about it.

Verify rather than trust confidence. Use verification signals, not just confidence: groundedness and consistency checks. A model’s stated confidence is generated text like any other, and OWASP’s phrasing (“not just confidence”) is a warning against building on it.

Gate the high-impact path. Enforce runtime verification for high-impact actions through approval workflows and system checks. The trade-off is throughput and reviewer fatigue, so the gate must be scoped to actions that genuinely warrant it or it degrades into rubber-stamping.

Force omissions into the open. Detect and prevent omission failures by requiring structured outputs with mandatory fields. A required contraindications field that must be populated or explicitly marked absent converts a silent omission into a visible one. It does not guarantee the content is complete. It guarantees the question was asked.

Contain the consequence. Limit blast radius with least privilege, sandboxing, and rate limits. This is the control that holds when all the verification above fails, and it is the one to build first.

Measure it. Monitor and test for misinformation: log claims, evidence, and outcomes, and test adversarial scenarios. Run adversarial evaluation and continuous testing of workflows against misleading scenarios. Logging claims alongside evidence is the specific requirement. A log of outputs without the grounding they were supposed to rest on cannot tell you whether a failure was hallucination or bad retrieval.

Calibrate trust explicitly. Distinguish verified facts from assumptions, for both human and system consumers. In a multi-agent pipeline this means the message format itself needs to carry provenance; otherwise every downstream agent re-derives the same unwarranted confidence.

Attack scenarios

1. Hallucinated dependency recommendation. A coding assistant recommends a plausible but non-existent package that an attacker has pre-registered under the hallucinated name. A developer who trusts the suggestion installs attacker-controlled code (Spracklen et al., 2025).
2. Incorrect policy decision by agent. A customer-service agent misreads a policy and approves a refund that violates the terms, causing financial loss.
3. Omission in a safety-critical summary. A clinical summary omits a drug contraindication and a clinician acts on the incomplete recommendation. Nothing in the summary was false.
4. Adversarially induced false reasoning. An attacker seeds a support forum with false remediation steps. A troubleshooting agent retrieves them and repeats them as a trusted recommendation. The attacker never touched the target system.
5. False alert triggers automated response. A security agent misclassifies normal traffic as an intrusion and automatically blocks a production network segment, causing an outage. The automation that made the agent useful is what made the error an incident.
6. Cross-agent trust failure. A retrieval agent reports a customer as identity-verified when it is not. A downstream payment agent trusts that state and releases funds. No component behaved maliciously; the trust boundary between them was never defined.
7. Fabricated task completion. An agent reports that a nightly database backup completed when it never ran. The failure surfaces later, when a restore fails because no backup exists. Detection latency here is measured in whatever interval separates the false report from the first restore attempt.

Scenarios 5, 6, and 7 have a common shape: the misinformation is about system state, it is consumed by automation, not by a person, and the harm is delayed. These are the ones that argue for validating preconditions against the system itself rather than against the model’s account of it.

Related entries

• Prompt Injection (LLM01:2026) - one route by which misinformation is deliberately induced.
• Data and Model Poisoning (LLM05:2026) - durable corruption of training data or a retrieval corpus, producing false output as a persistent property.
• Unbounded Consumption (LLM06:2026) - agents looping on a false premise consume budget as well as producing wrong answers.
• LLM04:2026 Supply Chain - registration of hallucinated package names as a supply-chain vector.
• LLM10:2026 Improper Output Handling - execution and handling of unsafe generated code.

The full list is at AI Security.