./resources / blog
Pentest · AI // 2026-08-30 // 14 min read

Burp Suite MCP: Wiring an AI Assistant into Your Pentest

PortSwigger's MCP server turns Burp Suite into a set of tools an AI assistant can drive — reading proxy history, replaying requests, and reasoning over responses while you stay in control. Used well, it removes the drudgery from a web assessment. Used carelessly, it fires live traffic at a target on the model's whim. This guide covers the architecture, the setup, the workflow, and the guardrails.

VM By Viral Maniar · Managing Director & Principal Consultant

The Model Context Protocol (MCP) is an open standard that lets an AI client — Claude Desktop, an IDE agent, or any MCP-capable app — discover and call external tools through a uniform interface. PortSwigger ships an official Burp Suite MCP Server that exposes Burp's core capabilities as MCP tools. The result: your assistant can ask Burp for the last 50 proxy entries, resend a request with a tampered header, and read the response back — all without you copy-pasting between windows.

This is genuinely useful for a pentest, but it is active testing. Every request the AI sends goes through Burp to the real target. Treat it with the same discipline you would any other offensive tool.

How it fits together

The MCP server is a Burp extension. It listens locally over Server-Sent Events (SSE), and a small proxy jar bridges that to stdio-only clients. The AI never talks to your target directly — it talks to Burp, and Burp talks to the target.

Burp MCP — architecture MCP Client Claude Desktop / IDE agent Proxy jar mcp-proxy-all.jar stdio ↔ SSE Burp MCP Server extension :9876 /sse Burp Suite Proxy · Repeater Intruder · Scanner Target app / API stdio SSE API HTTP(S) Your machine — localhost only (127.0.0.1) Preemptive Cyber Security
Figure 1. The AI drives Burp, not the target. Everything left of the target stays bound to 127.0.0.1 on your machine.

Prerequisites

  • Burp Suite (Professional or Community) with the Montoya extension API — i.e. a current release.
  • Java on your PATH (the same JRE Burp uses is fine), plus the jar command if you build from source.
  • An MCP-capable client — Claude Desktop, or an IDE/agent that speaks MCP.
  • A signed authorisation and defined scope for the target you intend to test. This is not optional.

Setup, step by step

You have two ways to get the extension: install “MCP Server” from the BApp Store (Extensions → BApp Store), or build it from source. The build is a one-liner:

git clone https://github.com/PortSwigger/mcp-server
cd mcp-server
./gradlew embedProxyJar
# → build/libs/burp-mcp-all.jar  (the extension)
# → the bundled mcp-proxy-all.jar (the stdio bridge)
Setup pipeline 01 Install extension 02 Enable MCP server 03 Configure MCP client 04 Restart client 05 Verify tools listed Preemptive Cyber Security
Figure 2. Five steps from a fresh Burp to an AI that can see your proxy history.

1 & 2 — Load and enable the server

In Burp, go to Extensions → Add, set the type to Java, and select burp-mcp-all.jar. A new MCP tab appears. Tick Enabled. The server now listens on http://127.0.0.1:9876 (host and port are configurable). Leave “Allow tools that can edit your config” off unless you specifically need it — it widens what the AI can change.

3 — Configure the MCP client

The extension ships an installer that can auto-configure Claude Desktop. To do it by hand, point your client at the bundled proxy jar. On Claude Desktop the file is %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "burp": {
      "command": "java",
      "args": [
        "-jar",
        "C:\\tools\\burp-mcp\\mcp-proxy-all.jar",
        "--sse-url",
        "http://127.0.0.1:9876"
      ]
    }
  }
}

Use the exact command shown in the MCP tab — it prints a ready-to-paste snippet for your client and OS, so you never have to guess the jar path.

4 & 5 — Restart and verify

Restart the client so it spawns the proxy and completes the MCP handshake. In Claude Desktop you should see the Burp tools listed under the tools/plug icon. Ask it something read-only first, such as “show me the last 10 entries in Burp's proxy history”. If they come back, you are wired up.

What the AI can actually do

The exact tool set evolves, but it maps onto the parts of Burp you already use. Broadly, the server exposes tools to:

  • Read proxy history — fetch recent HTTP (and WebSocket) traffic, including regex-filtered queries to find specific requests.
  • Send requests — issue new HTTP/1 and HTTP/2 requests through Burp and read the full response.
  • Drive Repeater & Intruder — create Repeater tabs and hand payloads to Intruder for iteration.
  • Work with the editor and encodings — read/replace the active editor contents and URL/Base64 encode or decode.
  • Query the scanner — pull scanner issues and their definitions for triage and write-up.
  • Manage scope and tasks — read scope and control the task engine (behind the config-editing toggle).
The model does not "hack" anything on its own — it composes these Burp tools. Its value is speed and pattern-recognition across your traffic, not autonomy.

Using it during a real assessment

The productive pattern is a tight loop: let the AI triage and propose, and keep a human decision point before anything that changes state on the target. In practice you drive it in natural language — “review the proxy history for this host, flag any endpoints reflecting user input, and show me candidate parameters for XSS” — then review its picks before it sends anything.

AI-assisted pentest loop Review history get_proxy_history Hypothesis candidate flaw Human approval in-scope? safe? Send test via Repeater Analyse response confirm / refine Document evidence + PoC approved refine loop Preemptive Cyber Security
Figure 3. A human approval gate sits between the AI's hypothesis and any request that touches the target. The refine loop lets it iterate on the analysis without re-approval until it wants to send again.

Where it shines

Three tasks pay for themselves immediately: triaging large proxy histories (“group these 4,000 requests by endpoint and flag anything handling auth tokens”), drafting and iterating payloads in Repeater while you judge the responses, and turning confirmed issues into report-ready write-ups with request/response evidence pulled straight from Burp. It is an accelerator for the tester, not a replacement.

Safety, scope, and OPSEC

Because the AI can send live requests, the controls matter as much as the capability.

Non-negotiable controls

  • Authorisation first. Only point this at targets you are contracted and permitted to test — the AI has no concept of your rules of engagement.
  • Enforce Burp target scope and keep a human approval gate before any state-changing or destructive request.
  • Bind to localhost. Keep the server on 127.0.0.1; never expose :9876 to a network.
  • Mind data egress. Proxy history can contain secrets, tokens, and PII that get sent to the model provider — check your NDA and consider an approved or local model.
  • Leave config-editing tools off unless required, and watch for prompt-injection: a malicious response in the traffic could try to steer the agent.

Limitations to keep in mind

The model can misread a response, over-claim a finding, or loop on a dead end — every result still needs a tester's validation. It also generates traffic quickly, so cap iterations on fragile or production-adjacent targets. And like any MCP setup, the security of the whole chain depends on the client you trust and the tools you enable.

#burpsuite #mcp #pentest #ai-security #tooling
All articles Scope an engagement