A support agent tells a customer that a product qualifies for a longer return window, cites a policy page, and recommends the next step with complete confidence. The policy page doesn't contain that rule. The response is fluent, useful-looking, and wrong. In a production system, the problem isn't limited to fabricated facts. An agent can misapply valid evidence, lose conversation state, misunderstand intent, rely on stale retrieval, cross an authorization boundary, or construct a causal explanation that the evidence doesn't support.
These LLM hallucination examples are organized around the control boundary that failed: evidence, state, intent, retrieval, time, authority, or reasoning. Each pattern includes a practical detection method, a mitigation strategy, provenance requirements, and a fail-closed design choice. Grounding, authorized retrieval, claim validation, and abstention won't make hallucinations disappear. They make unsupported outputs visible, contain their impact, and give the system a valid way to say that it can't answer.
1. Factual Fabrication and False Citations
A factual fabrication is the most recognizable hallucination pattern. The model produces a date, person, statistic, citation, product capability, or policy that sounds plausible but has no support in the system of record. A SaaS onboarding assistant might invent an API endpoint that isn't in the documentation. An e-commerce agent might tell a shopper that a product qualifies for a return policy that doesn't exist. A marketplace agent might blend one tenant's feature set into another tenant's answer when the application relies on prompting rather than enforced boundaries.
The risk isn't theoretical. A 2025 survey of hallucinations in large language models described entity-level and fact-level errors, including a model claiming that Marie Curie invented penicillin and another stating that Pluto is the largest planet in the solar system. In the same comparison, LLaMA 2 (13B) scored 27.8 on TruthfulQA, 31.4 on QAFactEval, and 34.6 on HallucinationEval, while GPT-4 was reported at 14.3, 4.7, and 9.8. Those benchmark results are not a universal production ranking. They show why teams need task-specific evaluation instead of treating fluency as evidence.
Make provenance a delivery requirement
A grounding layer should authorize evidence before generation, not attach citations after the answer has already been written. This distinction matters because a plausible citation can become a decorative explanation for an unsupported claim. Read more about what grounding is and why it matters in systems that need evidence control.
Useful controls include:
- Require claim-level provenance: Emit a claim, source document ID, paragraph or chunk identifier, and validation state rather than free prose alone.
- Reject missing evidence: If a claim has no authorized source, convert the response into an abstention or ask for more information.
- Audit canonical divergence: Compare generated claims with the current policy, product catalog, or documentation source and route mismatches for review.
- Test tenant boundaries: Send identical questions through separate tenant contexts and verify that every cited source belongs to the requesting tenant.
Practical rule: A citation is not evidence until the system has verified that the cited passage supports the specific claim.
2. Context Hallucination and State Drift
A model can fabricate conversation history without inventing an external fact. It may claim that the customer previously requested a refund, accepted a configuration, or approved an action when the actual record contains no such decision. This happens when an application reconstructs state from incomplete summaries, evicts older messages, or treats a model-generated recap as authoritative.
Consider a support conversation in which a customer asks about a refund early in the interaction and later asks about expedited shipping. After context eviction, the agent may combine those requests into a single prior instruction and respond as though the customer asked for both at once. A setup assistant may also summarize a critical configuration choice incorrectly, causing a later workflow to take the opposite path.
The control boundary here is state, not merely context length. A long prompt doesn't guarantee accurate memory, and a short prompt isn't unsafe if the application has a durable state model.
Separate records from interpretations
Store immutable conversation logs separately from an operational state object. The log answers what was said. The state object records current facts, constraints, decisions, and unresolved questions. That separation is central to reliable AI context management.
Use a state transition such as:
state_in → user_message → model_action → state_out
Then validate whether state_out contains only changes authorized by the latest user message and approved business rules. Store complete, versioned snapshots instead of relying only on deltas. When an agent answers a question about a previous interaction, it should query the memory store or event log, not infer the answer from a partial prompt.
A safe response to “What did I ask for before?” is “I don't have a record of that” when the memory system has no matching entry. That is more useful than a polished reconstruction that a support representative must later unwind.
Test context eviction deliberately. Truncate long conversations, replay state transitions, and compare the resulting decisions with the authoritative event history. The relevant metric isn't just conversational coherence. It is whether the agent preserves the correct state when context is incomplete.
3. Semantic Drift and Premise Fabrication
Semantic hallucination begins before the answer. The model misreads the user's objective, invents constraints, or answers a plausible version of the wrong question. A customer who says, “I need a solution for my team,” hasn't specified team size, budget, procurement requirements, or security needs. An agent that recommends an enterprise plan has filled an ambiguity with a premise.
The same failure appears in cost conversations. “Help me optimize costs” could mean consolidating subscriptions, removing unused seats, changing payment terms, or reducing functionality. A downgrade recommendation may be technically coherent while violating the customer's actual goal. In a marketplace, an assistant trained on predominantly B2B interactions may interpret a small seller's question through B2B assumptions and apply irrelevant discount or invoicing guidance.
The failed boundary is intent. Better retrieval won't correct a query that was routed to the wrong objective, and a more capable model may produce a more convincing answer to that wrong objective.
Capture intent as structured state
Use an intent representation with explicit fields for goal, constraints, preferences, facts, and unresolved dimensions. IntentParse is one example of an infrastructure approach that converts raw language into a validated intent state for downstream decisions. The application can ask a clarifying question when a required field is absent instead of guessing automatically.
A practical test set should include ambiguous requests and competing interpretations. For each common request, identify plausible readings and verify that the agent either selects the supported interpretation or asks for clarification. A semantic probe can also separate extraction from generation:
- Primary goal: What outcome is the user asking for?
- Constraints: What conditions did the user state?
- Unresolved dimensions: What information is necessary before recommending an action?
Generation should be coupled to the extracted intent. If the validated state says the user is cost-sensitive, the response policy should favor lower-cost options. If the state is uncertain, the policy should prevent the model from presenting a definitive recommendation.
Tenant-specific intent profiles can improve routing, but they shouldn't override the user's words or authorization. Local norms are useful priors. They aren't permission to invent a premise.
4. Retrieval Hallucination and Vector Drift
Retrieval can make an answer look grounded while still failing to support it. A RAG system may retrieve a document titled “Pricing and Discounts” for a question about whether a feature is included in a free plan. The document can discuss bulk discounts without saying anything about free-tier availability. The model then cites the relevant-looking document as proof of an answer it doesn't contain.
Cross-tenant retrieval makes the same failure a security issue. Two customers may ask about API rate limits, and semantic similarity may return one customer's configuration document for the other. An embedding model upgrade can introduce another form of drift. Queries that previously found the right policy may begin returning related but irrelevant content, while the generator continues to write with confidence.
HaluEval 2.0 contains 8,770 questions across biomedicine, finance, science, education, and open domain. It distinguishes micro hallucination, the rate of hallucinatory statements within responses, from macro hallucination, the share of responses containing at least one hallucinated statement. That distinction is operationally useful because a single unsupported claim can matter even when most of the answer is accurate.
Treat retrieval as an authorization and relevance pipeline
The retrieval-augmented generation architecture should expose an auditable chain for every answer:
query → tenant and scope check → candidate retrieval → relevance validation → quote extraction → claim validation → generation
Log the claim, source document ID, chunk ID, retrieval score, embedding version, and authorization result. Use separate tenant indexes or enforce row-level security in the vector database. A secondary relevance classifier can act as an independent gate, but its threshold must be calibrated against the target domain rather than copied blindly from another system.
Historical queries should be replayed after embedding changes. Compare retrieved documents, investigate large shifts, and require migration tests before promoting a new index. Exact quote extraction is another useful control. If the model can't locate a passage that entails the claim, generation should stop or return an evidence gap.
For a related failure pattern in generated database queries, see SQL failure modes in LLM code.

A process video can help engineering and product teams align on where relevance and authorization gates belong.
5. Temporal Hallucination and Outdated Facts
Temporal hallucination occurs when an assertion was once correct but is no longer current. The model may rely on training knowledge or an old document and present the result as present-day truth. This differs from pure fabrication. The fact existed, but the system failed to account for time.
A SaaS assistant may recommend a feature that has since been deprecated. A marketplace agent may quote an old fee from a previous pricing period. A compliance assistant may summarize an earlier interpretation of a regulation after a later decision changed the applicable requirements. These examples are hypothetical, but they expose a common architecture mistake: asking the model to remember mutable facts instead of querying the system that owns them.
The control boundary is time. A citation to a real document isn't sufficient if the document is obsolete for the decision being made.
Put freshness into the policy
Define freshness requirements by domain. Pricing and inventory may need current system state, while explanatory product documentation may tolerate older material. The application should attach last-modified timestamps and effective dates to retrieved records, then apply policy before generation.
For feature availability, use a live feature-flag or entitlement service as the source of truth. For critical policies and prices, maintain a versioned fact cache with explicit effective periods. Retrieval should check the cache first and refresh it when the record is stale.
Test the same question against date-specific snapshots. The answer should reflect the state that was valid at the selected time, not whatever the model remembers. A production monitor can compare claims with current canonical state and route stale claims to review. That monitor should distinguish an outdated source from a model that ignored a newer authorized source.
Multilingual systems need the same discipline. A 2026 study on low-resource languages reports that hallucination behavior can vary across model and reasoning configurations, and describes a retrieval-sensitive names-only setting with rates ranging from 2.50% to 37.23% across configurations. Those results don't establish a universal language ranking. They do show why a freshness and grounding policy must be evaluated in the languages and retrieval conditions where the product operates.
6. Authority Hallucination and Permission Violations
An authority hallucination may contain a fact that is true but still must not be disclosed or acted upon. The model claims knowledge of another tenant's customers, recommends an upgrade without checking contract rights, or retrieves a patient's record because the record resembles the current case. This is not merely a correctness problem. It is a failure to respect who may access what, for which purpose, and which actions require approval.
A multi-tenant marketplace illustrates the danger. An agent serving Tenant A may answer a competitive question with information from Tenant B if both tenants share a model, vector database, cache, or broad prompt context. In a healthcare workflow, a similar retrieval collision could expose another patient's treatment information. The model might describe the information accurately and still violate the access policy.
OWASP's multi-tenant AI security guidance identifies shared GPU clusters, model-serving endpoints, vector databases, inference caches, network segments, and residual GPU memory as potential tenant-exposure surfaces. It recommends logical and cryptographic isolation. The implication is clear: a tenant name in a prompt isn't an isolation mechanism.
Authorize before retrieval and action
Use a zero-trust retrieval path. Every document request should validate a signed credential, scope, tenant, resource, and purpose before content reaches the model. Log the decision, not only the document ID. Sensitive fields should be masked before generation, and high-impact actions such as upgrades, deletion, or escalation should require approval when the user's authority is insufficient.
Test isolation in continuous integration. Query Tenant A with Tenant B identifiers, use similar records across tenants, inspect cache behavior, and verify that denial responses don't leak whether a protected record exists. Treat authorization logs as immutable or tamper-evident audit records.
The correct fail-closed behavior is not “the model should be careful.” It is “unauthorized evidence never enters the generation context, and unauthorized actions never reach the executor.”
7. Reasoning Hallucination and False Causal Claims
A reasoning hallucination links premises that don't entail the conclusion. The output may contain a tidy sequence of steps, but one intermediate assumption is unsupported. A support agent may attribute a failed integration to authentication when the logs only show a timeout. A diagnostic assistant may infer a root cause from a correlated symptom. A recommendation system may claim that one business change caused an outcome when the available evidence only shows that both occurred.
This failure is harder to catch than a fabricated name because every individual sentence can sound reasonable. The evaluator must inspect the relationship between claims, not just the presence of familiar words or citations. A retrieved document can support the premises while failing to support the causal conclusion.
HalluLens separates intrinsic from extrinsic hallucinations and proposes three extrinsic tasks with dynamic test-set generation to reduce data leakage and improve evaluation robustness. That taxonomy supports a useful testing distinction: did the model contradict the supplied evidence, or did it add an unsupported conclusion beyond the evidence?
Validate the chain, not just the answer
Require the agent to identify the relevant premises, assumptions, evidence, and uncertainty before it recommends a cause or action. The system can then validate each premise against logs, policies, or retrieved passages. For high-impact workflows, use deterministic tools for calculations, rule evaluation, and database checks rather than asking the model to perform them in prose.
A synthetic hallucination-dataset study created 52,646 hallucinated instances across factual inconsistency, factual fabrication, logical inconsistency, instruction inconsistency, and context inconsistency. Fine-tuning on that corpus improved detection accuracy by 15.8% in medicine, 11.4% in law, and 11.6% in finance. The result is domain-specific, so it doesn't justify assuming the same improvement elsewhere. It does support measuring failure modes separately instead of collapsing them into one quality score.
Evidence standard: A plausible explanation isn't a root cause until the system can show which observed evidence supports each causal step.
For causal claims, allow abstention when the system can describe symptoms but can't establish the mechanism. That limitation is a product feature in sensitive workflows, not a failure of conversational polish.
7-Point LLM Hallucination Comparison
| Failure Mode | Implementation Complexity 🔄 | Resource Requirements ⚡ | Impact if Unmitigated 📊 | When to Prioritize / Ideal Use Cases 💡 | Primary Mitigation Advantage ⭐ |
|---|---|---|---|---|---|
| Factual Fabrication: Invented Facts and False Citations | High, grounding layers, fail‑closed gating, provenance tracking | High, canonical state DBs, retrieval infra, human audit | High, misleading guidance, customer loss, integration failures | Customer support, technical docs, RAG systems requiring factual accuracy | Substantially reduces hallucinations and increases trust |
| Context Hallucination: Fabricated Conversation History and State Drift | Medium‑High, persistent memory & deterministic snapshots | Medium, state DB, versioning, retrieval instrumentation | Medium‑High, broken continuity, repeated work, contradictions | Multi‑turn agents, onboarding flows, long sessions | Restores conversational continuity and prevents mistaken assumptions |
| Semantic Drift: Misaligned Intent Interpretation and Premise Fabrication | Medium, intent extraction, clarification loops, constraint enforcement | Low‑Medium, structured schemas, UI/intent capture, light classifiers | Medium, wrong solutions, ignored constraints, user frustration | Ambiguous or multi‑intent requests, multi‑tenant support | Ensures outputs align with user goals and reduces incorrect assumptions |
| Retrieval Hallucination: False Confidence in Retrieved Context and Vector Drift | High, dual retrieval, embedding versioning, per‑tenant isolation | High, vector DBs, monitoring, secondary relevance models | High, misrepresented citations, incorrect evidence grounding | RAG systems, legal/technical citations, high‑assurance retrieval | Improves citation fidelity and prevents misapplied documents |
| Temporal Hallucination: Outdated Knowledge and Time‑Aware Fact Drift | Medium‑High, timestamped retrieval, freshness policies, versioned facts | Medium, live canonical APIs, timestamp metadata, periodic reindexing | High, stale recommendations, pricing/regulatory compliance failures | Pricing, feature flags, regulatory/compliance domains | Ensures answers reflect current state and reduces stale claims |
| Authority Hallucination: Unauthorized Cross‑Boundary Claims and Permission Violations | High, auth integration, per‑call credentialing, DLP, RLS | High, auth service, per‑tenant indexes, immutable audit logs | Very High, data leaks, compliance breaches, unauthorized actions | Multi‑tenant platforms, sensitive data (health, finance), escalation flows | Prevents unauthorized disclosures and enforces least‑privilege access |
| Reasoning Hallucination: Unfounded Logical Leaps and False Causal Claims | Medium‑High, justification verification, assumption extraction, chain checks | Medium, secondary verifier models, structured reasoning logs | High, invalid causal claims, unsafe recommendations in diagnostics | Diagnostic systems, legal/medical decision support, root‑cause analysis | Improves validity of explanations and reduces false causal inferences |
Build the Control Plane Around Evidence
The seven patterns point to a common design conclusion. Hallucination prevention isn't a single prompt, model choice, or retrieval feature. It is a control plane that decides whether evidence is present, whether the evidence is authorized, whether it is current, whether it answers the user's actual intent, and whether the proposed conclusion follows from it.
Start by identifying canonical state. Define which system owns pricing, entitlements, policy versions, conversation events, customer identity, and action permissions. Then authorize retrieval before generation. A model shouldn't receive a document and only afterward learn that the user wasn't allowed to see it. Preserve provenance down to the document, chunk, quote, state version, timestamp, and authorization decision.
Next, validate claims and constraints separately. A claim can be factually supported but irrelevant to the user's request. A user intent can be correctly extracted but still lack the authority required for an action. A retrieved policy can be authentic but stale. Your evaluation matrix should therefore include unsupported claims, stale facts, state continuity, intent alignment, retrieval fidelity, authorization leakage, and causal reasoning as separate dimensions.
Evaluation needs realistic boundaries. WildHallucinations was built from 118,785 generations produced by 15 LLMs over 7,919 entities mined from one million real user-chatbot interactions, with automated fact-checking against curated web sources rather than only Wikipedia. That scope makes it useful background for thinking about realistic entity coverage, but no external benchmark substitutes for replaying your own tenant, language, policy, and permission conditions.
AletheionAGI and GQueries can be considered as a grounding and evidence-control layer alongside existing LLMs, RAG pipelines, vector databases, and memory systems. Their relevant architectural role is to support persistent memory, authorized retrieval, provenance, and fail-closed delivery. They don't replace the model, source systems, vector indexes, or application policies that your team must still configure and evaluate.
Abstention should be a valid result. If the system lacks an authorized, current source, it should say so. For implementation guidance on agentic AI security best practices, focus on the same principle that governs reliable generation: models may propose, but evidence, policy, and canonical state must decide.
AletheionAGI offers grounding and evidence-control infrastructure for teams that need claim validation, authorized retrieval, persistent state, and fail-closed behavior around existing AI applications. Visit AletheionAGI to evaluate how its research and products can support safer RAG, agent memory, and multi-tenant AI workflows.



