Vigolium: The Vulnerability Scanner That Runs an LLM Inside Go

Hook

Most AI-powered security scanners are just traditional tools with ChatGPT bolted on via API calls. Vigolium runs its entire LLM reasoning loop in-process, inside Go, and uses it to generate JavaScript attack modules dynamically based on what it discovers.

Context

Modern web vulnerability scanning lives in two disconnected worlds. Traditional DAST tools like Burp Suite and OWASP ZAP excel at crawling and fuzzing but require manual configuration for authentication flows and custom logic. Meanwhile, the recent wave of "AI-powered" security tools are essentially Python wrappers around LLM APIs that analyze scanner output after the fact—they don't integrate intelligence into the scanning process itself.

Vigolium attempts to bridge this gap with an architecture that's genuinely unusual: a Go-native scanner with 235+ detection modules, session-aware authentication primitives, and an embedded JavaScript runtime for extensibility—all orchestrated by an in-process LLM engine called pkg/olium. This isn't an LLM analyzing JSON reports; it's an agent that plans multi-phase scans, generates custom attack code targeting discovered endpoints, and triages findings while the scan is running. The project splits execution across "native" mode (traditional pipeline-based scanning with content discovery, browser spidering, and active/passive audits) and "agentic" modes (Autopilot for autonomous planning, Swarm for dynamic module generation). It's ambitious, opinionated, and shows what offensive tooling looks like when you take AI integration seriously rather than treating it as a post-processing step.

Technical Insight

The most interesting architectural decision in Vigolium is pkg/olium, the in-process LLM runtime. Most security tools that claim AI integration shell out to Python SDK wrappers or make HTTP calls to hosted APIs. Vigolium embeds the entire agentic loop—tool registry, turn-based execution, context management, provider abstraction—directly in Go. Here's what the tool interface looks like:

// pkg/olium/tool.go
type Tool struct {
    Name        string
    Description string
    Parameters  map[string]Parameter
    Handler     func(ctx context.Context, args map[string]interface{}) (interface{}, error)
}

// Example scan planning tool
var PlanScanTool = Tool{
    Name:        "plan_scan",
    Description: "Generate multi-phase scan strategy based on target fingerprint",
    Parameters: map[string]Parameter{
        "target_url": {Type: "string", Required: true},
        "auth_type":  {Type: "string", Enum: []string{"cookie", "jwt", "oauth"}},
        "scope":      {Type: "string", Enum: []string{"passive", "active", "intrusive"}},
    },
    Handler: func(ctx context.Context, args map[string]interface{}) (interface{}, error) {
        targetURL := args["target_url"].(string)
        scope := args["scope"].(string)
        
        // Extract modules based on LLM-determined scope
        modules := selectModulesByIntent(scope)
        return ScanPlan{Phases: buildPhases(targetURL, modules)}, nil
    },
}

The agent doesn't just call predefined functions—it can access the scanner's HTTP client layer with full session awareness. This matters enormously for authenticated testing. Traditional scanners treat authentication as a configuration hurdle: you record a macro, export cookies, or write custom scripts. Vigolium's HTTP abstraction maintains separate cookie jars per session and provides extraction chains for pulling tokens from arbitrary JSON paths, headers, or cookies. The result is IDOR and BOLA testing as first-class primitives rather than bolt-on features.

Swarm mode showcases where this architecture really pays off. The master agent doesn't just select modules from a static library—it generates custom JavaScript attack extensions on-the-fly based on endpoint analysis. Imagine the scanner discovers a GraphQL endpoint with a complex nested mutation. The agent calls vigolium-audit (a separate Claude/Codex harness) to perform static analysis, then synthesizes a JavaScript module that hooks into the scan phase, accesses the authenticated HTTP session, and runs mutations with privilege-level comparison:

// Dynamically generated by Swarm agent
module.exports = {
  name: 'graphql_nested_idor',
  phase: 'active',
  
  async run(context) {
    const { endpoint, sessions } = context;
    
    // Extract mutation structure from schema introspection
    const mutations = await this.introspectGraphQL(endpoint);
    
    for (const mutation of mutations.filter(m => m.hasNestedObjects)) {
      // Generate cross-session probes
      const lowPrivResult = await sessions.user.graphql(mutation, {
        id: sessions.admin.lastCreatedId
      });
      
      const highPrivResult = await sessions.admin.graphql(mutation, {
        id: sessions.admin.lastCreatedId
      });
      
      if (lowPrivResult.success && !lowPrivResult.errors) {
        this.report({
          severity: 'high',
          type: 'IDOR',
          evidence: { lowPrivResult, highPrivResult }
        });
      }
    }
  }
};

This JavaScript runs in the same embedded runtime that allows manual extension development, but the source code is generated by the agent based on discovered attack surface. It's agentic code generation targeting the scanner's own extension API—a meta-level of automation that's genuinely novel.

The native scanning pipeline itself is impressively architected. Deparos, the content discovery phase, uses fingerprint-based soft-404 detection rather than naive status code checks. It hashes response body structures and builds similarity clusters to distinguish legitimate endpoints from custom error pages. Spitolas, the browser spider, runs a full Chromium instance via CDP (Chrome DevTools Protocol) with traffic interception—not just for rendering JavaScript-heavy SPAs, but to record state transitions that can be replayed during active audit phases. This bridges the gap between static crawling and dynamic analysis: the scanner captures how a single-page app transitions between views, then later injects payloads while replaying those exact interaction sequences.

The queue architecture reveals production-grade concerns rare in open-source offensive tools. Vigolium supports three queue backends (in-memory, disk-backed, Redis) with transparent failover and scan state serialization. Long-running engagements can pause, resume across restarts, and distribute work across multiple scanner instances—all while maintaining per-host rate limiting and respecting session affinity (requests for a given session stick to the same worker that holds the authenticated cookie jar).

Gotcha

The dual-runtime build requirement is the first friction point: you need both Go 1.26+ and Bun 1.3.11+ installed. This suggests the JavaScript engine or UI components pull in Node-ecosystem tooling, which is unusual for a Go project. Most Go security tools pride themselves on single-binary distribution—Vigolium trades that simplicity for extensibility.

The bigger issue is architectural complexity in the agentic execution paths. There are three separate agent systems: olium (in-process autopilot/swarm), vigolium-audit (external Claude/Codex harness), and piolium (separate driver for Pi model). The audit dispatcher runs multiple harnesses back-to-back with post-pass deduplication, which makes reasoning about findings provenance difficult. When a vulnerability is reported, did the native scanner find it? Did the LLM generate a custom module that found it? Did the external audit harness flag it from static analysis? Without clear lineage tracking, debugging false positives becomes a nightmare.

The 235 module count lacks transparency. There's no public module directory, no CVE mappings, no false-positive baselines. Nuclei has 9,000+ templates with community validation and severity scoring. Burp Suite's scanner checks are closed-source but battle-tested across millions of scans. Vigolium's modules are a black box—you're trusting the maintainers' vulnerability research without the benefit of community review or published coverage metrics. For production security assessments, this opacity is a risk.

Server mode's transparent proxy ingestion with auto-scan-on-receive is powerful but dangerous. Point it at a high-traffic application and you could trigger runaway resource consumption. The documentation shows no concurrency limits, scan throttling, or job queuing safeguards. You'd need external rate limiting or significant code review before deploying this in any production monitoring scenario.

Verdict

Use if: You're running authenticated multi-session penetration tests and need programmable scanning logic without managing separate tools for DAST, LLM orchestration, and custom scripting. The in-process LLM runtime and JavaScript extensibility genuinely differentiate this from Burp (closed-source, expensive) and Nuclei (template-only, weak auth primitives). The agentic module generation in Swarm mode is legitimately innovative—if you're testing complex authenticated workflows where custom attack logic matters more than broad CVE coverage, Vigolium's architecture pays dividends. It's also compelling for bug bounty hunters who want AI-assisted workflow automation beyond simple payload generation and can tolerate bleeding-edge instability in exchange for programmability. Skip if: You need mature false-positive filtering (Nuclei's community templates win decisively), enterprise reporting and compliance scanning (commercial DAST tools are decades ahead), or just want fast passive reconnaissance (httpx + nuclei is simpler and faster). The dual Go/Bun build requirement and fragmented agentic execution paths make this early-stage ambitious architecture, not production-hardened infrastructure. You're trading stability for extensibility and betting that AI-driven scanning justifies the complexity tax.