Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.vigolium.com/llms.txt

Use this file to discover all available pages before exploring further.

Vigolium is a powerful offensive security tool. Two parts of the system are intentionally permissive so they can do their job, and you should understand the trade-offs before running them on a machine you care about.

​
Agent mode runs with no sandbox

Agentic modes (vigolium agent autopilot, swarm, vigolium-audit, piolium, audit, query, olium) drive an LLM with full access to Bash, Read, Write, Grep, and Glob tools on the host. This is deliberate: a sandboxed agent cannot reach the artifacts a real pentest needs, source trees, locally installed tools, captured traffic, custom wordlists, or the network paths a target is reachable on. The consequence is that, while the agent is running, it can:
  • Execute arbitrary shell commands as the user running Vigolium.
  • Read, modify, or delete files anywhere that user has access to.
  • Reach any host the machine can reach, including internal services, cloud metadata endpoints, and SSH-reachable systems.
  • Spend money on whichever AI provider’s credentials it is configured with.
If any of the above worries you, do not run agent mode directly on your workstation or a production host. Run it inside a disposable environment, a Docker container, a fresh VM, a cloud sandbox, or an ephemeral CI runner, scoped to the targets and credentials the engagement actually needs.
A reasonable baseline:
  • A dedicated container or VM per engagement, with only the scope-relevant files mounted in.
  • A non-root user with no SSH keys, cloud credentials, or password manager state inherited from your workstation.
  • Outbound network restricted to in-scope targets plus the AI provider endpoint(s).
  • AI provider keys scoped or rotated per engagement so a leaked or misused key has a bounded blast radius.
Native (non-agent) scans do not have this property, they only issue HTTP traffic against the targets you ask them to scan. The sandbox guidance above applies specifically to vigolium agent ... subcommands.

​
Extensions can run arbitrary commands

Vigolium’s extension system (JavaScript, YAML, quick checks, and snippets) is designed for full flexibility, extensions can issue HTTP requests, read and write files, shell out, hit the database API, and trigger out-of-band (OAST) interactions. See Writing Extensions for the surface area. That same flexibility means an extension loaded from a third party is, in practice, code you are choosing to run on your machine with your privileges.
Treat untrusted extensions exactly like untrusted code. Review them before loading, do not run extensions you cannot read or do not understand, and prefer pinned versions from sources you trust.
Before loading an extension you did not write:
  • Read the source. JS and YAML extensions are plain text, there is no obfuscated bundle step.
  • Check what it shells out to, what URLs it contacts, and what files it touches.
  • Run it first against a throwaway target in a sandboxed environment (see the agent-mode guidance above).
  • Pin to a specific version or commit instead of “latest”, so an upstream compromise does not silently roll out to your scans.
The same caution applies to YAML and JS modules dropped into your modules directory by other tooling, or to extension bundles shared during an engagement, they execute with the same privileges as Vigolium itself.

​
Authorized use only

Vigolium is intended for authorized security testing, audits, CTFs, and research against systems you own or have explicit permission to test. You are responsible for ensuring your use complies with all applicable laws and contracts. The authors provide no warranty and disclaim liability for misuse.

​
Reporting a security issue

If you discover a vulnerability in Vigolium itself, please report it privately to [email protected] rather than filing a public issue, so a fix can be shipped before details are disclosed.