The 5 Types of Agent Hallucinations (and Why Permission Hallucination Is the Worst)

TL;DR

"Hallucination" is doing too much work as a word. It covers five distinct failure modes, and only two of them are the reason agents cause incidents. A wrong sentence in a chat window and a wrong database write share a root cause and nothing else.

Two of the five have published mechanisms now. Kalai and colleagues argue models guess because benchmarks reward guessing, calling the state of evaluation an "epidemic of penalizing uncertain responses." A separate 2024 paper argues from computability theory that some residual rate survives any amount of training data and coins the term "structural hallucination" for it.

The one that produces incidents is different in kind. Tool and permission hallucinations act instead of stating. And the measurement that should worry anyone hoping to fix this with better models runs the other way: strengthening reasoning through RL raised tool hallucination in step with task performance, and every mitigation tested traded utility for reliability.

We're not claiming model quality is irrelevant. It shrinks three of the five. It does not shrink the fifth, because the gap there isn't knowledge, it's that nothing checked the agent's belief about its own authority against a record outside the model.

So put the authority check outside the model. NIST's zero-trust tenets already say it in one line: authorization is "dynamic and strictly enforced before access is allowed."

Overview

"Hallucination" gets used for everything from a wrong date in a chat reply to an agent deleting a record it had no business touching. A chatbot's only output is text on a screen, so a wrong answer is bounded by whoever reads it next. An agent's output is behavior: an API call, a database write, a message handed to another agent. The same underlying error now propagates through a system instead of stopping at a screen.

Splitting the word into the five shapes it takes is worth doing because the fix for each one lives somewhere different, and because the literature on each one is separate. A citation checker catches the first. A computability argument says the third can't be removed. A 2025 benchmark says the fourth gets worse as models get smarter. Only the fifth is a security problem rather than a quality problem.

They form a rough ladder. Take a support agent working a routine ticket. It can misstate a policy (factual), draw the wrong conclusion from a correct policy (reasoning), do either no matter how good the model gets (structural), invent or misuse a tool while trying to close the ticket (tool), or act as though it's allowed to read a record it isn't (permission). Same agent, same ticket, five ways to go wrong, each one closer to the real world than the last.

1. Factual Hallucinations

The most familiar kind: the agent states something false with full confidence. A misquoted regulation, an API that doesn't exist, a financial figure invented rather than looked up, a citation to a case that was never decided. None of this is the model lying. A well-formed sentence about a nonexistent case is exactly as easy to generate as one about a real case, because the model learned the shape of a citation, not the fact underneath it.

The most useful recent framing of why this persists is economic rather than architectural. Kalai, Nachum, Vempala and Zhang argue that models hallucinate because "language models are optimized to be good test-takers, and guessing when uncertain improves test performance." Under binary scoring, an abstention and a wrong answer score identically, so a model that says "I don't know" is strictly punished for honesty. Their prescription isn't a better architecture, it's changing how benchmarks score uncertainty.

OWASP files the downstream harm under misinformation rather than hallucination, and its two examples are worth keeping in mind because they're the ones with real consequences: fabricated legal cases that lawyers relied on in court, and attackers who publish malicious packages under names coding assistants commonly invent, so that the hallucination becomes a supply-chain compromise.

Factual hallucinations are also the most tractable, because they're verifiable. A retrieval step, a citation check, or a second model grading the claim against a source catches a real share of them before a user sees the output. This is the type everyone already knows to check for, and we'd put it lowest on the list of things worth losing sleep over.

2. Reasoning Hallucinations

Here the individual facts can all be correct and the conclusion still wrong. The model builds a flawed chain of logic on top of true premises, and because each link looks locally reasonable, the failure is harder to spot than a fabricated fact.

Take an agent reconciling two financial reports. It reads both totals correctly, correctly identifies the gap, then confidently attributes that gap to a currency conversion that never happened, because that's a plausible-sounding explanation rather than one the data supports. Every fact it cited was real. The reasoning connecting them was fiction.

The obvious defence is to have the model check its own chain, and that defence has been measured. Huang et al. removed the oracle labels earlier self-correction papers relied on and found accuracy fell: GPT-3.5 went from 75.9 to 74.7 on GSM8K over two rounds of self-review, and from 75.8 to 41.8 on CommonSenseQA. Their diagnosis is the sentence to remember here. "LLMs cannot properly judge the correctness of their reasoning."

That matters more for agents than for chat, for a specific reason: an agent acts on its own reasoning instead of displaying it. A person reading a chatbot's conclusion can sanity-check it. An autonomous agent executes the next step the instant the reasoning produces one.

3. Structural Hallucinations

You can't patch this one out. LLMs Will Always Hallucinate, and We Need to Live With This argues the case formally, drawing on Gödel's First Incompleteness Theorem and undecidability results including the halting, emptiness and acceptance problems, and it coins "structural hallucination" for the residue. The claim is that this "cannot be eliminated through architectural improvements, dataset enhancements, or fact-checking mechanisms," because every stage of the pipeline "will have a non-zero probability of producing hallucinations."

Worth being precise about what that does and doesn't establish, because it sits alongside the Kalai argument rather than replacing it. One is a statement about incentives that predicts hallucination will decline if scoring changes. The other is a statement about computability that predicts a floor no scoring change reaches. Both point the same way operationally: plan for a nonzero rate.

We read this as a design constraint, not a reason for despair. If hallucination can't be driven to zero, "make the model stop hallucinating" was never an achievable goal, and any architecture quietly depending on it is standing on sand. Everything after this point assumes hallucinations keep happening and asks what happens next.

4. Tool Hallucinations

This is the first point on the list where hallucination stops being a sentence and starts being an action.

The Reasoning Trap, accepted to ACL 2026, isolates two failure modes with a diagnostic benchmark called SimpleToolHalluBench: agents that call a tool when none is available, and agents that call the wrong one when only distractor tools exist. Three findings there are load-bearing. The relationship is causal, not incidental: "progressively enhancing reasoning through RL increases tool hallucination proportionally with task performance gains." It isn't overfitting, because training on non-tool tasks such as mathematics still amplifies it afterwards. And it is method-agnostic, appearing under supervised fine-tuning and even when step-by-step thinking is merely elicited at inference time.

The mitigation result is the uncomfortable one. Prompt engineering and direct preference optimisation both work, and both cost you capability: the paper reports "a fundamental reliability-capability trade-off: reducing hallucination consistently degrades utility." So the usual reassurance, that the next model generation will quietly fix this, points the wrong direction. A more capable reasoner is more willing to invent or misuse a tool to close a gap, because it was optimised to produce a solution rather than to admit a missing capability.

The operationally worst version isn't calling a bad tool. It's the agent that can't find a working one and narrates a result instead: reporting that an email went out, a refund was issued, a ticket was closed, when none of it happened. Downstream steps treat that narration as fact.

A tool hallucination is, at least, containable at the gate. A strict registry, schema validation, and rejecting any call to an unregistered function stop most of them before they run. That containability is exactly what the next category loses.

5. Permission Hallucinations

This is the one that matters most, because it's the only failure on this list where the model doesn't have to be wrong about anything in the world to cause damage. It only has to be wrong about itself.

Permission hallucination is what happens when an agent assumes it's allowed to do something it isn't: view a restricted record, call a sensitive API, forward data to another agent. The other four are errors about the world. This one is an error about the agent's own authority, and because most agent frameworks execute tool calls under one broad service credential, what the Agent Access Control Taxonomy calls aact:identity-model/shared-service-account, a confidently mistaken belief is frequently all it takes for the unauthorized action to go through.

OWASP's LLM06:2025 entry decomposes the underlying condition into three causes, and the decomposition is the useful part because each one has a different owner. Excessive functionality is extensions carrying capabilities nobody needed. Excessive permissions is more access than the intended operation requires. Excessive autonomy is insufficient verification before a high-impact action. Two of its eight mitigations are the ones we'd put first: "Execute extensions within the user's security context" and implement authorization in downstream systems rather than trusting the model's account of what it may do.

Take a support agent resolving a routine ticket. It decides the fastest path is pulling the customer's billing history, and because it runs under a service account with database-wide read access, it does exactly that, and returns another customer's financial data in its reply. No tool was invented. No fact was wrong. The agent assumed it was allowed, and nothing in its path stopped it from finding out otherwise.

The MCP security guidance describes the same shape from the credential side, listing "expanded blast radius: stolen broad token enables unrelated tool/resource access" as the first consequence of over-broad scopes, and naming as a common mistake "treating claimed scopes in token as sufficient without server-side authorization logic." That is the mechanism in one line. The agent's belief and the credential's reach were both wrong, and neither was checked against the other.

We'd rank it above every other type on this list for an enterprise deployment. Not because it's the most common; factual and reasoning hallucinations almost certainly outnumber it. Because it's the only one whose damage doesn't scale down with model quality, since the gap being exploited isn't a knowledge gap.

Telling Them Apart

In an incident review you don't get told which of the five you're looking at. You get a transcript, a tool-call log, and an angry stakeholder. These are the signals that separate them.

Table 1 — Five failure modes and the log evidence that identifies each. The bottom two rows are the only ones where something actually happened.

The row that catches people out is the boundary between tool and permission. Both end in an action, and in a transcript both can read as "the agent did a thing it shouldn't." The distinguishing question is whether the call was well-formed and accepted. A tool hallucination fails at the gate or leaves no call at all; a permission hallucination sails through, because every layer it touched was willing to serve it.

A Blast-Radius Model for Hallucinations

Line the five up by blast radius, how far a single error travels before something stops it, and they stop looking like five unrelated bugs. They're one failure tracked across five escalating containers.

Figure 1 — Five hallucination types tracked as one failure escalating through five containers. Only the last container sits outside the model entirely.

The first three are quality problems: better models, better retrieval and better evaluation shrink them, and none of that shrinking requires touching how the agent is authorized. The fourth is an integration problem, and a tool registry closes most of it. The fifth is a security problem by nature, because its blast radius isn't set by the model at all. It's set by the permissions of the identity the agent runs as, which is the one place engineering can put a hard ceiling on the damage any hallucination can do, including ones nobody has named yet.

The shape of that ceiling is not novel, which is the encouraging part. NIST's zero-trust tenets already describe it: access is granted per session, "authentication and authorization to one resource will not automatically grant access to a different resource," and "all resource authentication and authorization are dynamic and strictly enforced before access is allowed." Substitute "agent" for "subject" and the document needs no other edits.

Figure 2 — The same permission hallucination, with and without an entitlement check that the model cannot influence.

Where Fabriq Fits

Agentic Fabriq is built around the bottom row of Table 1. Credentials live in a vault per user and get attached server-side at the moment of the call, so the agent never holds the secret it would otherwise be reasoning about. Every call carries two identities, the agent and the acting user, and lands in an audit record with both, which is what makes a denied-versus-served distinction visible afterwards rather than inferred. An agent's effective tool list is the intersection of the user's scopes and the agent's, so an agent cannot reach past the person it is acting for even when it believes it can.

What it does not do is reach into the provider for you. Clearing a vault copy of a credential is not the same act as invalidating a grant upstream, so the provider's own revoke call remains yours to make.

Frequently Asked Questions

What is permission hallucination? An agent acting on a mistaken belief that it is authorized to take an action, where nothing in the path verifies that belief before the action executes. It is distinct from the other four hallucination types because the model isn't wrong about the world, only about itself, and because the damage is an action rather than a sentence.

Can AI hallucinations be eliminated? Not on the current evidence. One argument says they persist because benchmark scoring rewards guessing over abstention, which is fixable in principle. A separate argument from computability theory says a nonzero rate survives any architecture, dataset or fact-checking layer. Plan for a floor and bound what a wrong output can do.

Do better models hallucinate less? For factual and reasoning errors, generally yes. For tool hallucination, the measured effect goes the other way: enhancing reasoning through RL increased tool hallucination in proportion to task-performance gains, and it showed up even when the training data contained no tool tasks.

What's the difference between a tool hallucination and a permission hallucination? Whether the call succeeded. A tool hallucination is malformed or aimed at something that doesn't exist, so a registry and a schema check stop it. A permission hallucination is a perfectly valid call that the requester wasn't entitled to make, so only an entitlement check stops it.

Does RAG fix hallucinations? It reduces the factual class by giving the model something to ground against, and OWASP lists it first among misinformation mitigations. It does nothing for the reasoning class, where the retrieved facts are correct, and nothing at all for the permission class.

Will self-review catch a hallucination? Not reliably, and it can make things worse. Without external feedback, GPT-3.5 fell from 75.9 to 74.7 on GSM8K and from 75.8 to 41.8 on CommonSenseQA across two rounds of self-correction. Reviews that know something the writer didn't, a fresh retrieval or a validator, are the ones worth running.

How do I spot a permission hallucination in logs? Look for successful, well-formed calls whose acting user had no entitlement to the resource. That requires recording the acting user's identity alongside the agent's on every call, which is why a single shared service credential makes this class invisible as well as possible.

Is prompting the agent about its own limits a fix? It helps at the margin and it isn't a control. The authority the agent believes it has is a string in a context window, and anything that can write to that window can change it. The authority it actually has should live somewhere it cannot write to.

Containing the Blast

None of the five types are going anywhere. Factual and reasoning hallucinations will keep shrinking as models and retrieval improve. Structural hallucination isn't going to zero. Tool hallucinations get contained by registries and schema checks most teams already know how to build, and, on the current evidence, get worse rather than better as reasoning improves. Permission hallucinations are the odd one out: they don't shrink with model quality, and they're the only one of the five that turns a wrong belief into an action nobody authorized.

So the real question isn't how to make hallucinations disappear. It's how to make sure one, whichever of the five it is, can't cross into permissions or trust boundaries it has no business touching.

The pieces of that answer aren't exotic: bind every agent action to a real identity, keep scopes least-privilege and per-resource, verify tool use against actual authorization rather than the model's account of its own authorization, and audit the chain closely enough that a violation is visible instead of quietly successful. The throughline is one principle. Authority lives in the system, never in the model's head. The agent can be as wrong as it likes about what it's permitted to do, as long as a layer it doesn't control checks every action against the real identity and the real scope first.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — the identity-model term for one non-human account shared by many agents, with the blast-radius note, and the authorization-model term for evaluating each call as it is attempted.
• Why Language Models Hallucinate, Kalai, Nachum, Vempala and Zhang — the test-taker argument, binary scoring, and the "epidemic of penalizing uncertain responses".
• LLMs Will Always Hallucinate, and We Need to Live With This, Banerjee, Agarwal and Singla — the origin of "structural hallucination", the Gödel and undecidability arguments, and the nonzero-probability claim.
• The Reasoning Trap: How Enhancing LLM Reasoning Amplifies Tool Hallucination, Yin et al., ACL 2026 — SimpleToolHalluBench, the two failure modes, the causal RL result, and the reliability-capability trade-off.
• Large Language Models Cannot Self-Correct Reasoning Yet, Huang et al., ICLR 2024 — the self-correction degradation numbers and "LLMs cannot properly judge the correctness of their reasoning".
• OWASP LLM06:2025 Excessive Agency — excessive functionality, permissions and autonomy, and the mitigation list including downstream authorization.
• OWASP LLM09:2025 Misinformation — hallucination and overreliance as causes, the fabricated legal cases, and hallucinated-package supply-chain attacks.
• OWASP LLM01:2025 Prompt Injection — direct and indirect injection, and why no prevention is fool-proof.
• MCP Security Best Practices — scope minimization, expanded blast radius from broad tokens, and trusting claimed scopes as a named mistake.
• NIST SP 800-207, Zero Trust Architecture — tenets 3 and 6 on per-session access and dynamic authorization strictly enforced before access.