Custom AI Agent (six2dez/burp-ai-agent): MCP Tooling for Burp Suite, and the 0.9.x Security Debt It Repaid

The gap this fills between Burp and a language model

Burp Suite already has a built-in Burp AI provider, and the README is explicit that the extension was renamed to Custom AI Agent partly to avoid confusion with it. So the project is not competing on the existence of an AI button. It is competing on where the model sits relative to the proxy. In this extension the model is a client of Burp, not a feature inside it: the README describes 59 MCP tools that let an MCP client such as Claude Desktop drive Burp, plus a Burp Scan Skill that turns a coding assistant into a scanner. The intended user is a pentester or bug bounty hunter who already lives in Burp Pro, wants to point an external agent at a target, and does not want that agent to see out-of-scope hosts or unredacted cookies. That last constraint is the whole design brief. Anyone who just wants a chat box next to the HTTP history is not the audience.

Twelve backends, three privacy modes, one approval gate

The backend list is deliberately wide: Burp AI (built-in), Anthropic, Ollama, LM Studio, NVIDIA NIM, Perplexity, a generic OpenAI-compatible endpoint, and four CLI wrappers (Gemini CLI, Claude CLI, Codex CLI, OpenCode CLI, plus Copilot CLI). Local models via Ollama or LM Studio matter here because the privacy modes only govern what leaves Burp; if nothing leaves, the redaction question changes shape. The three modes are STRICT, BALANCED and OFF, and the README frames them as redacting sensitive data before it leaves Burp. The mechanism that carries the most weight in 1.0.0 is the approval gate: a tool call parsed out of model output does not reach Burp until you approve it, read-only bounded tools run silently, and an unrecognised tool name confirms every time rather than running. The README states the tiers fail closed. That is a meaningful architectural choice, because it means the failure mode of a confused model is a prompt, not an action. The passive scanner is implemented as a Burp PassiveScanCheck, and the README attaches Burp Pro to that sentence. Active scanning covers 62 vulnerability classes across injection, auth and crypto, per the README.

Two defects in every 0.9.x build, and what rotating credentials means

This is the part that should decide your upgrade timing. The README states that an external review of 0.9.2 on 2026-08-05 confirmed two exploitable defects by running the shipped code, and that both affect every published 0.9.x release. SEC-04 is described as critical: MCP access-control checks did not run on resolved routes, so with external access enabled the listener accepted unauthenticated tool calls, and in local mode the Origin, Host and User-Agent checks plus the security response headers were inert on matched routes. PRIV-05 is high: session cookies reached AI backends unredacted in STRICT and BALANCED, because the passive scanner emitted cookies as bare name=value and dropped the prefix that the redaction keyed on, so only a cookie literally named session was caught. Both are fixed in 1.0.0, and no CVE or GHSA identifier was issued, which the README says plainly so you do not go searching for one. The practical consequence is unusual for a version bump: the advisory instructs you to rotate your MCP token and to rotate affected cookies, because credentials may already have been disclosed to a third party. Treat that as the first step, not the last.

Building the JAR, loading it, and the config directory that keeps the old name

The extension is not on the BApp Store. The README says the submission has been open since January 2026, so installation is from GitHub Releases or from source. Building needs Java 21 and the Gradle wrapper: clone the repository, then either run JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar for the full build with all 59 MCP tools, or append -PstoreBuild=true for the store build with 8 extension-native AI MCP tools. The outputs differ in name: build/libs/Custom-AI-Agent-full-<version>.jar for the full build and build/libs/Custom-AI-Agent-<version>.jar for the store build. Picking the wrong one silently costs you 51 tools, which is worth checking before you file a bug. Loading is the standard Burp path: Extensions > Installed > Add, choose Java, select the JAR. The extension registers in Burp as Custom AI Agent. Naming is inconsistent by design and worth internalising: the repository stays github.com/six2dez/burp-ai-agent, the docs site stays burp-ai-agent.six2dez.com, and the configuration directory stays ~/.burp-ai-agent/. On first run the extension auto-installs bundled agent profiles into ~/.burp-ai-agent/AGENTS/, and dropping additional *.md files into that directory adds custom profiles. Audit logging writes JSONL with SHA-256 integrity hashing, and every launch is stamped with promptSource and contextKind for reproducibility.

What the 1.0.0 hardening does not tell you

The changelog summary is unusually candid about process, and the numbers are worth reading as engineering evidence rather than marketing: the test suite grew from 660 to 1131 tests across 158 classes, line coverage went from 34% to 58%, and the detekt baseline shrank from 1096 to 1040 rather than growing. A shrinking static-analysis baseline alongside a doubling test count is the kind of signal that is hard to fake. But read the coverage number twice. 58% line coverage on a security tool that handles credentials means a substantial fraction of the code is not exercised by the suite, and the two defects that shipped in 0.9.x were found by an external review running the code, not by that suite. The other hardening items are narrower than the headline: SsrfGuard now classifies alternate IP notations so that http://2852039166/ no longer sidesteps the private/link-local warning by notation alone, and classification performs no name resolution at all; shell arguments are quoted by allowlist, closing a settings-import-to-command-execution path for values like foo;id or $(cmd); tool execution, backend HTTP and MCP stop() moved off the Swing event dispatch thread, and recurring tasks are guarded against death-by-exception. Each of those is a specific bug with a specific trigger. None of them is a general safety property, and the README does not claim otherwise.

The MCP port takeover, and why token handling changed shape

SEC-07 is the most interesting fix because it is about a local attacker rather than a remote one. The README states that a local process squatting the MCP port and echoing the identity header could previously harvest a token granting full MCP tool access. The new behaviour: the takeover client presents an HMAC proof of possession instead, and under TLS it pins the server certificate to its own keystore. That is a real change in the trust model, and it is the kind of thing that is easy to overlook when you skim a changelog for features. It also implies a constraint that the README does not spell out in the excerpt available: the proof-of-possession flow and certificate pinning are described as protections for the takeover path, and whether your particular MCP client interoperates cleanly with them is something you have to confirm against your own setup. The scoped MCP access feature is the other half of this story. The README says you can optionally confine every MCP tool to your in-scope hosts so external AI clients cannot reach out-of-scope targets through Burp. Optional is the operative word. If you enable external access and do not enable scope confinement, you have handed an external agent the same reach Burp has.

Where this is the wrong tool

Three cases stand out. First, Burp Community users who want the passive scanner: the README ties that path to Burp Pro because it is implemented as a PassiveScanCheck, so on Community you lose a headline feature. Second, anyone who wants an unmediated agent loop. The approval gate is the point of the 1.0.0 security posture, and if your workflow depends on a model firing tool calls without a human in the loop, this extension is designed to interrupt you. The README says read-only bounded tools run silently and everything else asks first, so a long autonomous chain will be punctuated by approval cards. Third, teams that need a signed, store-distributed extension with a stable vendor channel. The BApp Store submission has been open since January 2026 per the README, which means distribution is GitHub Releases plus your own build pipeline, and you own the verification. On the alternative side, Burp's built-in Burp AI provider is the obvious comparison and the README treats it as a distinct thing: it is a provider inside Burp rather than an MCP server that external agents connect to. The difference in approach is where the model runs. Burp AI keeps inference inside the product with no external client driving Burp; this extension inverts that, exposing Burp as a tool surface for an agent you run elsewhere. If your requirement is that no external process ever issues commands to Burp, the built-in provider is the closer fit and this extension is the wrong shape regardless of its feature list.

Maintenance cost and the licence question

The MIT licence is permissive and the README does not attach conditions to it, so redistribution and modification are permitted under MIT terms. That is not legal advice and the repository's LICENSE file is the authority. The maintenance picture is more interesting than the licence. This is a single-maintainer extension that talks to twelve backends, four or five CLI wrappers and an MCP surface with 59 tools, and the 0.9.x history shows what that breadth costs: two exploitable defects reached every published release in the line, and the fix required a coordinated rename, a credential-rotation advisory, and a coverage push from 34% to 58%. Anyone adopting this should budget for tracking releases closely rather than pinning once. The configuration directory ~/.burp-ai-agent/ and the AGENTS/ profile directory are the parts you will touch most, and the audit log with SHA-256 integrity hashing is the part that survives an upgrade. If you operate under a compliance regime that wants a record of what the AI was asked and in what context, the promptSource and contextKind stamps per launch are the reason to keep the JSONL log rather than discard it.

Editorial conclusion

Adopt 1.0.0 if you already run Burp Pro and want an MCP surface that external agents can drive under scope restrictions, and treat the 0.9.x upgrade as a credential-rotation event rather than a routine version bump: the SECURITY.md advisories state that the MCP token and session cookies may already have been disclosed, so rotate the MCP token and any cookie the passive scanner handled before you load the new JAR. Skip it if you are on Burp Community and your workflow depends on the passive scanner, since that path is implemented as a Burp PassiveScanCheck and the README ties it to Pro. Before trusting the build, verify three things yourself: that the JAR you downloaded is the full build rather than the store build with 8 MCP tools, that your configured privacy mode actually redacts the cookie names your target uses, and that your MCP client cannot reach out-of-scope hosts once scoped access is enabled.

Official sources

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