The word "hallucination" is overused in AI discourse, but it earns its keep in security tooling. A hallucinated CVE reference, a hallucinated function signature, a hallucinated dependency path — any of these, shipped as advice to an engineer on a deadline, causes harm. Grounded reasoning is reasoning whose claims map, one to one, onto artifacts in a system of record. Hallucinated reasoning is reasoning whose claims sound right. The difference is invisible in a demo and ruinous in production. Griffin AI is built on the premise that every output must be traceable to the deterministic engine underneath it: a specific SBOM component, a specific call graph edge, a specific taint trace. Pure-LLM products in the Mythos class inherit the frontier model's tendency to generate confident prose without a corresponding artifact. Over nine months of side-by-side evaluation, the most reliable predictor of whether a finding was true was whether the tool could produce an artifact when asked.
What does "grounded" mean at the token level?
When Griffin AI emits a sentence like "CVE-2023-25690 is exploitable via mod_proxy in Apache HTTPD 2.4.55 on the /billing route," each noun in that sentence ties to a record. CVE-2023-25690 ties to the NVD entry. mod_proxy ties to the call graph node. Apache HTTPD 2.4.55 ties to the SBOM component with a specific digest. /billing ties to the route declaration in your config. The engine produced each of those links before the LLM opened its mouth; the LLM's job was to compose the sentence. That's what "grounded" means architecturally — the model's degrees of freedom are reduced to phrasing and prioritization. In a pure-LLM system, every one of those nouns is a potential hallucination, because the model can generate strings that look like CVE IDs, function names, and version numbers without any grounding in the target codebase.
How do you detect hallucinated reasoning at evaluation time?
Three tests work. First, ask the tool for a call-graph citation. "Show me the edge from entry point to sink." A grounded system returns a traversal; a hallucinated system returns prose. Second, reference a CVE that doesn't exist — something like CVE-2099-00001 — and ask whether it applies. A grounded system returns "no such CVE in the feed." A hallucinated system may, disturbingly often, produce an analysis. Third, ask for a patch and rebuild the branch in isolation. A grounded patch compiles at the rate Griffin reports (73%); hallucinated patches compile at a much lower rate, often with made-up imports or wrong function arities. We've used these three tests in customer bake-offs and they cleanly separate the two architectures without requiring any vendor disclosure.
Where does hallucination come from, mechanically?
Language models are trained to produce plausible continuations of a prompt. "Plausible" means statistically likely given the training distribution. Nothing in that objective rewards factual fidelity to a specific target system. If the prompt contains the word jackson-databind and a question about deserialization, the model is primed to produce tokens about CVE-2019-12384 or CVE-2020-36518 because those CVEs were abundant in training text. Whether either CVE actually applies to the user's build is a question the model cannot answer from its prompt alone. A pure-LLM retrieval system retrieves chunks that it hopes will ground the model, but similarity retrieval does not prevent the model from overriding the retrieved chunks with higher-probability pretraining tokens. Griffin AI's engine provides structured facts, not chunks — facts the LLM is instructed to cite rather than interpret.
Does grounding limit the LLM's value?
This is the honest question. If the engine does all the factual work, what is the LLM contributing? Three things, and they matter. First, prioritization: given six true findings, which is most urgent given business context, exploitability, and blast radius? Second, explanation: turning a taint trace into a paragraph an engineer can act on. Third, remediation design: proposing a patch that respects the codebase's conventions, rather than a naive fix that clashes with the framework in use. None of those tasks require the LLM to guess facts. They require the LLM to reason over facts. That is where the 81% hypothesis accuracy and 73% auto-PR compile rate come from — the LLM is applied to the parts of the problem it is genuinely good at, and the engine handles the parts it is not.
What happens when hallucination hits production?
I have watched an engineer spend three days tracking down a CVE that a pure-LLM tool had confidently attributed to their service. The CVE was real; the attribution was not. The vulnerable function existed in a transitive dependency that their build never linked, and the tool had inferred reachability from the presence of an import in an unrelated file. Three days of engineering time lost to a confident paragraph. In other cases I've seen hallucinated patches introduce new bugs — a null check that silently drops error paths, a try/catch that swallows an exception and hides the underlying failure. Hallucination in security tooling has a specific failure profile: it looks like progress but substitutes for it.
How does grounded reasoning affect trust over time?
Trust compounds. When Griffin AI's first finding for a team is accompanied by a call-graph trace and a patch that compiles, the team updates their prior. The next finding is accepted more readily. Over a quarter, the team starts using Griffin's suggestions as drafts rather than fighting them. In pure-LLM deployments we've studied, the trend goes the other way: every false positive erodes trust, and teams start defaulting to "ignore AI findings unless a human pre-verifies." That posture negates the entire value of the tool. The 98% adversarial resistance Griffin publishes contributes to this: when red-teamers try to manipulate the system into producing unsafe outputs, the engine's constraints hold, and the team's trust does not get battered by edge cases.
Does this generalize beyond security?
We think it does. Any domain where the facts live in a structured system — code, legal contracts, medical records, financial ledgers — favors engine-grounded reasoning over pure-LLM reasoning. Security is a particularly sharp example because the cost of hallucination is immediate (developer hours, audit findings, unpatched CVEs), but the pattern is general. The frontier model's job is to reason about facts; somebody else's job is to produce facts that are true. Conflating those two roles, which is what pure-LLM products do, is an architectural error that scale alone will not fix.
How Safeguard Helps
Safeguard's engine is the source of truth Griffin AI reasons over: SBOM, call graph, taint analysis, provenance records. Every Griffin claim cites an engine artifact, and every patch goes through build-and-test verification before it reaches a developer. That is why our 81% hypothesis accuracy, 73% auto-PR compile rate, and 98% adversarial resistance numbers hold up in production. If you're evaluating a pure-LLM competitor, ask to see the citations. Grounded reasoning leaves a trail; hallucinated reasoning leaves a story.