Model or dataset
six2dez/burp-ai-agent avatar
six2dez/burp-ai-agent

Custom AI Agent for Burp Suite: what the 1.0.0 release fixes and who should load it

Burp Suite extension that adds built-in MCP tooling, AI-assisted analysis, privacy controls, passive and active scanning and more

1,517 stars226 forksKotlinMIT

At a glance

What is it?
six2dez/burp-ai-agent is a Kotlin Burp Suite extension that wires twelve AI backends, 59 MCP tools and AI-assisted scanners into Burp. Version 1.0.0 closes two exploitable defects that shipped in every 0.9.x build.
Who is it for?
Adopt Custom AI Agent if you already run Burp Suite, want local models or CLI agents driving it over MCP, and can accept that the extension has no BApp Store listing and a passive scanner that needs Burp Pro. Stay away if you are on any 0.9.x build and have not read SECURITY.md, or if you need a signed, store-distributed extension.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 28 days ago.
What is it written in?
Mainly Kotlin, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The gap Custom AI Agent fills between Burp Suite and an AI backend

Burp Suite ships its own AI provider, and the extension's README says the project was renamed from Burp AI Agent to Custom AI Agent specifically to avoid confusion with it. That rename is the clearest statement of what this project is not: it is not a wrapper around Burp AI. It is a separate bridge that lets you point Burp at a model you choose, including one running on your own machine.

The intended user is a pentester or bug bounty hunter who already lives in Burp and wants three things the built-in provider does not give them together: model choice, an MCP surface that external AI clients can drive, and privacy controls over what leaves the machine. The README lists twelve backends, from Ollama and LM Studio locally through Anthropic, NVIDIA NIM, Perplexity and a generic OpenAI-compatible endpoint, plus CLI agents such as Claude CLI, Codex CLI and Gemini CLI. If your constraint is that request data must not reach a third party, the local options are the reason to look here.

The second audience is tooling-oriented: people who want Claude Desktop or another MCP client to operate Burp as a tool rather than chat about it. The README describes 59 MCP tools in the full build and 8 extension-native AI tools in the store build, and a scoped MCP mode that confines every tool to in-scope hosts.

How the MCP listener, scanners and privacy modes fit together

The architecture visible in the README has three cooperating pieces. The first is the AI backend layer, which normalises twelve providers behind one interface. The second is the MCP layer: a listener that exposes Burp actions as tools to external clients, with an access-control decision that the 1.0.0 notes say now runs ahead of routing. The third is the scanning layer, 62 vulnerability classes split between a passive scanner and an active AI scanner.

One implementation detail matters more than the feature count. The passive scanner runs as a Burp PassiveScanCheck, and the README states plainly that this requires Burp Pro. Community users get the chat, the backends and the MCP surface, but not passive scanning through that hook. That is a licensing boundary inside Burp itself, not a limitation the extension can work around.

Privacy modes sit between the scanners and the backend. STRICT, BALANCED and OFF decide how much redaction happens before a request reaches a model. The 1.0.0 changelog is unusually candid about how the previous implementation failed: the passive scanner emitted cookies as bare name=value pairs, dropping the prefix the redaction logic keyed on, and only a cookie literally named session was caught. The fix is in 1.0.0 and the README tells affected users to rotate those cookies. Anyone evaluating the privacy modes should read that entry before trusting the feature.

Tool-call confirmation is the other mechanism worth understanding. Tool calls parsed out of model output do not reach Burp until the user approves them, read-only bounded tools run silently, and an unrecognised tool name confirms every time rather than running. The design fails closed, which is the right default for a component that can issue requests through your proxy.

Installing the JAR and running a first prompt

The README gives two routes: download the JAR from Releases, or build from source with Java 21. The build has two flavours, and the difference is tool count, so pick deliberately. The default build produces the full JAR with all 59 MCP tools; passing the storeBuild property produces the BApp Store submission build with 8 extension-native AI tools.

bash
git clone https://github.com/six2dez/burp-ai-agent.git
cd burp-ai-agent
JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar
# Output: build/libs/Custom-AI-Agent-full-<version>.jar

If you want the store build instead, the README documents the property as follows. Note that the output filename loses the full suffix.

bash
JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar -PstoreBuild=true
# Output: build/libs/Custom-AI-Agent-<version>.jar

Loading it is the standard Burp flow. Open Burp Suite Community or Professional, go to Extensions > Installed > Add, choose Java as the extension type, and select the JAR. According to the README the extension registers in the Extensions list and the Suite tab as Custom AI Agent, which is how you distinguish it from Burp's built-in Burp AI provider.

On first run the extension installs bundled agent profiles into ~/.burp-ai-agent/AGENTS/. Adding a custom profile means dropping a *.md file into that directory. The README does not document a schema for those files, so the bundled profiles are the working reference. Configuration itself is truncated in the README excerpt, so the settings tab is where you will actually choose a backend and enter credentials.

The 0.9.x credential exposure and other reasons to be careful

The most important limitation is not architectural, it is historical. The README carries an advisory block telling anyone running 0.9.0, 0.9.1 or 0.9.2 to read SECURITY.md before upgrading, and states that two defects confirmed by running the shipped code affect every published 0.9.x release. It also warns that no CVE or GHSA identifier was issued, so searching a vulnerability database will not surface them.

The first, labelled SEC-04 and critical, is that MCP access-control checks did not run on resolved routes. With external access enabled, the listener accepted unauthenticated tool calls; in local mode the Origin, Host and User-Agent checks and the security response headers were inert on matched routes. The practical consequence is that an MCP token may have been usable by someone it should not have been, and the README's remediation is to rotate it.

The second, PRIV-05, is the cookie redaction failure described earlier, and it affected both STRICT and BALANCED modes. A user who believed they were in STRICT mode while scanning an authenticated session may have sent session cookies to a cloud backend in a form the model could read. The remediation is rotating the affected cookies, which is a real cost if those sessions are long-lived.

There are quieter constraints too. The README says the extension is not on the BApp Store and that the submission has been open since January 2026, so installation is manual and updates are manual. The passive scanner needs Burp Pro. And the security posture of the project rests on an external review of 0.9.2 dated 2026-08-05, which is a good sign but also a reminder that the 0.9.x line shipped for months with these defects present.

Custom AI Agent against Burp's built-in AI provider

The honest comparison is with Burp Suite's own Burp AI provider, because that is the thing the project renamed itself to avoid being confused with. The difference in approach is ownership of the model connection. Burp AI is a provider inside Burp; Custom AI Agent is a client that speaks to a provider you configure, and the README's list spans local runtimes, cloud APIs and CLI agents.

That matters in two directions. If you want zero configuration and you are happy with the vendor's model, the built-in provider is less work and comes with the product. If you need a model running on infrastructure you control, or you want an MCP client to drive Burp as a tool, the built-in provider does not offer that surface and this extension does.

The cost of the extension's approach is that you own the keys, the endpoints, the token rotation and the upgrade path. There is no store listing to notify you that a new version exists. After the 0.9.x disclosures, that ownership is not theoretical: the README's remediation steps are things you have to perform yourself.

A second alternative worth naming is the general pattern of exporting Burp traffic and analysing it with a standalone CLI agent. That avoids running a listener inside Burp entirely, at the cost of losing live tool calls against the proxy and the scanner integration. If your threat model dislikes an MCP port on the machine, that trade may be the right one.

Maintenance, licence and what upgrading actually costs

The repository is not archived and the last push was on 2026-09-02, which is recent enough to call the project maintained. Version 1.0.0 is the first stable release, dated 2026-08-22, following 0.9.2 on 2026-07-29. The README describes the test suite growing from 660 to 1131 tests across 158 classes with line coverage moving from 34% to 58%, and the detekt baseline shrinking from 1096 to 1040. Those numbers come from the project's own release notes, not from independent measurement.

The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice retained. That is a permissive arrangement and it is compatible with the way most consultancies would use a Burp extension internally. Nothing in the repository suggests dual licensing or a paid tier. This is a description of the licence text, not legal advice; if you are redistributing a modified build, read the LICENSE file and your own counsel's guidance.

Upgrade cost is the part people underestimate. Because there is no BApp Store listing, there is no in-product update prompt, so you have to watch Releases yourself. Because the 0.9.x fixes include credential rotation, an upgrade is not a drop-in JAR swap for anyone who ran an affected version. And because the full build and the store build produce different JAR names and different tool counts, a team that standardises on one must document which artefact it ships, or someone will load the 8-tool build and wonder where the rest went.

Editorial conclusion

Adopt Custom AI Agent if you already run Burp Suite, want local models or CLI agents driving it over MCP, and can accept that the extension has no BApp Store listing and a passive scanner that needs Burp Pro. Stay away if you are on any 0.9.x build and have not read SECURITY.md, or if you need a signed, store-distributed extension. Before anything else, verify the JAR you download is the 1.0.0 full build, not the store build, and confirm your MCP token was rotated after the upgrade.

Frequently asked questions

What does Burp AI do in Custom AI Agent?

The extension integrates AI into the security workflow: it connects Burp Suite to local models or cloud providers, lets external AI agents drive Burp through MCP, and runs passive and active scanners that look for vulnerabilities while you test manually. The README lists twelve supported backends and 62 vulnerability classes.

How much does Burp AI cost in Custom AI Agent?

The project itself is MIT licensed, so the extension costs nothing. What you pay for are the backends you configure: local runtimes such as Ollama and LM Studio need no API spend, while cloud providers such as Anthropic, NVIDIA NIM and Perplexity bill on their own terms. The README does not publish pricing for any provider.

Is Burp Suite used by hackers?

The extension's stated audience is security work: pentesting, bug bounty hunting and AppSec, and its topics include pentesting and web security. The README describes scoped MCP access that confines every MCP tool to your in-scope hosts, and privacy modes that redact sensitive data before it leaves Burp. It does not discuss use outside authorised testing.

Official sources

  1. License: MIT
  2. Project website
  3. README
  4. Releases
  5. six2dez/burp-ai-agent on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/six2dez-burp-ai-agent.svg)](https://hysenlabs.com/projects/six2dez-burp-ai-agent)