AI Pentesting, Part 8: Burp Suite AI: Features, Extensions, and an Evidence-First Workflow

1. The documented built-in feature inventory

This inventory reflects PortSwigger's Burp AI capabilities and AI-extension documentation reviewed on 28 October 2026. It is a dated overview of the documented feature families, not a guarantee of every future release, BApp, edition, or account entitlement. Record your installed Burp version and inspect the feature's current controls before use. Burp AI is associated with Professional workflows; an MCP extension's availability does not grant Community users Professional Scanner or built-in AI capabilities.

Do not interpret a model's executive summary as proof that an issue is exploitable. Preserve the request/response evidence and the expected application policy alongside the output.

2. How to use Repeater and Explainer

1. Open an isolated lab project, set the exact target scope, and use synthetic accounts.
2. Capture a known-good request and save it as the baseline.
3. Select the smallest relevant evidence: a header, response field, or JavaScript function.
4. Ask Explainer for semantics, alternative explanations, and one bounded confirming check.
5. Review the proposed request before sending it; keep the positive and negative control tabs.
6. Save the final evidence independently of the AI conversation.

Explain the supplied cache-control and vary headers.
Separate standards semantics from assumptions about this application.
Identify whether the response could contain user-specific data.
Propose one lab-only comparison using two synthetic users.
Do not change scope, send requests, or infer cache leakage yet.

Example: a response has Cache-Control: private and a user-specific marker. That suggests shared caches should not store it, but application and edge behaviour still need testing. Example: an unusual cookie attribute may warrant a review, yet a missing attribute has different impact depending on transport, session use, and browser behaviour. Ask for the dependency, not just a generic finding.

For JavaScript, supply the function and callers from Part 4. Explainer can reduce reading time, but the browser trace still decides whether the source reaches the sink.

3. Explore issue and access-control validation

PortSwigger describes Explore issue as active exploration that can attempt to leverage an issue, access sensitive data, discover more surface, and identify escalation paths. Do not enable it against a real application merely because a scanner flagged a low-risk candidate. Use a disposable lab, synthetic records, explicit request budgets, and a reviewer who can intervene.

For access control, configure two lab users with known tenant ownership and stable sessions. Start from Part 3's role matrix. Check that the scanner's login state is correct and that an apparent cross-user response is not a generic error page. AI false-positive reduction can help interpretation; it cannot invent the intended policy or prove there was no side effect.

Case: two synthetic tenants, one invoice each.
Baseline: Alpha reads Alpha invoice successfully.
Negative control: Alpha requests known Beta invoice identifier.
Expected: no Beta fields and no state change.
Review: status, body marker, ownership fixture, cache behaviour.
Stop: unexpected personal data, new host, logout loop, or health alert.

Do not allow discovery to expand scope automatically. A link to an external identity provider or storage service remains outside the test unless separately approved. If the feature cannot enforce the engagement's controls, do not use that mode for that engagement.

4. Validate AI-generated login sequences

Generated sequences reduce recording friction but still need replay testing. Use dedicated accounts with non-production data. Verify successful login, reliable logged-in detection, token refresh, logout behaviour, and recovery after session expiry. MFA, CAPTCHA, device trust, passkeys, and conditional access may require human participation or a specially approved lab flow; do not weaken production identity controls for scanner convenience.

Example one: an application returns HTTP 200 on both successful and failed login. Configure a meaningful logged-in indicator rather than status alone. Example two: the sequence reaches a post-login consent screen and the scanner mistakes it for the application. Confirm the final route and accessible fixture. Example three: replay triggers repeated MFA prompts. Stop and redesign the lab account workflow instead of increasing retries.

Keep authentication automation separate from account administration. A login recorder should not gain permission to reset passwords, enrol authenticators, or consent to unrelated applications. Record the generated sequence revision and inspect it after application changes.

5. Extensions, Montoya AI, and credits

The documented extension workflow enables AI per extension through Extensions > Installed > Use AI. AI use is disabled for extensions by default. AI calls consume credits; the UI exposes balance and per-session extension usage. Set a budget and monitor it. A model loop that repeatedly explains identical traffic wastes credits without improving evidence.

The community names above identify categories and known naming patterns, not a claim that every similarly named BApp exists in your installed catalogue or is currently maintained. Review the exact release, source, permissions, and provider contract. A BApp Store review is not a guarantee of behaviour. Third-party extensions may send data through their own APIs, outside the built-in Burp AI processing path.

For extension development, prefer bounded selected-message analysis and explicit user invocation. Keep slow AI calls off the UI event thread, cap response size, redact credentials, and treat model output as untrusted text. Do not let generated output become an executable BCheck or active scan configuration without review.

6. Connect MCP without confusing the trust boundaries

The official PortSwigger MCP extension connects an external AI client to Burp. Its documented configuration uses a local listener, with an SSE server or packaged stdio proxy. The reviewed README lists 127.0.0.1:9876 as the default binding; verify the actual extension release and generated client configuration rather than copying an assumed path. Client transport support evolves, so discover the supported transport and tools at runtime.

Start with read-only history access and a bounded evidence selection. Disable configuration-edit tools unless necessary. Do not expose the listener on all network interfaces. Localhost is not authentication against every local process; apply process isolation and tool approval as well. A request body can contain prompt injection, so the assistant must not treat target content as instructions.

Session policy:
Allowed: list a bounded set of in-scope proxy entries; explain evidence.
Approval required: resend a specific reviewed request to the lab host.
Denied: new destinations, config edits, credential export, bulk traffic.
Evidence: request hash, tool call, approval identity, response hash.
Stop: scope mismatch, unexpected redirect, or budget exhaustion.

Validate the built-in AI path, each extension's provider path, and the MCP client's provider path independently. Keep the existing site's Burp MCP article as a companion architecture explanation, but use this part's dated inventory to avoid assuming older setup details remain universal. The next part applies these controls to endpoint and hardware simulations.

7. Step-by-Step Lab: Review One Lab Request with Burp AI

Prerequisites: A compatible Burp installation with the relevant licensed AI features, a synthetic local application, two approved lab identities where needed, and a budget. Feature names and availability vary by release. The offline response comparison below does not call Burp or a model.

1. Create a dedicated Burp project and configure the exact owned target scope. Use a disposable browser profile and synthetic accounts. Confirm proxy routing and certificate handling without exposing the listener on an unintended interface.
2. Capture a known-good lab request and send it to Repeater. Name the baseline tab with a case ID, account role, and fixture version. Record the expected policy before asking AI to interpret the response.
3. Select a small header or code slice for Explainer. Ask for observed facts, assumptions, competing explanations, and one minimal check. Do not send full cookie jars or private records to the model.
4. Prepare positive and negative role/object controls. Use the same known synthetic object identifier and confirm ownership from a fixture, not from response appearance alone.
5. If you use an active AI mode such as Explore issue, review its current permission and stop controls first and keep it inside an explicitly approved disposable lab. Otherwise perform the proposed comparison manually.
6. For a generated login sequence, verify real logged-in state, expiry recovery, final application route, and absence of unexpected MFA prompts. Do not weaken production identity controls for convenience.
7. Review each extension's AI permission, provider path, credit usage, and actual tool list independently. Export the final evidence and remove live secrets from the model-facing report.

const owner = { status: 200, marker: "ALPHA-SYNTHETIC" };
const denied = { status: 403, marker: null };
const genericLogin = { status: 200, marker: null };
function classify(baseline, response) {
    if (baseline.status !== 200 || baseline.marker !== "ALPHA-SYNTHETIC") return "invalid_control";
    if (response.status === 403 && response.marker === null) return "expected_denial";
    if (response.status === 200 && response.marker === "BETA-SYNTHETIC") return "candidate_policy_violation";
    return "needs_review";
}
const results = [classify(owner, denied), classify(owner, genericLogin)];
if (results.join("|") !== "expected_denial|needs_review") throw Error("response classification mismatch");
console.log(JSON.stringify(results));

Expected result: Expected denial for the explicit 403 fixture, but needs_review for an HTTP 200 response with no object marker. This small classifier illustrates why status alone is not authorisation evidence. It is not a scanner, extension, or substitute for reviewing the real policy and side effects.

8. Worked Examples and Expected Outcomes

Example A: Explainer flags an unfamiliar header

The assistant says a header may affect caching. Check standards semantics and two synthetic user responses before claiming leakage. A plausible explanation is the beginning of a test plan, not a completed finding.

Example B: login recording stops at consent

The generated sequence reaches an intermediate page and reports success. Confirm the final application marker and allowed fixture data. Update the sequence or account workflow; do not treat every HTTP 200 as authenticated coverage.

Example C: an extension has its own provider key

The extension does not necessarily use the same path or retention terms as built-in Burp AI. Inspect its exact release and destinations. A BApp review or Use AI checkbox does not establish that no separate outbound processing occurs.

AI review prompt:
Explain this selected lab response only.
Separate observed bytes from application-policy assumptions.
Propose one positive and one negative control.
Do not send requests, expand scope, edit configuration, or export credentials.
Return evidence IDs and unresolved questions.

9. Troubleshooting, Retesting, and Completion Evidence

Retest and completion: Keep Burp version, project scope, role labels, request/response evidence, login-state checks, approvals, and extension/provider review. Retest the original comparison manually after remediation. Where a feature cannot enforce the engagement controls, use a narrower mode rather than assuming operator intent constrains it.

10. Real Tool Workflow: Set Up a Burp Project, AI Permissions, and a Reviewed MCP Bridge

Prerequisites: A supported Burp installation with the features/licence required by the chosen mode, an owned loopback application, an isolated browser profile, and explicit data-processing approval. For MCP, obtain the exact official extension release and verify its current transport/client instructions; it is not installed by this article.

Use reviewed releases and record the versions actually installed. Command references for this workflow were reviewed on 29 October 2026; product support and flags can change. Instructions and output shapes are not claims of a live assessment.

Step-by-Step Tool Operation

1. Create a dedicated project and add only the exact owned origin to target scope. Open a dedicated Burp browser or explicitly configured test profile; do not capture personal browser traffic. Record Burp version and baseline application state.
2. Capture one successful synthetic request, send it to Repeater, and name it with the role, object, and case ID. Confirm manually that its response contains the expected fixture marker before any AI comparison.
3. Use Explainer on a small selected header or function. Require facts, assumptions, and one bounded follow-up. If using a mode that performs active investigation, inspect the installed feature's approvals and stop controls first.
4. For extensions, open Extensions > Installed, review the exact extension, and enable Use AI only if that implementation and data path are approved. Record per-session credit use; a third-party provider key or API can bypass assumptions about Burp's built-in AI path.
5. For the official MCP extension, inspect its release, bind the listener to 127.0.0.1, discover the actual tools, and start with bounded read access. Disable configuration-edit and send tools or require separate approval at the server/broker.
6. Export the minimal request/response evidence, verify the policy comparison manually, then disable unused AI/MCP capabilities and close the isolated project/browser. Do not leave an administrative bridge listening after the exercise.

Burp project checklist:
Help / About -> record installed version and edition.
Target scope -> exact owned loopback origin and excluded paths.
Proxy history -> one known-good synthetic baseline.
Repeater -> labelled owner and non-owner controls.
Extensions > Installed -> review Use AI, provider path, and credits.
MCP settings -> loopback binding, reviewed tools, config edits disabled.
Export -> evidence IDs, identity labels, expected policy, observed result.

java -version
Get-FileHash -LiteralPath .\reviewed-burp-mcp.jar -Algorithm SHA256
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -eq 9876 } | Select-Object LocalAddress, LocalPort, OwningProcess

Expected Evidence and Interpretation

The JAR filename is your locally reviewed extension copy, not a file bundled with this site. Port 9876 is a documented default used by some official extension releases; use the actual configured port. The listener check is Windows-specific and observes binding only; it does not authenticate the endpoint or certify the extension's permissions.

A useful result is a reproducible baseline, one reviewed comparison, and a clear separation between model explanation and sent traffic. If the read-only workflow can still issue arbitrary sends or edit configuration through another exposed tool, it is not read-only in practice.

Troubleshooting and Cleanup

If the browser captures unrelated traffic, stop and correct the test profile/scope before analysis. If the MCP client cannot connect, compare installed transport support and binding rather than opening the listener to all interfaces. If AI credits rise while evidence is unchanged, stop duplicate calls. Remove test tokens from exports and terminate the bridge through its own supported controls.