You Bought the Hands, Not the Brain: After Analyzing Burp AT, I Built an Open-Source Burp MCP

I opened up Burp AT’s jar looking for one thing: where does it hide the GPT client?

After a thorough search, the answer was — nowhere, because it doesn’t exist.

A Burp that can chat and autonomously run scans, yet it has no complete chat client running locally. That alone tells you something. After going through the entire jar, it clicked: the thing running locally is just a pair of hands. The brain calling the shots lives on PortSwigger’s cloud.

This post is about those hands — and how to give them a different brain. The conclusion first: Burp AT proves that “penetration testing can be handed to AI” is the right direction, but it locks the model in the cloud, doesn’t fit production environments, and creates approval fatigue. I analyzed its protocol, followed the official front door, and built an open-source burp-mcp-server — putting Burp’s hands back in your Agent’s control. No more waiting for approval on your next move.

First, What Exactly Is Burp AT?

Figure · Burp AT official product page (PortSwigger)

If you haven’t used Burp AT, here’s the one-sentence version: it’s PortSwigger’s official AI-powered automation capability for Burp Suite Pro (website) — you give it a target, and it crawls, sends requests, runs audits, and files findings on its own. It’s like having an intern who never sleeps, clicking through Burp for you.

Under the hood, it does three things:

• Wraps Burp’s core capabilities (sending requests, reading history, scanning, Collaborator, Intruder…) into dozens of atomic tools that AI can call like functions;
• Adds a task engine to manage those jobs: scans are asynchronous, with queuing, status polling, deduplication, and timeout convergence — not just blocking on a single return;
• Layers a conversation interface on top, so you describe what you want in plain language, and it orchestrates the tools behind the scenes.

The results can be genuinely impressive — drop in a target and it finds injection points on its own, faster than clicking through manually. That’s exactly why I say “handing penetration testing to AI” is the right direction.

But “sometimes impressive” and “production-ready” are two different things. That’s what we’re about to unpack.

Hands Are Local, the Brain Is in the Cloud

Let’s establish a shared vocabulary first — everything that follows hangs on this:

• Hands (capability): Burp’s local tool runtime — sending requests, reading history, scanning, feeding Intruder, Collaborator.
• Brain (orchestrator): The component that decides which tool to call next, how to interpret results, when to escalate — i.e., the model plus the Agent loop.
• Protocol: How the two sides talk (standard MCP, or AT’s own BurpAI envelope).

So in the default configuration, Burp AT is a private Agent in the cloud, using its model to drive Burp’s local capabilities (the hands). When evaluating any “AI × security tool” product, start by drawing this picture: who is the Client, who is the Server, where does the model run — that matters far more than which base model they’re using.

Figure 1 · Hands are local, the brain is swappable.

The hands haven’t moved — that’s the premise of this entire thing. The desktop tool runtime is still local; you can drive it with a different Client. The only problem is that the default Client is in the cloud, with its policies in the cloud, and you don’t control the model.

So why bother swapping the model?

Because the landscape has shifted. General-purpose models get better every year, and open-source models are thriving — the barrier to self-hosting and self-scheduling is now very low. In this environment, a security tool clinging to the “private model + cloud lock-in” model is essentially handing your data, your strategy, and your autonomy to a single vendor. Any security practitioner with ambition will want to connect their capabilities to the model of their choice: controlled model, data stays in-domain, scheduling on your own terms.

That’s exactly what this post sets out to solve.

Three Paths: Front Door, Back Channel, Custom Framework

PortSwigger actually ships two things, and I initially conflated them — which cost me some time:

• The official burp-mcp: this is the MCP line. Burp listens locally (default 127.0.0.1:9876), your Agent acts as the Client, using standard MCP. This is the front door.
• Burp AT: a closed-loop commercial Agent product. From your perspective, it has nothing to do with MCP — you use its built-in chat interface, the model runs on PortSwigger’s cloud, and the desktop connects back through a private, authenticated envelope protocol. You wouldn’t point an MCP client at AT.

The topologies are also inverted: in one, Burp is a Server waiting for connections; in the other, Burp is a Client making outbound connections. Don’t conflate them just because both involve Burp — one is an open protocol, the other is a closed product.

Three ways to put Burp under your own Agent’s control:

Figure 2 · Three ways to swap models: pick a topology, not an API-key box.

A · Front Door is my recommended default for most people: install the official mcp-server, enable the MCP tab, configure Claude Code / Desktop with SSE or a stdio proxy. The protocol is standard, the model is entirely yours, and Tools.kt is extensible. Verification is simple — tools/list from the client returns non-empty, and a single end-to-end request or proxy history read confirms it works.

B · Back Channel is an architecture-level research project: implement a BurpAI-compatible gateway locally, point the desktop AT’s reverse MCP to you instead of ai.portswigger.net, and connect your own OpenAI-compatible endpoint or custom Agent loop behind the gateway. I’ve been down this road and it deserves a specific callout:

Pointing to localhost ≠ connected.

I had ZL() reporting session already started — it looked like it worked. But Zy() never actually ran hub.connect() because of a gating condition — the session marker and the underlying transport were out of sync. So when debugging, only trust one thing: does your gateway log show an active GET /api/v1/mcp SSE, and has the state machine actually entered the connected state? Don’t let the UI popup fool you.

The minimum protocol contract for this back channel (architecture-level, no exploitation details): GET {base}/api/v1/mcp opens SSE → receive connection.accepted with mcp_connection_id → POST …/sessions/{burpai_session_id}/claim to claim → bidirectional type: mcp.message envelopes (inner payload is JSON-RPC) → handle the ~90s idle reconnect, POST 409 re-claim state machine. Common headers: Portswigger-Burp-Ai-Token, optional Bearer, Burpai-Engagement-Id, X-MCP-Connection-Id. Note: this is not bare MCP — pointing a generic MCP Client library directly at the cloud won’t work; you need to implement this authenticated envelope yourself.

A practical reminder: the base URL’s three-tier resolution (-Dburpai.mcp.url → BURPAI_MCP_URL → regional fallback; production defaults to https://ai.portswigger.net) may have the sysprop/env read path “compiled away” in certain production builds. Whether it works depends on the jar in your hands — additional measures may be necessary.

C · Custom Framework is the long-term form once you shed the AT shell: your own Agent + burp-mcp (or a custom Montoya adapter). The tool I’m about to introduce falls squarely on this path.

What I Open-Sourced, and Where It Differs

This is the section I most want to write — and the one most lacking in available materials.

I built an open-source burp-mcp-server following the official front door — it’s a fork of PortSwigger/mcp-server, preserving the official stable tool surface while adding the spine that makes a red-team automation loop actually close. Current version 1.3.0-AT, JDK 21 build, ./gradlew embedProxyJar produces a fat JAR; pre-built packages are in Releases.

Why extend it? The official burp-mcp has about twenty useful tools covering the main red-team path (HTTP/1.1, HTTP/2 requests, Repeater/Intruder delivery, Proxy history, Scanner issues, Collaborator, encoding/decoding, config import/export). But AT has roughly 54 atomic tools across 12 groups — the extra ones fill two critical gaps: low-attended automated assessment and large-scale fuzzing. No scope navigation, no scan orchestration, no queryable fuzz result surface.

My initial plan was to match all 54 tools. After listing them out, I got realistic. No need to compete on quantity — a maintainable narrow tool surface often outperforms an unmanageable wide one. So I filled gaps by closing the loop, not by chasing numbers.

The extension path is straightforward: modify Tools.kt + Montoya API, treat AT’s enumeration as a gap list reference, not a runtime dependency. Unit tests ToolsKtTest pass under JDK 21 with BUILD SUCCESSFUL.

Here’s what got added, broken down by category — which Burp capability each reuses, what the API enables, and why the original MCP couldn’t do it:

I borrowed a few of AT’s design principles — universally applicable to anyone building pentest Agents. Borrow the structure, not the trademark:

• Permission gates for dangerous operations (sending requests, scanning, deleting issues) are enforced at runtime, not through prompt-based verbal constraints;
• Long-running tasks like scans return handles and are pollable, rather than assuming sub-second tool results — an Agent that only waits for instant returns can’t do real penetration testing;
• HTTP literals from model output undergo \r\n normalization — never assume the model produces byte-level-valid HTTP;
• History and issues are paginated and truncated to protect context windows.

Try It, Give Me Feedback

Different people have different default actions:

• Red Team / Security Engineering: Burp + burp-mcp-server + your own Agent (Claude Code or custom). If the tools aren’t enough, extend Tools.kt following the P0/P1 priority — don’t start by chewing on obfuscated AT.
• Building a custom pentest framework: Prioritize standard MCP; tools carry permission and async semantics; the workbench is swappable, the model is swappable — Burp is just one workbench candidate.
• Still want to tinker with the AT shell: Back Channel B has architectural room, but verification only counts SSE, and production build details vary by version. This post doesn’t provide a bypass cookbook.

When evaluating any AI security product, draw that “hands / brain” diagram first, then talk about model names.

You bought the hands, not the brain. What matters isn’t which model name is written inside Burp — it’s who has the authority to issue tools/call.

burp-mcp-server has opened the door. Install it, connect your own model, and let me know how it goes.