DEV Community

jomynn
jomynn

Posted on

Building an Offline AI Security Scanner That Doesn't Hallucinate Findings

#ai #security #cybersecurity #llm

How AiSec Studio pipes every scan through parser → rule engine → knowledge graph before a local LLM ever sees it — and why that order matters. 60-second Auto Scan demo included.

Most "AI-powered" security scanners work the same way under the hood: grab the target's code or HTTP responses, stuff them into an LLM prompt, and ask it to find vulnerabilities. It demos well. It also hallucinates constantly — the model pattern-matches on plausible-looking code and reports things that were never exploitable, or never there at all.

I've been building AiSec Studio, an offline AI security research platform, around the opposite assumption: the LLM should never be the thing that discovers a vulnerability. It should only reason over what a deterministic system already found.

Here's a 60-second walkthrough of the Auto Scan lane — target URL in, reviewed report out — followed by how the pipeline behind it is actually built.

The pipeline 

Parser → Rule Engine → Knowledge Retrieval → Summarization → LLM → Reasoning → Finding → Report
Enter fullscreen mode Exit fullscreen mode

Every stage exists to keep the model away from raw, untrusted input and away from the job of deciding something is a vulnerability.

1. Parse before you analyze

Before any AI touches a target, the code goes through Roslyn (for .NET) or Tree-sitter (everything else) to extract:

  • AST
  • Call graph / dependency graph
  • Controllers, services, routes
  • Authentication and authorization wiring
  • Configuration

This is the same reason a compiler front-end exists before an optimizer runs — you don't want probabilistic reasoning operating on unstructured text when a deterministic parser can hand you a structured graph instead.

2. Rule engine does the actual discovering

Vulnerability discovery is a deterministic-rules job, not an LLM job:

  • Secret detection
  • JWT validation (including algorithm-confusion, CWE-347)
  • Header / cookie / CSP / CORS analysis
  • SQL and XSS pattern detection
  • Dependency and configuration analysis

None of this requires a model. It requires correct rules, and it's auditable — you can point at exactly which regex or AST pattern fired for a given finding.

3. Everything lands in a per-engagement Knowledge Graph

Pages, APIs, JS bundles, auth flows, technologies, and findings all get cross-linked by canonical route into one persistent graph per engagement. This is what lets risk propagate — a leaked JWT secret on one endpoint and an IDOR on a related endpoint aren't two isolated findings, they're connected nodes with compounding risk.

It also means re-scanning is incremental: unchanged parts of the graph don't get re-analyzed.

4. The LLM only reasons over structured summaries — never raw input

This is the boundary that matters most. The local LLM (Qwen2.5-Coder or DeepSeek-Coder, served through Ollama or llama.cpp — no cloud API, ever, at any point) is only handed:

  • Structured summaries from the rule engine + knowledge graph
  • Never raw HTTP responses
  • Never raw bundles
  • Never raw source dumped wholesale

Its job is explanation and correlation: why does this finding matter, what's the business impact, which of these twelve findings should a human look at first, how should the final report read. It doesn't get to originate a finding out of nothing, because it never sees anything a finding could be originated from.

5. Confidence tiers instead of confident-sounding guesses

Every finding is tagged:

  • Confirmed
  • Likely
  • Possible
  • Hypothesis

If the evidence doesn't support any of those, the system returns "Needs Manual Verification" instead of inventing a conclusion. A finding without evidence, reasoning, a confidence score, a risk level, and a suggested fix isn't a finding — it's a guess wearing a report template.

What the demo actually shows

Mapped to the pipeline above, the video is:

  1. Auto Scan panel — set the target URL
  2. Scan Anonymously — passive discovery only, rule-engine + parser stage
  3. Scan All — runs discovery → analysis → active testing end to end
  4. Investigate → Finding Report — step through findings one by one, each with its evidence and confidence tier attached
  5. Report → Markdown — export the write-up
  6. Open Report — hand it straight to the OS's default viewer

Nothing in that flow leaves the machine. No target data, no code, no findings go to a cloud API at any point — that's a hard architectural constraint, not a configuration toggle.

Try it yourself: https://github.com/sendwavehub/scan-target-demo-apps
Free download: https://apps.microsoft.com/store/detail/9PJ0J7BK1M27?cid=DevShareMCLPCB

Web download:
https://sendwavehub.tech/th/apps/ai-security-studio-4

Top comments (0)