Xalgorix Review: The Open-Source AI Pentester That Tries to Prove What It Finds

Most vulnerability scanners are very good at producing alerts. The harder part starts five minutes later: is the issue actually exploitable? What request proves it? Did an authorization boundary really break? Is the severity justified, or am I about to hand an engineer another afternoon of false-positive triage?

That gap between “this looks suspicious” and “here is evidence that it works” is the problem Xalgorix is trying to solve.

I approached Xalgorix the way I would evaluate any security tool before bringing it into a real workflow: I looked at the install path, the scan model, the evidence it preserves, the operational controls, the user interface, and the places where human judgment is still necessary. This is a practical product review based on the open-source project, its current interface, and its documented workflow.

The short version

Xalgorix is an Apache-2.0-licensed, self-hostable AI pentesting platform that combines autonomous security testing with a separate verification step. Its primary agent explores an authorized target through a structured methodology; an independent verifier then attempts to reproduce candidate findings before they are treated as confirmed.

The project is Linux-first, built with Go and TypeScript, and ships with a React/Vite dashboard. You can bring your own LLM provider, keep scan data inside your environment, run the open-source edition locally, or use the optional hosted service when you do not want to operate the scanner yourself.

The big appeal is not simply that “AI scans websites.” Plenty of tools can generate a long list of possible weaknesses. Xalgorix is more interesting because it treats verification, evidence, and remediation-ready output as first-class parts of the workflow.

What exactly is Xalgorix?

At a high level, Xalgorix is an autonomous web application security testing system. Instead of firing a fixed collection of templates and stopping at matches, its agent can reason through a target, call security tools, follow application behavior, test hypotheses, and move across a multi-phase methodology.

The open-source edition is the center of gravity. It runs on infrastructure you control and lets you choose the LLM behind the agent. Current provider options include OpenAI, Anthropic, DeepSeek, Gemini, Groq, Ollama, MiniMax, and OpenAI-compatible gateways such as LiteLLM. That flexibility matters for privacy, cost control, latency, and organizations that already have an approved model gateway.

Under the hood, the packaged environment includes familiar security utilities such as Nmap, Nuclei, httpx, Subfinder, Katana, ffuf, Gobuster, sqlmap, Masscan, Dalfox, and Feroxbuster. The AI layer is therefore not pretending those proven tools do not exist. It is orchestrating them, interpreting the output, deciding what to investigate next, and collecting a coherent trail of evidence.

A security workspace, not a giant “Scan” button

The self-hosted overview immediately tells you what is happening: active work, total findings, critical and high-severity counts, targets, the current methodology phase, queued scans, recent activity, system health, and a compact view of important findings.

That sounds cosmetic until a scan runs for a while. Autonomous testing can be noisy and opaque if the interface only displays a spinner. Here, the dashboard makes the system legible. I can see whether the agent is still progressing, what target it is touching, what phase it is in, and whether resource pressure is becoming a problem.

Verification, not just detection

The product's strongest design choice is the separation between discovery and verification. The primary agent performs reconnaissance, interacts with the application, calls tools, and develops candidate findings. A second verifier then attempts to reproduce those candidates independently.

Why does that matter? Because a plausible report can still be expensive. An engineer has to reconstruct the environment, identify the exact request sequence, determine whether the behavior crosses a real security boundary, and decide whether the claimed impact is possible. A scanner that emits dozens of “maybes” has not removed work; it has moved the work downstream.

In Xalgorix, a confirmed issue can retain the endpoint, technique, evidence, proof-of-concept context, severity, and remediation guidance. If the verifier cannot reproduce a result, the platform can keep that uncertainty visible instead of dressing it up as certainty.

Inside the 22-phase methodology

Xalgorix does not treat a web application as one undifferentiated attack surface. The methodology is visible in the interface and gives both the agent and the operator a shared map of the work.

• Reconnaissance — establish the target surface and initial context.
• Manual vulnerability discovery — reason about behavior that templates may miss.
• Directory and file discovery — locate hidden routes, files, and exposed content.
• CORS and cookie analysis — inspect cross-origin policy and browser security attributes.
• Authentication and session testing — examine login, session handling, and identity boundaries.
• Injection testing — probe input paths for SQL, command, template, and related injection classes.
• SSRF — test whether server-side requests can be redirected to unintended resources.
• IDOR and broken access control — check object and action authorization, not merely authentication.
• API and GraphQL testing — investigate API-specific schemas, operations, and authorization.
• File upload testing — analyze validation, storage, retrieval, and execution risk.
• Deserialization and RCE — look for unsafe object processing and code-execution paths.
• Race conditions and business logic — test timing, workflow, and state assumptions.
• Subdomain takeover — identify dangling infrastructure references.
• Open redirects — validate redirect handling and abuse potential.
• Email security — examine email-linked flows such as verification and password recovery.
• Cloud and infrastructure — inspect exposed services and configuration boundaries.
• WebSockets — test persistent connections, message handling, and authorization.
• CMS-specific checks — adapt testing to common content-management surfaces.
• Broken-link hijacking and content spoofing — find abandoned references and trust-boundary issues.
• Exploit verification — independently reproduce candidate vulnerabilities.
• Novel vulnerability discovery — reason beyond known signatures and predefined templates.
• Final report — consolidate evidence, impact, severity, and remediation.

A fixed list of phases is useful for two reasons. First, it makes coverage easier to discuss: you can see what was attempted and what remains. Second, it makes selective testing possible. A team can run a focused authorization assessment without pretending it ran a full pentest, or reserve high-impact phases for a dedicated staging environment.

What running a scan looks like

The normal workflow starts in the local dashboard at http://127.0.0.1:9137. From there, the operator creates a new scan, chooses a mode, selects phases, sets visibility filters, and optionally adds report branding.

Xalgorix supports a focused single-target workflow, wildcard or multi-target work, and DAST-style scanning. During execution, WebSocket-driven telemetry exposes tool calls, agent messages, HTTP activity, findings, errors, and LLM activity in near real time. That live feed is especially helpful when a target behaves unexpectedly or the agent spends too long in one branch.

A practical first run looks like this:

• Open the dashboard and confirm the selected LLM provider and runtime settings.
• Choose New Scan and enter only a target you are authorized to test.
• Select the scan mode and relevant phases.
• Apply a conservative rate limit and proxy configuration for the environment.
• Start the scan, then watch Overview, Scan Detail, and Live Feed for progress.
• Review candidate and verified findings before generating or sharing a report.

Reviewing findings and evidence

The Findings view is deliberately less flashy than the overview, and that is a compliment. It is built for triage: severity counts sit at the top, search and filtering are prominent, and each result exposes the vulnerability class, affected route, CVSS context, target, and time information.

For a security team, the crucial question is not whether a dashboard can color a finding red. It is whether the finding contains enough context to reproduce, prioritize, and fix. Xalgorix's reporting model is designed around evidence and proof-of-concept detail, with remediation guidance carried into branded PDF output.

Live severity filters can reduce on-screen noise during a scan, while the underlying PDF and API output can still retain the full result set. That is a sensible separation: a temporary viewing preference should not silently rewrite the audit trail. I would still expect a reviewer to validate the business impact, check whether the evidence contains sensitive data, and confirm that the recommended fix fits the application's architecture. Good automation shortens that work; it does not make ownership disappear.

Feature-by-feature review

1. Autonomous testing with real tool orchestration

Xalgorix combines LLM reasoning with established reconnaissance and exploitation tools. The agent can decide what to call next based on observed behavior rather than running every utility in a rigid order. That makes it better suited to chained logic than a template-only scanner, particularly around authentication, access control, and application-specific flows.

2. Independent exploit verification

This is the feature I would use to explain Xalgorix in one sentence. Discovery and verification are separate responsibilities. A candidate result must survive another attempt before it is promoted as confirmed. That architecture does not guarantee perfection, but it creates a healthier default than treating every heuristic match as a vulnerability.

3. Multiple scan shapes

Single-target scans are useful for a focused application review. Wildcard and multi-target workflows fit larger surfaces. DAST mode supports running against a live application, while phase selection lets teams scope work to the authorization they actually have.

4. Source-code-assisted security review

The CLI can also work from a local source tree or a Git repository. In review mode, findings are source-verified. In provision mode, Xalgorix can build and run the application and then perform dynamic testing, allowing findings to become exploit-verified when the environment supports it.

xalgorix --source ./my-app --code-scan review
xalgorix --source https://github.com/org/app.git --code-scan provision

That distinction is useful: a code pattern and a demonstrated exploit are related, but they are not the same kind of evidence.

5. Live telemetry and operational visibility

The Overview, Scan Detail, and Live Feed screens expose agent messages, tool activity, HTTP traffic, errors, findings, and LLM events. Queued and resumable work is visible, as is system health. For long-running autonomous work, this observability is not a bonus feature — it is part of the safety model.

6. Findings, reports, and remediation-ready output

Results can be filtered by severity, organized across scans, and exported into branded PDFs. Reports are intended to include an executive summary, technical evidence, proof-of-concept detail, and remediation guidance. The API gives teams a path to feed findings into their own systems instead of treating the dashboard as a silo.

7. Bring-your-own LLM and local privacy controls

Provider flexibility is one of the open-source edition's strongest operational advantages. A team can use a commercial API, route through an approved OpenAI-compatible gateway, or run Ollama locally when the model and hardware are appropriate. API credentials are stored in ~/.xalgorix.env with restrictive file permissions. The trade-off is that model choice matters: cost, latency, context limits, and reasoning quality can change scan behavior.

8. Authentication flows and notifications

AgentMail provides a test inbox for workflows that need verification emails or one-time codes. Discord and Telegram notifications can surface scan progress and results. These integrations help with realistic application journeys, but they should be configured with dedicated test identities rather than production user accounts.

9. API, CI, and pull-request workflows

Xalgorix exposes an API for automation and can fit into CI/CD. The project also offers a GitHub App for reviewing pull-request diffs, while the full scanning workflow can gate releases on verified findings. The practical advice is to start in report-only mode, understand runtime and false-positive behavior, and only then make a verified result capable of blocking deployment.

Setup guide: from zero to a first authorized scan

The open-source route is the most interesting way to understand Xalgorix because it exposes the operational choices a hosted scanner normally hides. The following setup is intentionally conservative.

Before you install

• Use Linux. The project is Linux-first. Docker is the easiest way to keep the scanning environment contained.
• Have explicit authorization. Use an application you own, a purpose-built lab, or a target whose rules clearly allow automated testing.
• Choose an LLM provider. Bring an API key for a supported cloud provider, an approved compatible gateway, or a reachable Ollama instance.
• Start with a staging target. Autonomous testing can generate load, create data, trigger emails, or exercise destructive-looking application paths.
• Decide where evidence may live. Findings, HTTP data, screenshots, and reports can contain sensitive application information.

Option A: the quick installer

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

As a general security habit, I prefer to inspect any remote install script before piping it to a shell, especially on a scanning host. If your environment requires a controlled build, use the source-build path below instead.

Run the setup wizard

xalgorix --setup

The wizard configures the LLM provider, model, and credentials. Xalgorix stores API settings in ~/.xalgorix.env and documents restrictive 0600 permissions. Ollama can be used without a cloud API key, provided the selected local model is capable enough for the workflow. This is a good time to set a cost ceiling and test a short scan — autonomous, multi-phase work can consume considerably more tokens than a single chat request.

Launch the local dashboard

xalgorix --web
# then open http://127.0.0.1:9137

Keeping the dashboard on the loopback interface is the safest default. If you expose it to another machine, put authentication and network controls in front of it. A security scanner's dashboard is not something I would publish directly to the internet.

Create the first scan

• Open Settings and verify the provider, model, proxy, rate limit, and resource controls.
• Create dedicated test credentials if the application requires authentication.
• Click New Scan, choose the target mode, and enter the authorized URL or scope.
• Select a small phase set for the first run — reconnaissance plus one relevant test family is easier to observe than all 22 phases at once.
• Add any required authentication context and report branding.
• Start the scan and keep Overview, Scan Detail, and Live Feed available.
• Stop the job if traffic, resource use, or application behavior moves outside the approved test plan.

Running Xalgorix in Docker

The simplest container command is:

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

The --privileged flag enables low-level networking and security tools, but it also gives the container broad host capabilities. I would run it on a disposable, isolated scanning machine or VM — not beside sensitive production workloads. The documented narrower alternative is:

--cap-add=NET_ADMIN --cap-add=NET_RAW --cap-add=SYS_PTRACE --security-opt seccomp=unconfined

That is still a powerful container. Apply network segmentation, restrict dashboard exposure, mount only the data you need, and monitor what the target and scanner are doing. For repeatable lab deployments, Docker Compose makes logs easier to follow:

curl -sSLO https://raw.githubusercontent.com/xalgorix/xalgorix/main/docker-compose.yml
docker compose up -d
docker compose logs -f

Pin image versions in controlled environments rather than automatically inheriting every change from latest.

Building from source

If you want to audit or modify the project, the documented build flow is:

git clone https://github.com/xalgorix/xalgorix.git
cd xalgorix
make build
sudo install -m 755 build/xalgorix /usr/local/bin/xalgorix

The source build expects Linux, Go 1.25 or newer, and Node.js/npm for the web interface. Building locally takes more effort, but it gives security teams a clear path to review dependencies, pin commits, and integrate changes into their own release process.

Safety checklist for a first real assessment

• Write down the authorized domains, IPs, methods, time window, and prohibited actions.
• Use test accounts and disposable data whenever possible.
• Start with conservative concurrency and rate limits.
• Route traffic through an approved proxy if you need a second audit trail.
• Do not enable local or internal target scanning casually. It is disabled by default and should only be enabled on a controlled, single-tenant host.
• Treat LLM prompts, scan logs, HTTP captures, and reports as sensitive security data.
• Keep the dashboard local or protect it with strong authentication and network policy.
• Review every critical claim before it blocks a release or reaches an application owner.

What about the hosted Xalgorix service?

The managed option is useful when a team wants the workflow without operating the scanning host, LLM configuration, queues, scheduling, credits, and report infrastructure. The SaaS dashboard adds a portfolio view with security score, vulnerability totals, open issues, mean time to remediate, completed pentests, issue categories, affected assets, audit logs, schedules, billing, and API access.

I see the hosted product as a convenience layer, not a replacement for the open-source story. Self-hosting provides the strongest control over runtime and evidence. SaaS removes operational work and offers a cleaner organization-level view. The right choice depends on data-handling requirements, team size, and whether managing a security scanner is a good use of your time.

What I liked most

• The verification boundary is explicit. Candidate findings and independently reproduced results are not treated as the same thing.
• The open-source edition is a real product path. Apache 2.0 licensing, self-hosting, source builds, and BYO LLM support give teams meaningful control.
• The methodology is visible. Twenty-two named phases make scope and progress easier to explain than an opaque “AI is working” screen.
• The interface supports supervision. Live telemetry, queues, system health, scan controls, and detailed findings make autonomy observable.
• It works with the existing security ecosystem. Xalgorix orchestrates established tools instead of pretending an LLM replaces them.
• The output is designed for remediation. Evidence, proof-of-concept context, CVSS information, branded reports, and API access help results travel beyond the scanner.

What could trip you up

• Model quality changes the experience. A cheaper or smaller model may save money but can reason less consistently; a stronger model may make long scans expensive.
• Self-hosting creates operational responsibility. You own isolation, secrets, upgrades, storage, access control, and monitoring.
• The Docker permissions deserve respect. A privileged security-tool container should live in a dedicated, disposable environment.
• Linux-first is not universal. Teams centered on desktop-only Windows workflows will likely prefer a Linux VM, WSL-based lab, or the hosted service.
• Autonomy is not authorization. The system can move faster than a human operator, so scope, rate limits, test accounts, and stop conditions must be decided before launch.
• Verification is stronger evidence, not absolute truth. Business impact and environmental context still need a qualified reviewer.

Who is Xalgorix for?

• Security engineers and AppSec teams can use it to expand testing coverage, gather evidence, and feed verified findings into remediation workflows.
• Developers and platform teams may find the source-review, API, GitHub, and CI paths useful — especially when they want actionable context rather than a raw rule ID.
• Red teams and security researchers get a repeatable methodology, a tool-rich environment, and the ability to supervise complex exploration.
• Bug-bounty researchers may appreciate the verification mindset, provided every program rule is followed and automated testing is explicitly allowed.
• Small teams can start with the open-source edition and a limited staging target, then decide whether operating the platform or using SaaS makes more sense.

Who should wait? If you need a completely hands-off compliance checkbox, have no Linux or container operational capacity, cannot isolate the scanner, or expect AI to replace security review, Xalgorix is unlikely to feel effortless. It is powerful precisely because it can take meaningful actions; that power needs an owner.

My recommended evaluation plan

• Deploy it on an isolated Linux VM or dedicated container host.
• Use a deliberately vulnerable lab application or a controlled staging clone.
• Run reconnaissance and one narrow vulnerability family first.
• Compare the evidence with a familiar baseline such as Burp Suite, OWASP ZAP, or Nuclei.
• Measure runtime, LLM usage, reproduced findings, and reviewer effort — not just the number of alerts.
• Only after that, expand phase coverage or connect it to CI.

Final verdict

Xalgorix is one of the more thoughtful attempts to bring agentic AI into practical application security because it does not stop at “the model found something.” Its workflow is built around methodology, independent verification, observable execution, and evidence that another person can inspect.

The open-source edition is the most compelling part of the product. It gives technical teams room to audit the code, choose the model, keep data in their environment, modify the workflow, and learn what the agent is actually doing. The hosted dashboard is a useful option for teams that value operational convenience, but it does not overshadow the self-hosted core.

I would not treat Xalgorix as a magic replacement for Burp Suite, ZAP, Nuclei, a skilled pentester, or a mature AppSec program. I would treat it as an orchestration and verification layer that can make those workflows more continuous, more observable, and less dependent on humans chasing every weak signal by hand.

Security note: only scan systems you own or have explicit permission to test. Start with an isolated lab, use conservative limits, and review evidence before acting on it.