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 real incidents. A wrong sentence in a chat window and a wrong database write share a root cause and nothing else, and treating them as the same problem is how the dangerous one gets the same shrug as the harmless one.

Factual, reasoning, and structural hallucinations are quality problems. They degrade what the agent says, and a retrieval step, a second model, or a human catches a real share of them before anything happens downstream.

Tool and permission hallucinations act instead of just stating something. A tool hallucination breaks a workflow. A permission hallucination breaks a trust boundary, and it's the one failure on this list that better model quality alone does not fix.

Making models more honest about what they don't know is useful, and we'd take it. But the fix that actually matters here is making sure a wrong belief about authority never becomes a successful unauthorized action.

That's an architecture decision, not a prompting one. Authority has to live in a layer the model doesn't control.

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, and lumping those together is the actual problem. 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.

We think the useful move is splitting "hallucination" into the five shapes it actually takes, because the fix for each one lives somewhere different. A citation checker catches a factual hallucination. Nothing catches a structural one; you design around it instead. Only one of the five, the last, is a security problem rather than a quality problem, and it's the one this post spends the most time on.

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 of those 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 different 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. It's predicting a plausible continuation of the prompt, and 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 notorious real-world examples follow exactly this pattern: lawyers who submitted briefs citing court opinions an LLM had invented, and were sanctioned for it.

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 ever sees the output. That's why the industry has already built tooling for this one specifically, and why we'd put it lowest on the list of things worth losing sleep over in an agent system. It's the type everyone already knows to check for.

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 much harder to spot than a fabricated fact would be.

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

This matters more for agents than for chat, for a specific reason: an agent acts on its own reasoning instead of just displaying it. A person reading a chatbot's conclusion can sanity-check it before relying on it. An autonomous agent executes the next step the instant the reasoning produces one. If the logic is broken, so is whatever comes after it.

3. Structural Hallucinations

You can't patch this one. It's baked into the mathematics of how these models work.

The paper LLMs Will Always Hallucinate, and We Need to Live With This argues the case formally, drawing on computability theory and Gödel's First Incompleteness Theorem: no finite training corpus can contain every true statement, and retrieving facts over an incomplete corpus is itself undecidable in general. The consequence is blunt. Every stage of the pipeline, from compiling training data to generating the final token, carries a nonzero probability of hallucinating, and no amount of scale, cleaner data, or bolt-on fact-checking drives that probability to zero.

We don't read this as a reason for despair. We read it as a design constraint. If hallucination can't be eliminated, "make the model stop hallucinating" was never an achievable goal, and any architecture that quietly depends on it is standing on sand. Everything after this point in the post assumes hallucinations will keep happening, and asks a different question: 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.

A 2025 benchmark paper, The Reasoning Trap: How Enhancing LLM Reasoning Amplifies Tool Hallucination, isolates two failure modes: agents that call a tool when none is available, and agents that call the wrong one when only distractor tools exist. The finding worth sitting with is the direction of the effect. Improving an agent's reasoning, through reinforcement learning for instance, increases the rate of tool hallucination roughly in step with the gains in task performance. A more capable reasoner is more willing to invent or misuse a tool to close a gap, because it's been optimized to produce a solution, not to admit it's missing a capability.

The operationally worst version isn't calling a bad tool. It's when the agent can't find a working one and simply 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, and the error compounds silently through everything that follows.

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 real 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, act on an instruction that violates policy. The other four failures are errors about the world, a fact, a plan, a tool. This one is an error about the agent's own authority, and because most agent frameworks execute tool calls under one broad service credential, a confidently mistaken belief is frequently all it takes to make the unauthorized action actually go through.

Take a support agent resolving a routine ticket. It decides the fastest path is pulling the customer's billing history, and because it's running 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 simply assumed it was allowed, and nothing in its path stopped it from finding out otherwise.

The mechanism, plainly: a service account had more reach than the judgment behind the request. It's the same shape as a phishing attempt succeeding against a person who clicks without checking, except the party being fooled is a credential, and a credential never pauses to think it over.

This is why 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. A better model makes fewer factual errors. It doesn't reliably make fewer permission errors, since the gap being exploited isn't a knowledge gap. It's the absence of a system that checks belief against reality before acting on it.

A Blast-Radius Model for Hallucinations

Line the five up by blast radius, how far a single error can travel 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 the only one that's 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, including ones nobody has named yet, can do.

Containing the Blast

None of the five types are going anywhere. Factual and reasoning hallucinations will keep shrinking as models and retrieval improve, and structural hallucination isn't going to zero no matter what ships next year. Tool hallucinations get contained by registries and schema checks that most teams already know how to build. 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, because we can't, and chasing that goal is a distraction from work that actually pays off. It's how to make sure a hallucination, whichever of the five it is, can't cross into permissions, policy, or trust boundaries it has no business touching.

The pieces of that answer aren't exotic: bind every agent action to a real identity, enforce least-privilege scopes, 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 before anything executes. Believe whatever it wants; the request still gets denied.