Vigolium AI Scanner Puts Token Budget Decisions on Operators

Vigolium shipped its first open-source release this month with more than 250 scan modules and an in-process AI agent, called olium, that plans its own attack strategy, generates custom JavaScript extensions mid-scan, and re-checks every finding in a separate triage pass before delivering results to the operator. The project comes from a single author, Jessie Ho, and sits on GitHub under an AGPL (Affero General Public License, an open-source license that requires any entity making the software available over a network to also publish their modifications as open source) license at no cost.

The more consequential decisions in the design are not the module count. They are buried in the budget controls: how much token spend an operator permits per session, what the agent does when time runs out, and why the same JavaScript extension model that gives Vigolium its adaptability also makes a community extension marketplace a genuine security problem.

Two Modes, One Stack

Vigolium exposes two scanning paths from a single command-line interface. The first, vigolium scan, runs a deterministic multi-phase pipeline covering content discovery, browser-based spidering for single-page applications, and active and passive auditing across a module library of 251 scanners covering injection, access control, framework-specific checks, and out-of-band attack testing. That last category includes OAST (Out-of-Band Application Security Testing, a technique for detecting blind vulnerabilities like server-side request forgery and blind injection, where the payload triggers a callback to an external server rather than producing a visible response change). It is repeatable, fast, and fits a CI/CD (continuous integration and continuous delivery, the automated pipeline that tests and deploys code on each commit) gate without touching a language model. The full module breakdown is in Vigolium’s GitHub repository and architecture documentation.

The second path, vigolium agent, hands control to the olium runtime. The LLM (large language model, an AI system trained on large text datasets to generate and reason with language) harness selects its own modules, writes custom scan extensions based on what it observes in the target, and combines static source-code analysis with live dynamic testing. Eight AI providers are supported, including Anthropic’s API, OpenAI, Google Vertex AI, and self-hosted model servers via compatible endpoints such as Ollama and OpenRouter, so the tool is not tied to a single inference vendor.

The gap between the two modes is not only depth versus speed. Cost structure diverges sharply, and that divergence shapes how teams should reach for each.

Budget Caps as the First Design Choice

Every autonomous reasoning loop costs tokens. Every tool call consumes context. A session without guardrails can wander for hours on a single target and return findings that are lower quality than a tighter, shorter run would have produced. Vigolium’s operator documentation exposes four configurable caps that are set before each agentic session starts.

Ho described two failure modes from misconfigured caps in remarks to Help Net Security. Set too tight and the agent is cut off mid-investigation, returning a low-confidence stub that the operator still has to decide whether to act on. Set too loose and the agent wanders, spending tokens on diminishing returns and filling a report with noise that should not be there.

His guidance for new users is to open with the wall-clock and iteration caps set conservatively, then loosen only when a genuine investigation is visibly being cut off before reaching a conclusion. The judgment call shifts from the LLM to the human at the configuration stage, which is a more honest accounting of what agentic security tools actually provide: supervised autonomy, not full autonomy.

Triage Runs Separately from the Scan

AI-assisted security testing has a persistent credibility problem: the plausible finding that fails to reproduce. Cross-site scripting (XSS, a class of web attack in which malicious scripts are injected into pages viewed by other users) candidates that the agent reports with confidence but cannot demonstrate are worse than no finding, because they send a developer to chase a ghost and erode trust in every subsequent report from the same tool.

Vigolium handles this by making triage its own phase, run after scanning completes rather than inside it. Ho described the design at the project’s launch:

The scanner finds candidates, then a separate pass re-checks each one against its evidence.

On deduplication, the system favors transparency over quiet cleanup. The agent collapses exact copies of the same issue into a single representative entry but does not make keep-or-kill calls on borderline findings. Anything it is uncertain about is downgraded in severity and surfaced to the operator with its full evidence trail intact, including the specific request-response data that triggered the candidate. Operators see what the agent saw, rather than a curated version of it. That design keeps the audit trail complete and pushes the final judgment to a human, which is where it belongs.

Extensions Run Arbitrary Code Without a Sandbox

Vigolium’s JavaScript engine lets operators write custom scan modules using session-aware HTTP APIs (application programming interfaces, the standard connection mechanism between software services). The extensions run alongside built-in modules, accept command-line flags, and can execute arbitrary commands on the host machine. For teams scanning proprietary authentication flows, unusual API patterns, or frameworks the default module library does not cover, that extensibility is the practical point of the model.

It also creates a material trust problem for any sharing mechanism. Code signing establishes who wrote an extension. It does not tell an operator whether that extension is safe to run against a live application. Asked whether a community registry might emerge, Ho was candid about the constraints any such system would face, as covered in Vigolium’s product overview.

For a registry to function without simultaneously distributing exploits alongside scanners, three conditions would need to hold from the start:

• Provenance and code signing on every submission, establishing a traceable author record so operators know exactly who built each module and when
• An untrusted-by-default posture, with explicit operator opt-in required before any community extension is permitted to execute against a target
• Active curation rather than open submission, keeping the available set small enough to meaningfully review before any module reaches production use