Vulkro AI (local)

AI assists. The scanner decides.

Vulkro ships optional AI help that runs where your code lives: a small model on your own machine, through Ollama, with no API key and no cloud in the loop. It explains findings, answers questions about your codebase, and drafts fixes. What it never does is change what the scanner found. The scan stays deterministic, the benchmark is scored with the AI off, and a drafted fix counts only when a fresh scan proves the finding is gone.

Start the 14-day trial Read the CLI reference →

Runs via local Ollama
Never changes a scan verdict
Fixes verified by re-scan

$ vulkro ai ask "which endpoints skip auth?"

Two routes accept requests without an
access check:
  POST /api/orders (orders.py:41)
  GET /api/export (export.py:12)
evidence: scan 2026-07-28, endpoint map

Grounded in the scan evidence, answered on your machine.

01 / The stance

One invariant: AI never changes a scan result.

Most of the industry now puts a model inside detection: plausible, confident, and different every run. Vulkro holds the opposite line. Detection is deterministic program analysis, the same verdict for the same code, every time. The AI layer sits beside the engine, not inside it.

The scan is AI-free

No model scores, filters, or ranks a finding. A passing scan means the same thing on every run, which is what lets a scan gate a release.

The AI is advisory

It explains, summarizes, answers, and drafts. Its output is labeled as advisory in the report and never becomes a finding on its own.

The benchmark stays clean

Every published benchmark number is measured with the AI off. The accuracy claims are claims about the engine, not about a model.

02 / What it does

Explain, answer, triage, draft. Locally.

One local model, several surfaces. Everything below works in both flagships: the core scanner and Vulkro for Salesforce.

ask

Ask questions about your codebase

Ask which endpoints skip auth, where user input reaches the database, or what changed since the last scan. Answers are grounded in the scan evidence graph, not in a model’s imagination, and cite the file and line they came from.

explain

Explain findings in plain language

Every finding already ships with a deterministic explanation. The AI tier adds context on request: what the flaw means in this codebase, and what the fix trades off.

triage

A second opinion on noisy findings

The triage tier reads a finding and its evidence and argues for or against it being real. Its verdict is recorded as advisory: it can flag a likely false positive, it cannot delete a finding.

fix --ai

Draft fixes that must prove themselves

For findings without a deterministic fix template, the local model drafts a patch. Vulkro then re-scans: the draft is applied only if the finding is gone and the file still parses. Refused drafts change nothing.

03 / Verified fixes

A receipt, not a promise.

Every AI vendor promises fixes. Vulkro’s are accepted or refused by the deterministic engine, and you see which. The claim is narrow on purpose: verified means a fresh scan no longer reports the finding and the file still parses. It does not claim your build compiles or your tests pass; your CI keeps that job.

$ vulkro fix --ai

[HIGH] SQL injection in orders.py
  draft: parameterize the query
  parse check: ok
  re-scan: finding no longer reported
  verified, fix applied

Accepted: the re-scan no longer reports the finding.

$ vulkro-sf fix --ai

[CRITICAL] SOQL injection in QuoteCtl.cls
  draft: bind the user input
  parse check: ok
  re-scan: finding still present
  refused, nothing changed

Refused: the draft did not survive the re-scan. Nothing changed.

$ vulkro fix --ai --dry-run · docs/cli/fix · docs/salesforce/cli/fix

04 / Local by default

Your hardware, your model, no key.

One command sets up the local model through Ollama. The default is a small coding model that runs on a laptop; constrained machines get a smaller fallback. There is no account and no API key for the local path, and in offline mode Vulkro allows the loopback endpoint and refuses anything that would leave the machine.

One-command setup

vulkro ai setup installs the model through Ollama from its official source, with your consent, and checks it end to end. vulkro ai status shows what is configured; vulkro ai off turns the layer off.

Sane defaults, your override

The default model is qwen2.5-coder:7b. Machines with fewer than four physical cores fall back to phi4-mini:3.8b. Any OpenAI-compatible endpoint works via a flag or environment variable if you run your own.

Offline stays offline

The offline switch that kills the scanner’s network access applies to the AI layer too: local loopback is allowed, anything beyond the machine is refused. Air-gapped machines keep every deterministic feature.

$ vulkro ai setup · $ vulkro-sf ai setup · the full command reference

05 / Where the line is

What the AI does not do.

Clear limits, stated as design decisions.

It does not detect

No finding is created, scored, suppressed, or reordered by a model. If the deterministic engine misses a flaw, the AI will not paper over it, and we would rather fix the engine.

It does not phone home

The local path sends nothing off the machine. If you point Vulkro at your own remote endpoint, that is your endpoint and your choice, stated plainly in the config you wrote.

Verified is a narrow claim

A verified fix means the re-scan no longer reports the finding and the file parses. Compiling, passing tests, and preserving behavior remain your build’s job.

A small model, honestly small

A 7B local model is not a frontier model. It is good at explaining, summarizing, and drafting small patches, and every one of its drafts faces the same deterministic judge before it touches your code.