AutoHunter: an LLM multi-agent loop for authorized SRC bug hunting

The gap AutoHunter is trying to fill in SRC workflows

Classic bug bounty work on an SRC platform is a loop of manual steps. You search FOFA or a similar asset search engine for a fingerprint, you probe which hosts are alive, you run a handful of scanners, you read the output, and you decide whether anything is worth writing up. The README frames AutoHunter as a way to remove the middle of that loop. The author's pitch is blunt: hand one machine over as a 24x7 hunting platform and keep only the role of human reviewer, spending a few minutes deciding pass, reject, edit or submit.

The audience is narrow and the README says so up front. A warning block states the tool is only for targets where you hold explicit written authorization. That is not boilerplate caution. The pipeline is built to run offensive tooling against whatever the collector finds, so the scope question is the first thing a reader has to answer, not the last.

What makes the design interesting is the division of labor. The AI is not asked to be right. It is asked to be a filter, so that the human's attention is spent on candidates that already survived one review pass. Whether that trade is worth it depends entirely on how much noise your targets generate.

Collector, Worker, Reviewer: the three-stage pipeline

The README's flow diagram lays out a linear pipeline with one feedback edge. The Collector gathers assets, either from FOFA or by manual entry, and does liveness probing, scoring and attribution. Each asset then goes to a Worker in a 1:1 relationship, where an LLM drives its own reconnaissance using nmap, nuclei, sqlmap and httpx. The Worker's findings go to a Reviewer that the README describes as a strict first pass. If the Reviewer judges a finding good enough, it moves to human review. If not, it is either sent back to the Worker for deeper digging or discarded as noise or a false positive.

The feedback edge is the part worth noting. A rejected finding is not simply dropped; the Reviewer can push it back to the Worker for another attempt. That means a single asset can consume multiple LLM turns before it ever reaches a person. The README also describes a separate path from human approval to a submission list and to a Hunter mode that tries the same technique across many targets at once, with validation routed back through the Worker.

Architecturally this is a FastAPI application with a Vue 3 frontend, SQLite for state (aiosqlite and SQLAlchemy in requirements.txt), and a worker workspace on disk. The docker-compose.yml mounts two volumes: ah_data for the database and evidence, and ah_work for the worker scratch area. The comment on ah_data says restart recovery depends on it and warns against deleting it. That is the honest shape of the system: a stateful orchestrator, not a stateless scanner.

Installing AutoHunter with Docker Compose and a first task

The README gives two paths. The manual one is a three-command sequence: copy the environment template, edit it, then bring the stack up. The compose file header repeats the same sequence in a comment, and the build is local rather than pulling a prebuilt image.

cp .env.example .env
docker compose up -d --build

The README says the minimum viable configuration is LLM_API_KEY. The .env.example agrees: the header comment states that only the key is required to start, while FOFA_KEY and an access token are strongly recommended. Without FOFA credentials the Collector still has the manual entry path, but you lose the asset mapping that gives the system its name. The default model block points at DeepSeek with LLM_MODEL=deepseek-chat and LLM_TEMPERATURE=0.3, and the protocol field accepts auto, openai_chat or anthropic_messages.

The alternative install path is the bootstrap script referenced in both the compose header and the README:

bash scripts/install.sh

Once the container is up, the compose file publishes port 18800 on the host by default, mapped from the same port inside the container, and the host side can be changed by setting AUTOHUNTER_HOST_PORT in .env. The README's own quick-start section is what points you at the web UI for creating a task; the repository does not document a CLI equivalent, so the browser is the interface you get. The container is set to restart: unless-stopped, and the compose comment says it recovers task state from the database after a crash.

One build detail matters if you are outside China or inside it. The Dockerfile installs sqlmap from PyPI rather than cloning GitHub, with a comment explaining that GitHub clones often time out or fail from within China. The nuclei and httpx binaries are fetched from ProjectDiscovery releases through ghfast.top and ghproxy.net mirrors first, falling back to GitHub directly, and the build fails outright if the zip is invalid. That is a deliberate choice against silent partial images.

Where the LLM dependency becomes the failure mode

The single hardest constraint in AutoHunter is that the entire pipeline depends on tool calling against an external model endpoint. The .env.example is unusually candid about this. AUTOHUNTER_TOOL_COMPAT defaults to auto, which prefers native tool calling and falls back to prompt-based simulation when an endpoint hard-errors on the tools parameter. There is a prompt mode for models that accept the tools argument but never actually call anything.

That fallback is a mitigation, not a fix. A model running in prompt-simulation mode is being asked to emit tool calls as text, and the README does not claim the result is equivalent to native function calling. If your provider's tool calling is unreliable, the Worker's reconnaissance quality degrades in ways that are hard to observe from the outside, because the pipeline still produces findings.

The provider pool logic has a second-order effect. LLM_PROVIDER_FAIL_THRESHOLD defaults to 5 and LLM_PROVIDER_BEHAVIOR_FAIL_THRESHOLD to 3. Cooldowns escalate through 300, 900, 1800 and 3600 seconds. The comment on LLM_PROVIDER_FAILED_RETRY_SECONDS is the useful part: it defaults to 60, and the file explicitly advises single-endpoint deployments to lower it to 10 or 15, because otherwise one transient blip parks the whole task for a minute. That is a real operational trap for anyone running one model instead of a pool.

There is also an explicit warning in requirements.txt against installing pyppeteer or undetected-chromedriver inside the container. Those packages pull old websockets versions without a lower bound, and uvicorn needs websockets 13.0 or newer, so the container would break. If a Worker ever needs a real browser, that constraint is the wall you hit.

What the README will not tell you about data safety

The warning block near the top of the README contains a sentence that deserves more weight than its placement suggests. It says the tool has deletion restrictions, but that under some external conditions, including what it calls the model's own volition, a small amount of data may still be modified or deleted, and that all consequences are the user's. The author then asks not to be blamed.

Read that as a design boundary rather than a disclaimer. The agents have tool access. Tool access that includes file operations cannot be fully fenced by intent alone, and the project is telling you it has not solved that. If a Worker's workspace is mounted somewhere that also holds data you care about, the blast radius is your problem, not the project's. The ah_work volume is described as a worker temporary workspace, which is the right place to keep it.

The README does not document rollback. It does not describe a dry-run mode. It does not describe a permission model that limits which paths an agent can touch. Those absences are the ones to plan around. The compose file's ah_data volume comment says the database holds SQLite state plus evidence and that restart recovery depends on it, so backups of that volume are the only recovery story the repository actually describes.

A second gap: the README gives no install steps for a non-Docker deployment. The Dockerfile and compose file are the supported path, and requirements.txt is a runtime dependency list, not a deployment guide. Treating this as a pip install is not something the repository supports.

How AutoHunter differs from a scanner you already run

The obvious comparison is nuclei by itself. Nuclei is a template-driven scanner: you point it at a list of hosts, it runs community and custom templates, and it prints matches. It is deterministic, fast, and you can diff two runs. AutoHunter embeds nuclei as one of the Worker's tools, but the thing on top is a model deciding what to try next based on what it has already seen. That is the actual difference in approach, and it cuts both ways. You gain exploration that a fixed template set will not do. You lose reproducibility, because the same asset may produce different findings on two runs.

A second comparison is the standard pipeline of FOFA plus httpx plus a manual review spreadsheet. That workflow is cheap, auditable and entirely under human control. AutoHunter's claim is that the Reviewer agent absorbs the first triage pass so the human sees fewer, better candidates. If your targets are low-noise and your template set already covers them, the agent layer adds cost and unpredictability for little gain. If your targets are broad and the bottleneck is reading output, the pitch is more plausible.

The honest framing is that AutoHunter is an orchestration layer, not a new detection technique. Everything it finds comes from nmap, nuclei, sqlmap, httpx or whatweb, all of which the Dockerfile installs. The LLM decides sequencing, interpretation and triage.

Licence, maintenance and the cost of staying current

AutoHunter is Apache-2.0, and the repository carries both a LICENSE and a NOTICE file, which is what Apache-2.0 expects when a project wants attribution preserved. For most users that means you can run it commercially and modify it, provided you keep the notices and state your changes. The README's warning block restates the licence in the same breath as the authorization warning, and the two are separate concerns: the licence governs the code, and it does not grant you permission to test anyone's systems. Nothing here is legal advice, and if you plan to redistribute a modified version you should read the NOTICE file yourself.

The last push to the default branch was on 2026-09-16, and the repository is not archived. The README lists contributors with roles that map onto real subsystems: Engines, Agent UX, LLM Pool, FOFA API, DNS Probe, Workdir Cleanup, Reviewer Fix. That is a wider contributor surface than a single-author project usually shows, and it suggests the components are being touched independently.

Upgrade cost is dominated by the pinned external tooling. The Dockerfile pins NUCLEI_VER to 3.3.7 and HTTPX_VER to 1.6.9, and installs sqlmap from PyPI without a version pin, so a rebuild can pull a newer sqlmap than the last one. The frontend stage runs npm install against frontend/package.json with no lockfile copy in the snippet shown, which means frontend dependency resolution is not frozen either. If you care about reproducible images, those are the two places to look first. There are no releases retrieved for this repository, so upgrades mean tracking the main branch rather than a tagged version.

Editorial conclusion

Adopt AutoHunter if you already hold written authorization for specific targets, you are comfortable running an LLM-driven agent that executes nmap, nuclei, httpx and sqlmap, and you want a triage queue rather than a scanner you babysit. Do not adopt it if you need a tool that runs without an external LLM endpoint, if you cannot supply an LLM_API_KEY, or if you want deterministic, reproducible scan output, because the pipeline's decisions come from a model. Before pointing it at anything, verify three things in your own checkout: that .env has LLM_API_KEY set and the target scope is what you intend, that the ah_data volume is on storage you can keep, and that you have read the README warning that the project cannot guarantee its agents will never modify or delete data.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. StanleyNull/AutoHunter on GitHub