The security industry has spent the past 18 months buying AI tools on a specific implicit promise: that hallucinations are a current-generation problem, that reasoning depth will improve as models scale, and that agentic chains will become reliable enough for autonomous operation as training data and architectures mature. A recently published paper by Vishal Sikka and Varin Sikka — “Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models” — makes a formal argument that the industry is waiting for something the architecture cannot deliver.
The Sikkas are not sceptics from outside the field. Vishal Sikka holds a Stanford PhD supervised by John McCarthy, the person who coined the term “artificial intelligence.” Their argument is not qualitative. It is rooted in computational complexity theory that has been settled since the 1960s.
What the Paper Actually Proves
The core finding is that transformer-based models operate with a fixed compute budget per token. The self-attention mechanism that gives transformers their power is also what constrains them: the amount of computation a model can perform per output token is architecturally bounded. It does not scale with the difficulty of the task. A model reasoning about a three-word classification and a model being asked to reconstruct a complex multi-stage attack chain are allocated the same depth of computation.
This matters because of the Time Hierarchy Theorem — a foundational result in computational complexity that distinguishes problems by the compute required to solve them. Some problems are in complexity classes that provably require more computation than a fixed-budget architecture can perform regardless of training quality or parameter count. For these problems, transformer models will produce plausible-sounding outputs that are not derived from sufficient computation. That is not a description of a bad model. It is a description of what any transformer model will do when asked to solve a problem above its architectural compute ceiling.
The paper also addresses error propagation in agentic chains. When multiple LLM calls are chained — each using the output of the previous as its input — the error compounds rather than cancels. Longer chains do not average out hallucinations. They multiply them.
The Problem Classes Security Uses LLMs For
Security operations happens to rely heavily on exactly the split the paper identifies. Verification-class problems — is this alert consistent with known malicious patterns? does this log line match a known attack signature? is this CVE ID in our asset list? — are tasks where LLMs perform well and the architectural limits are rarely binding. Classification, triage scoring, and pattern matching against known structures are legitimate uses.
Investigation and attribution are different. Reconstructing a multi-stage attack chain from partial telemetry, determining whether a sequence of events indicates a novel attack versus benign coincidence, correlating activity across disparate data sources to form a causal narrative — these are solving-class problems. They require reasoning that builds on itself across many inferential steps. They are precisely the problem class where the fixed compute budget per token is a hard architectural constraint, not a soft one that improves with scale.
The AI SOC products being sold to security teams in 2026 are largely being sold on the promise of the second category while quietly delivering the first.
The Gap Between the Sales Deck and the Architecture
The industry framing for AI security tooling is almost universally progress-oriented: hallucination rates are dropping, context windows are growing, agentic frameworks are maturing. The implication in every vendor briefing is that current limitations are temporary — directional problems that better training will resolve.
What the Sikka paper establishes is that this framing is wrong for a specific and important subset of the tasks these tools are being deployed for. The hallucination problem in complex investigative reasoning is not a quality problem that training will eventually solve. It is a consequence of the architecture operating on a problem in a complexity class that the architecture cannot fully address. This is not an argument the vendors are making, because it does not help them close deals.
Security practitioners making deployment decisions about these tools need to hold a different model in their heads than the one the vendors are providing. The appropriate question is not “how much do I trust this tool’s outputs today versus in six months?” It is “which category of problem am I giving this tool, and is that category one where the architectural limits are binding?”
For triage, alert classification, and known-pattern matching: the tools are genuinely useful, the limits are manageable, and the efficiency gains are real. For novel attack investigation, multi-hop reasoning across sparse evidence, and autonomous agentic response chains: the limitations are not being engineered away. They are proven.
Building autonomous operational dependencies on AI tools for the second category — as a growing number of enterprise security programmes are doing — is building on a mathematical ceiling, not a temporary floor. The industry’s optimism about AI security tooling is not wrong in aggregate. It is wrong about which part of the problem the optimism applies to, and the Sikka paper gives that error a formal name.
The uncomfortable conclusion is not that AI has no place in security operations. It clearly does. The conclusion is that the current trust model — progressively extending autonomy to LLM-based systems under the assumption that limitations are temporary — is the wrong architecture for the problem. Security practitioners who understand where the ceiling sits can use these tools well. Those waiting for the ceiling to lift may wait indefinitely.