Xalgorix: an AI pentester that re-exploits its own findings before reporting them

The verifier is the whole argument

The README states the thesis in its heading: most scanners detect, Xalgorix proves. The mechanism is a two-agent arrangement. A language model agent works through a full penetration testing methodology, and then an independent verifier re-exploits every finding before it is reported. The pitch is that you get proof rather than a pile of maybes to triage.

That distinction matters more than it first appears, because it targets the specific failure mode of agentic security tooling. A model that hypothesised a vulnerability is also the model most likely to be committed to it. Given a failed callback and a hypothesis, there is no incentive to abandon the hypothesis; there is only a tendency to reinterpret the failure. Running every candidate through a second context, with an explicit job of reproducing it rather than finding it, removes at least some of that pressure. It is still a language model making the reproduction judgement, so this is a much better filter than no filter rather than proof in any formal sense.

The repository description frames the scope more plainly: autonomous AI pentesting agents covering real time reconnaissance, vulnerability detection and exploitation orchestration, written in Go and TypeScript. That is a full methodology runner, not a wrapper around a scanner, and the toolset suggests it drives the scanners rather than replacing them.

The most recent release, v4.6.80 published 2026-09-20, is a fix in exactly this area of behaviour. Its notes describe correctly identifying coordinator agent sessions when reporting provider rate limit and quota exhaustion pauses to backend storage, and propagating upstream provider quota exhaustion and budget timeouts from sub agents and the coordinator back to pause the root session. In plain terms, a scan that ran out of API budget now stops the whole run instead of leaving a partial result that looks like a finished one.

Install is one line, and the container wants to be root

The native path downloads a prebuilt binary for Linux or macOS on amd64 or arm64, then hands you a wizard:

curl -sSL https://www.xalgorix.com/install | bash
xalgorix --setup

The setup wizard asks for a provider, a model and an API key. The README's advice on model choice is worth repeating because it sets expectations: use a current frontier model with strong reasoning, long context performance and reliable tool calling, naming the latest capable GPT, Claude or Gemini. Smaller and local models are supported but may need more supervision during long autonomous scans. The key is written to `~/.xalgorix.env` with mode 0600, and the dashboard can be launched from the wizard or later with `xalgorix --web` at `http://127.0.0.1:9137`. Local Ollama is the one provider that needs no key at all.

Docker is the second path, and it comes with a security posture you have to accept deliberately:

docker run --rm -p 9137:9137 \
  --privileged \
  -v xalgorix-data:/data \
  xalgord/xalgorix:latest

The README does not dress this up. Privileged mode gives the toolset the same host-like access it has natively as root, because Docker's default sandbox drops capabilities such as NET_ADMIN and applies a seccomp filter, which breaks iptables and route changes, ARP spoof and man in the middle tooling, tun and tap VPNs, ptrace based debuggers and masscan interface tuning. An image cannot grant itself those capabilities, so they must be set at run time. The stated intent is a disposable, network isolated scanning sandbox, with a warning never to expose the dashboard publicly without authentication.

If you would rather not run privileged, the README names the alternative: swap it for `--cap-add=NET_ADMIN --cap-add=NET_RAW --cap-add=SYS_PTRACE --security-opt seccomp=unconfined`. The compose file carries the same choice as a commented capability block.

Two operational details reward attention. The dashboard launches without an LLM key, so you can explore the interface before committing to a provider. And if you do not pass `XALGORIX_USERNAME` and `XALGORIX_PASSWORD`, a random admin password is generated and printed to the logs on first run, so the compose path includes `docker compose logs -f` specifically to catch it.

The image is a full Kali toolbox, and size is the trade

The Dockerfile explains the design choice in its first comment: the runtime is based on Kali Linux and pulls in Kali's pentest metapackages, so hundreds of offensive security tools are preinstalled, and every package manager the agent might reach for is available at runtime. The README names the ones you would expect: nmap, nuclei, httpx, subfinder, katana, ffuf, gobuster, sqlmap, masscan, dalfox and feroxbuster, with apt, go, cargo, pipx and npm kept available so the agent can install anything missing on its own.

The Dockerfile is candid about the consequences. The image is many gigabytes, carrying the full Kali toolset plus wordlists plus Go and Rust toolchains, and that is described as intentional. It also explains why it runs as root rather than treating it as an oversight: package auto-install is enabled only when the effective user id is 0, and apt, go and cargo installs need write access to system paths. The container is the isolation boundary.

So the deployment guidance is really a sentence: treat it as disposable, network isolated and root. That is workable on a throwaway VM or a dedicated scanning host. It is not workable on a laptop where the same network carries your production traffic and your credentials.

The Go dependency list backs up the browser-automation and reporting story. `github.com/go-rod/rod` is a Chrome DevTools driver, `github.com/projectdiscovery/interactsh` is the out of band interaction client used to detect blind vulnerabilities, `github.com/gorilla/websocket` handles the live dashboard channel, `github.com/charmbracelet/bubbletea` and `lipgloss` build the terminal interface, `github.com/go-pdf/fpdf` renders reports, and `gopkg.in/yaml.v3` handles configuration. A `benchmarks/` directory and a `proxies.txt.example` file at the root suggest the project measures its own agent performance and supports proxy rotation for testing across source addresses.

Go 1.26 in go.mod, Go 1.24 on the badge

A small discrepancy worth resolving before you plan a build. The README badge advertises Go 1.24 or later, and links the installation section under a Linux platform badge. The `go.mod` file in the repository says otherwise: the module is `github.com/xalgord/xalgorix/v4`, the language directive is `go 1.26`, and the toolchain line is `toolchain go1.26.5`.

That is not a cosmetic gap. If you build from source with Go 1.24, the toolchain directive will try to fetch a newer toolchain, and in a locked or air gapped build environment that fails or forces an upgrade you had not planned. The Makefile confirms a source build path is real and supported: it pins `BINARY=xalgorix`, sets `VERSION=4.6.80`, and passes `-ldflags "-s -w -X main.version=$(VERSION)"` into `go build`. The same Makefile builds the React web interface first, with `npm ci` under `webui/` and the output directed into `internal/web/static`, then compiles `./cmd/xalgorix/`.

Note the naming inconsistency that runs through this project as well. The GitHub organisation and repository are `xalgorix`, and the module path is `github.com/xalgord/xalgorix/v4` with the organisation spelled without the second x. The Docker images are published as `xalgord/xalgorix:latest` on Docker Hub and `ghcr.io/xalgord/xalgorix:latest` on GitHub Container Registry. Anyone automating a pull should not assume the image name matches the repository name.

The security posture of the source tree is worth a quick look if you fork it. The root carries `.golangci.yml`, `.govulncheck.yaml` and `.semgrep.yml`, so linting, Go vulnerability scanning and Semgrep static analysis are all configured, plus `SECURITY.md` and `CODE_OF_CONDUCT.md`. That is a more mature security practice than most projects of this size bother with.

What it costs you in model budget, and what you get back

An autonomous agent driving Kali tools against a real target consumes tokens for a long time without asking permission, and the release notes show the project actively managing that. v4.6.80 propagates provider quota exhaustion and budget timeouts from sub agents up to the coordinator and pauses the root session. The compose file and wizard also let you set the model under Settings, which is the lever you actually control.

The README's guidance points at frontier models with reliable tool calling, and it is right to. Tool calling reliability is the whole game here: an agent that mis-formats one shell command or misreads one output can spend twenty minutes chasing a state that does not exist. This is the case where a cheap model is cheap for a reason.

What you get back is a findings list where each entry survived a second agent. If that filter works, it removes the triage tax that makes people ignore scanner output, which is the single largest source of wasted security tooling spend. The screenshots listed in the README, an overview dashboard, a scan detail view and a findings view on the local 127.0.0.1:9137 dashboard, suggest the reporting is meant to be read rather than exported and forgotten.

Two caveats. There is a hosted cloud version at www.xalgorix.com with its own dashboard showing security scores and remediation metrics, which is the sane answer if running a privileged root container on your network is not something you want to own. And the project carries a residential proxy sponsor in its README with a discount code, plus a `proxies.txt.example`, which is normal for this category and worth noting when you read scan results: results obtained through a proxy reflect the proxy's vantage point, not your infrastructure's.

Repository health is strong by the usual measures. 1,109 stars, 196 forks, 2 open issues, Apache-2.0, and a v4.6.80 tag published 2026-09-20T10:49:07Z against a last push of 2026-09-20T10:49:06Z, meaning the release is essentially the tip of main.

Editorial conclusion

Xalgorix is worth an hour of setup if you have a staging target you own and no pentest budget, because the verifier step is the one piece of the design that addresses the reason people do not trust AI scanners: unreproducible findings. Most tools hand you a list of maybe-possibles and leave the sorting to you, and an agent that has just convinced itself of a vulnerability is the worst possible source for that list. Refusing to report anything a second agent could not reproduce is the right filter. The costs are the ones the README is unusually honest about. This runs as root, wants a privileged container, and is built for a disposable network isolated sandbox, so the deployment has to be thought through before the first scan rather than after. The knowledge gap between go.mod, which requires Go 1.26 with toolchain 1.26.5, and the README badge claiming 1.24+, is worth resolving yourself before you plan a build pipeline. Apache-2.0 licensing, 196 forks, 2 open issues and a v4.6.80 tag published within a second of the last push on 2026-09-20 describe an actively maintained project, and the managed cloud at xalgorix.com exists if the privileged local posture is not one you want to operate. Point it at something you own, confirm the verifier rejects at least one planted false positive, and only then point it at anything that matters.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xalgorix/xalgorix on GitHub