use cases · bug bounty

Bug bounty automation that follows the program rules

An AI pentester can take recon and the first pass of testing off your plate. On a bounty program it also has to send the header the program asks for, stay under its rate cap and keep away from excluded hosts. Here's how to set Xalgorix up for that, and where it can't protect you.

Turn the policy into settings

Read the program policy before you start a scan. Each rule below maps to a setting in the open-source engine or in Xalgorix Cloud.

Program rule	Open-source engine	Xalgorix Cloud
Automated scanning is not allowed	Don't run Xalgorix on that program.	Don't run Xalgorix on that program.
Send an identifying header on every request	Repeatable -H "Name: value" (or XALGORIX_SCAN_HEADERS). Applied to all target traffic, including the bundled httpx and nuclei; never sent to your LLM provider.	Not a Cloud scan option today. Use the open-source engine for these programs.
Stay under a request-rate cap	XALGORIX_RATE_RPS (default 10) and XALGORIX_RATE_BURST (default 20) throttle outbound requests.	Not a per-scan setting. If the cap is below the engine default, self-host.
Some hosts or paths are out of scope	Scan in-scope hosts one at a time and list the exclusions in --instruction.	Use Single mode on in-scope hosts and list the exclusions in Custom instructions.
Some vulnerability classes are not accepted	Deselect those phases in the Web UI and say so in the instructions.	Deselect those phases (any subset of the 22) on the new-scan form.
Bound the time and spend	XALGORIX_MAX_DURATION, XALGORIX_MAX_TOOL_CALLS and XALGORIX_MAX_TOKENS stop a scan cleanly and keep its findings.	Credits are charged per scan; see pricing.

A scoped run, end to end

A program with one in-scope web app, an identifying header requirement, a low rate cap and an excluded payments host. Replace the values with the ones from your program's policy:

export XALGORIX_RATE_RPS=2
export XALGORIX_RATE_BURST=4
export XALGORIX_MAX_DURATION=7200

xalgorix --target https://app.example.com \
  --header "X-Bug-Bounty: your-handle" \
  --instruction "Only app.example.com is in scope. Do not touch
payments.example.com or any other host. Use only the two test
accounts described below. No DoS, brute force or destructive
actions, and no access to real users' data."

The header goes on every request to the target, including requests from bundled tools such as httpx and nuclei, so the program's team can recognise your traffic. Full flag list in the docs.

What you get back

Findings come with the request and response that demonstrate them, after an exploit verification phase re-tests each one. That gives you a starting point you can reproduce by hand and write up in your own words, rather than a list of maybes. See a real report in the sample report explorer, or read why detection isn't proof.

What it can't do for you

Instructions steer the agent; they are not a firewall. The engine's built-in guard blocks probes of your own machine and local network, not a program's out-of-scope list. That's why tight scopes should run as single-host scans.
Wildcard mode enumerates subdomains and starts a sub-scan for each live host. Use it only when the program says *.example.com is in scope with no host exclusions.
It won't tell you whether a bug is a duplicate, and it can't make an automation-banned program fair game.
You are still the reporter. Reproduce each finding yourself from the request and response evidence before you submit it.

Questions

Is it allowed on HackerOne, Bugcrowd or Intigriti programs?

That depends on each program's policy, not on the platform. Some programs ban automated tools, some cap request rates, and some require an identifying header. Read the policy first. Xalgorix's Acceptable Use Policy also forbids scanning bug-bounty targets outside a program's published scope or rules of engagement.

What do Cloud's default instructions do for bounty work?

The new-scan form pre-fills instructions that favour authenticated, stateful testing (access control, business logic, account lifecycle), ask for a reproducible exploit path, deprioritize commonly rejected findings such as missing headers, self-XSS and open redirects without a chain, and tell the agent to respect scope, exclusions, rate limits and automation policy. Edit them to match the program.

Should I self-host or use Cloud for bug bounty?

Self-host when the program requires an identifying header or a rate below the engine default, or when you want to bring your own model. Use Cloud when you want hosted models, compute and out-of-band listeners without setting anything up, and the program allows automated testing at normal rates.

Can it test the authenticated parts of a target?

Yes, if you give it test accounts you created under the program's rules. Describe the login flow and the accounts in the instructions. Never give it credentials for a real user's account.

Pick how you run it

Self-host the Apache-2.0 engine with your own model, or let Xalgorix Cloud run it.

Start on Cloud →Self-host from GitHub Compare the two