# Ars0n Framework v2 wraps 50 scanning tools and an AI agent behind one workflow

> Ars0n Framework v2 is a Go and Python tool that drives more than 50 open source bug bounty scanners from a single interface, stores their output in one database, and exposes an MCP server with over 150 tools so an AI agent can run the same steps. It is GPL-3.0, at beta 0.1.1, and its own documentation is explicit that it does not replace manual hunting.

**R-s0n/ars0n-framework-v2** — AI Native Bug Bounty Hunting Framework Designed to Help Beginners Compete w/ the Pros

- Repository: https://github.com/R-s0n/ars0n-framework-v2
- Stars: 858 · Forks: 169
- Language: Go
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/r-s0n-ars0n-framework-v2

## A wrapper whose job is to force a methodology

Ars0n Framework v2 is a Go project, with a Python service beside it, that presents a single interface over what the README calls 50 plus widely used bug bounty hunting tools. Amass is the first tool named in the list. The framing is worth quoting because it explains the design: the framework acts as a wrapper, and the interface design is what forces the user into a correct hunting methodology.

That is a different proposition from a scanner. A scanner finds things. This project is trying to make sure you do the right things in the right order, and it says so bluntly, claiming it is literally impossible to use the tool without going through the author's process.

The supporting mechanics are consistent with that goal. Results from each tool are stored in a central database, and the README says they can be used for understanding and visualising a target company's attack surface. Each section also carries a Help Me Learn dropdown containing a lesson plan that explains where you are in the methodology, what you are trying to achieve, and why it matters.

The origin story in the About section explains the rewrite. The code started as the author's own collection of scripts for repetitive bug bounty processes, grew into a framework that helped people begin their journey, and was then rebuilt as version 2 because the first implementation had a wide range of issues, mostly from never having been designed to be shared as an open source project.

The project is licensed GPL-3.0.

## Three pillars, and each one has a stated job

The README lays out how work should be divided, and the division is the most reusable idea in the project, independent of the code.

The first pillar is human creativity. The author's argument is that humans remain the key to success because they can come up with ideas that have never been thought of before, and that doing the same thing everyone else does means finding the same bugs everyone else finds.

The second is AI, specifically large language models, with two stated strengths: converting unstructured data to structured data, and building dynamic automated workflows that include complex decision making. The MCP server exists for this, with 150 plus tools to support the process.

The third is automation for repetitive work, which is handed off to 50 plus battle tested open source scanning tools rather than reimplemented.

The README is explicit about the boundary between those pillars, and it states the tool is not designed to replace manual bug bounty hunting with AI. Its stated purpose is to let a human researcher work with both an AI system and a wide range of open source tools, using each for what it is good at.

That framing matters for expectations. A framework that claims to remove the need for human judgement would be a red flag in a security tool. This one puts the human in the loop by design, and the AI in the role the author says models are actually good at.

## The MCP server lets an agent drive the same interface

The newest release adds the piece that connects the tool to an AI agent, and the README describes it as allowing an AI agent, or a collection of agents, to do anything a user can do through the interface.

That is a strong claim and it is worth being precise about what it depends on. The agent drives the framework's own API and tool set rather than the scanning tools directly, which means the agent inherits the framework's scope handling, its rate limiting and its database, since everything runs through the same service.

The second half of the feature is the Education Layer, which the README describes as providing the AI system with the knowledge of an experienced hunter. In other words the framework is not only a set of tools for the agent to call, it also carries the methodology as context that the agent can consult, mirroring the Help Me Learn lessons a human sees in the interface.

The repository layout supports this reading. There is an ai_service/ directory with its own container image and its own compose profile, a server/ directory holding the API, a client/ directory for the front end, an extension/ directory, and a scope/ directory. The compose file gives the ai service a profile named ai, so it starts only when that profile is enabled, and it points at the API through the API_URL environment variable.

For a team experimenting with agent driven reconnaissance, having the agent constrained by the same scope rules as the human operator is the feature that makes it usable at all.

## Four services, one compose file, and a database pin that matters

The deployment is a Docker Compose stack, and the compose file is the clearest documentation of how the pieces relate.

There are four services. nginx fronts the stack on port 80 and depends on the api and client services. The api service carries the main configuration, including the database connection and the address of a positive control oracle.

```yaml
    environment:
      ARS0N_CANARY_HOST: "oracle:8000"
      DATABASE_URL: postgres://postgres:postgres@db:5432/ars0n
```

The api container also mounts the Docker socket, has a temp_data volume, and mounts the repository's wordlists directory into the image at /app/wordlists. The ai_service is exposed on port 8000 and sits behind the ai profile, so it does not start with a plain compose up.

The db service is a PostgreSQL instance, and the comment attached to it explains the pin in unusual detail. The postgres_data volume was initialised by PostgreSQL 18, and the file says the image is pinned to the major deliberately, calling it the highest-consequence pin in the file, because PostgreSQL ships a new major every September or October and the official latest tag follows within days, which would otherwise break the existing data directory on a pull.

That is a good example of the failure this framework is meant to prevent, appearing in its own infrastructure. Anyone who reuses the compose file should keep the pin rather than updating the tag.

The top level also carries build.sh and build.ps1 for local builds, update.sh and update.ps1, a docker/ directory, an nginx/ directory, and two planning documents, IMPROVEMENT_PLAN.md and PERFORMANCE_IMPROVEMENT_PLAN.md.

## Scope, rate limiting and a positive control

Three details in the repository show how seriously the project takes the authorised testing boundary.

The first is the scope directory. Scope management is the part of bug bounty work that decides whether a request is allowed, and having it as a first class directory in the tree rather than a note in the docs says the framework treats it as configuration rather than as advice.

The second is rate limiting. The repository contains a rate-limiting.png screenshot, which suggests the framework surfaces its own throttling to the operator rather than leaving each underlying scanner to behave as it wishes. For a target under a programme that specifies request rates, this is the difference between a useful tool and a reportable one.

The third is the canary. The ARS0N_CANARY_HOST environment variable points at a positive control oracle, and the comment in the compose file explains why it is explicit rather than left to a compile time default, so that compose and the code cannot disagree about it silently. A positive control is a known-answer target used to check that the tooling still detects what it claims to detect.

There is a privacy dimension too. The api service sets DNS to the Docker resolver plus 8.8.8.8 and 1.1.1.1, and maps host.docker.internal to the host gateway, which is the usual arrangement for a container that needs both internal service discovery and outbound resolution.

None of this is legal advice, and none of it substitutes for a programme's rules of engagement, but it shows the intended operating model.

## Beta 0.1.1 is a statement about the interface, not the tools

The release history is short and recent. beta-0.1.1 was published on 2026-10-15, beta-0.1.0 on 2026-09-05, and beta-0.0.7 on 2026-03-20. The last push to the repository was on 2026-10-15, the same day as the newest tag.

The README also refers to pre-alpha demo videos, and the About section describes the first implementation as having had a wide range of issues. Read together, the message is that the framework's own interface and service layer are young, even though the scanning tools it drives are established and widely used.

That distinction is what makes the project usable. A bug bounty framework is mostly an orchestration and bookkeeping problem, and orchestration code changes shape under its users. The scanners underneath, including the ones the README names, are not the part that is being rewritten.

The practical advice that follows is narrow. If you are evaluating the framework, the interesting questions are about the service stack, the database schema, the scope configuration and the MCP tool surface, because those are what will change. The behaviour of the underlying scanners is not something this repository decides.

The README is also written in a distinctly personal voice, with a sponsorship button and links to the author's YouTube channel and LinkedIn profile, and much of the documentation lives in videos rather than in text. That is a fair warning for anyone who wants to read their way through the methodology.

## When this wrapper is the wrong choice

There are three cases where the framework costs more than it returns.

The first is a hunter with a working pipeline. If you already run Amass and the rest of your scanner set from a set of scripts, and you already keep results in a database or a set of files, the wrapper adds a service stack, a database schema and a web interface in exchange for a guided workflow you already have. The value is the methodology, and if you do not need the methodology, the value is thin.

The second is a team that needs auditability. A database, an API, a client and an AI service in front of every scan means there is now a system to secure, to patch and to keep in step with the tools it calls, and the AI service is an extra surface that can act on your target. For a target you are actively working, that may be acceptable. For a compliance environment, it is a discussion to have before installing.

The third is the beta itself. This is a project that wants to be run against real targets on day one, and the release notes are still moving fast, with a beta tag and a 0.x version number. The database migration question raised in the compose comment is the sort of thing that gets easier to answer once the schema settles.

None of that makes the project wrong. It makes it a tool for a particular person, which is what the author intended.

## Conclusion

Ars0n Framework v2 fits a beginner who wants a guided path through reconnaissance, enumeration and reporting, or a hunter who wants one interface over scanners they already run, because the central database and the methodology guidance are the point rather than any single tool. It is the wrong choice for a professional with an established pipeline, since the wrapper adds a service stack to do what a handful of scripts already do, and the release is beta 0.1.1 with the project itself describing its demos as pre-alpha. Before installing it, read the scope and rate limiting configuration, confirm your target is in an authorised bug bounty programme, and check the compose file's database pin, because the PostgreSQL major version is deliberately held back.

## FAQ

### What is Ars0n Framework v2?

It is a Go and Python framework that acts as a wrapper around 50 plus widely used bug bounty hunting tools, presenting them through one interface, storing each tool's results in a central database, and providing a methodology the user is guided through. The project is licensed GPL-3.0.

### What does the MCP server in Ars0n Framework v2 do?

The beta 0.1.1 release adds an MCP server with 150 plus tools that lets an AI agent, or a collection of agents, do anything a user can do through the interface, together with an Education Layer that gives the AI system the knowledge of an experienced hunter.

### Does Ars0n Framework v2 replace manual bug bounty hunting?

The README states explicitly that the tool is not designed to replace manual bug bounty hunting with AI. Its stated purpose is to let a human researcher work with both an AI system and open source tools, using each for what it does well.

### How is Ars0n Framework v2 deployed?

With Docker Compose. The stack has an nginx service on port 80, an api service, an ai_service on port 8000 that sits behind the ai profile, and a PostgreSQL db service. The api service is configured with DATABASE_URL, a wordlists mount and the ARS0N_CANARY_HOST pointing at a positive control oracle.

### What version of Ars0n Framework v2 is current?

The newest release is beta-0.1.1, published on 2026-10-15, before beta-0.1.0 on 2026-09-05 and beta-0.0.7 on 2026-03-20. The last push to the repository was on 2026-10-15 as well.

## Sources

- [Issues](https://github.com/R-s0n/ars0n-framework-v2/issues)
- [License: GPL-3.0](https://github.com/R-s0n/ars0n-framework-v2/blob/main/LICENSE)
- [README](https://github.com/R-s0n/ars0n-framework-v2/blob/main/README.md)
- [Releases](https://github.com/R-s0n/ars0n-framework-v2/releases)
- [R-s0n/ars0n-framework-v2 on GitHub](https://github.com/R-s0n/ars0n-framework-v2)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/r-s0n-ars0n-framework-v2