BugTraceAI: a self-hosted multi-agent scanner for authorized bug bounty work

BugTraceAI targets authorized bug bounty and pentest work

The README opens with a narrow audience: "Autonomous, self-hosted security testing for authorized bug bounty and pentesting". That framing matters more than the feature list. This is not a general SAST tool you point at a codebase, and it is not a service you sign up for. It is a framework you run on your own infrastructure against targets you have written permission to test, and the disclaimer repeats that constraint twice, requiring "explicit, written authorization" and telling readers to "Always verify findings manually."

The problem it addresses is the gap between automated scanners and manual testing. Scanners produce long lists of candidate issues with weak context; a human tester then spends hours triaging. BugTraceAI's stated position is that AI agents should do the prioritising and hypothesis-forming, while deterministic tools and collected evidence decide what is real. The README puts it plainly: "The AI prioritizes and reasons about hypotheses; tools and evidence validate what is real."

Who it is for, then: individual bug bounty hunters and small pentest teams who are comfortable running Docker, reading a wiki, and treating AI output as a lead generator rather than a verdict. Who it is not for: anyone without a defined scope and authorization, and anyone expecting a turnkey commercial product with support contracts.

Four components, a launcher, and a practice target

The repository is a monorepo of submodules rather than a single application. The top-level tree lists BugTraceAI-CLI, BugTraceAI-WEB, BugTraceAI-Launcher, BugStore and reconftw-mcp, alongside Documentation/, assets/ and the licence files. The README describes BugTraceAI as "4 independent but interconnected components, plus a dedicated practice target", which maps onto the CLI, the web dashboard, the launcher and the MCP integration, with BugStore as the target you can legally practise against.

The technology choices are visible in the badge row and the ecosystem table: Python 3.10 or newer, React 18, FastAPI, Go fuzzers, Playwright and Docker. That mix tells you roughly where each piece sits. Playwright implies browser-driven testing for client-side and authenticated flows. Go fuzzers imply compiled, fast payload iteration rather than Python-loop fuzzing. FastAPI and React imply the web dashboard is a separate service talking to a backend, not a static report viewer.

The scanning pipeline is the part the README names but does not detail here. It refers readers to the Architecture and Scanning Pipeline sections of the wiki, and the live demo is offered as the way to see a real scan. If you need to know exactly which tools run in which order before you install anything, the README alone will not tell you; the wiki and the DeepWiki mirror are the places it points to.

Installing BugTraceAI from the launcher and running a first scan

The README's Quick Start section points at the wiki rather than reproducing commands, and the Launcher badge shows version v2.9.1. The repository describes deployment as "One-command deployment via Launcher" and lists Docker as a core principle, so the intended path is the launcher submodule rather than a pip install of the CLI on its own.

Because the README does not print the exact launcher invocation, the honest first step is to read the wiki quick start and copy the command from there. What the repository does tell you is what to expect: a self-hosted stack with no telemetry and no cloud dependency, so nothing leaves your machine once it is running. The CLI badge shows v3.7.12-beta and the web badge shows v1.5.40-beta, which is what you should see reported after a successful start.

If you prefer to work component by component, the README states the components are modular: "Use components independently or together." That means the CLI submodule can be used without the dashboard, which is the lighter option on a laptop. The practice target is a separate repository, BugStore, linked from the badges, and it is the sane place to point your first scan.

git clone https://github.com/BugTraceAI/BugTraceAI.git
cd BugTraceAI
git submodule update --init --recursive

That sequence matters because the components are submodules. A plain clone gives you the top-level tree, not the CLI, web app or launcher contents, so the recursive update is what actually pulls the code you intend to run. After that, follow the wiki's launcher instructions for your platform.

ls BugTraceAI-CLI BugTraceAI-WEB BugTraceAI-Launcher

If those three directories are populated rather than empty, the submodules resolved correctly and you are ready for the launcher step. The README does not document a rollback procedure or an uninstall path, so plan to run this in a container or a disposable VM where removing it is a matter of deleting the environment.

What the beta labels and thin documentation mean in practice

The most useful signal in the README is not a feature, it is the version string. The CLI is tagged v3.7.12-beta and the web application v1.5.40-beta. Beta labels on a security tool that makes autonomous decisions about what to test are a real constraint: expect false positives, expect false negatives, and expect behaviour to change between releases. The README says as much in its disclaimer, warning that "AI output may contain inaccuracies, false positives, or false negatives" and that the platform "is not a substitute for professional security auditing."

The second constraint is documentation depth. The README is a landing page: it lists components, principles and community links, and repeatedly defers to the wiki, DeepWiki and the live demo for the parts an operator actually needs. There is no rollback procedure, no upgrade guide and no resource-sizing guidance in the README. For a self-hosted tool that runs browser automation and fuzzing, the absence of stated CPU and memory expectations is a gap you will discover on your own hardware.

The third is scope. A tool that combines AI agents with real exploitation steps is the wrong tool for a production environment you cannot afford to disturb, and the wrong tool for any target outside a written authorization. It is also the wrong tool if your goal is continuous CI gating: the repository contains a CI/CD proposal image and a section titled "CI/CD Integration Proposal", which reads as a proposal rather than a shipped, documented integration.

How BugTraceAI differs from reconftw and single-purpose scanners

The closest thing to a stated alternative inside the repository is reconftw-mcp, which appears in the top-level tree. The name points at reconftw, a well-known reconnaissance automation script, exposed here through the Model Context Protocol so agents can call it. That is a meaningful difference in approach: reconftw is a deterministic, scripted pipeline that runs a fixed sequence of reconnaissance tools and produces output for a human to read. BugTraceAI keeps those tools but puts an agent layer above them that decides what to run next and how to mutate payloads, with the README insisting this "is NOT a wrapper around existing tools."

The trade-off is legibility. A reconftw run is reproducible: same flags, same order, same output shape. An agent-driven pipeline is not, because the sequence depends on what the model decides at each step. For a bug bounty hunter chasing a novel issue on a target they know well, that adaptivity is the point. For a team that needs an auditable, repeatable scan record, a fixed pipeline plus manual review is easier to defend.

Against general-purpose scanners, the difference is where the intelligence sits. Traditional scanners enumerate known signatures and report matches; BugTraceAI's claim is that agents form hypotheses and then use tools and evidence to confirm or discard them. Whether that reduces triage time is exactly the thing the live demo exists to show, and the thing you should judge on your own target rather than take on faith.

Licence, upgrade cost and what the repository records

The licence situation needs care. The README badge says AGPL-3.0, and the repository carries both LICENSE and LICENSE-HISTORY.md, which implies the licence changed at some point. GitHub's own metadata for the repository still reports Apache-2.0, which conflicts with the badge and the history file. The NOTICE file exists as well. Treat the files in the repository as authoritative over the platform label, and read LICENSE-HISTORY.md before you build anything on top of this.

The practical implication of AGPL-3.0 is that if you modify BugTraceAI and offer it to others over a network, the licence's network clause is the part your legal team will want to read. That is a summary of why the file matters, not legal advice; the licence text governs.

Upgrade cost is the other hidden expense. With four submodules, upgrading means tracking four independent version numbers: the CLI badge, the web badge and the launcher badge are all separate, and the submodule pointers in the parent repository decide which commits you actually get. The README does not describe a migration path between versions, so the safe pattern is to pin a known-good set of submodule commits, test against BugStore, and only then move the pins forward. The last push to the repository was on 2026-09-14, so the codebase is moving; pins will drift quickly if you do not maintain them deliberately.

Editorial conclusion

Adopt BugTraceAI if you already run authorized engagements and want a local, AGPL-licensed scanner whose agents are paired with deterministic tools rather than a cloud service. Skip it if you need a stable, fully documented release: the README labels the CLI v3.7.12-beta and the web app v1.5.40-beta, and the quick start defers to the wiki. Before deploying, verify three things: the exact launcher command in the wiki quick start, whether the launcher binds the dashboard to a port you control, and the AGPL-3.0 obligations noted in LICENSE-HISTORY.md, which records a licence change from the Apache-2.0 identifier GitHub still shows.

Frequently asked questions

Official sources

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