文章总结： 本文详细介绍了BurpSuite官方MCP的集成方法与应用场景，强调其核心价值在于可控使用Burp工具而非自动攻击。文章系统阐述了连接配置、权限管理、工具选择策略，并提供了12个可落地工作流，重点指导如何通过只读整理、创建工作台和受控执行三个阶段安全地将AIAgent融入Web安全测试流程。
综合评分： 85
文章分类： WEB安全,安全工具,安全建设,渗透测试,安全运营
Burp Suite 官方 MCP：把 AI Agent 接进 Web 安全测试工作台
原创
lidasimida
lidasimida
安全学习之路
2026年6月19日 09:49
广东
在小说阅读器读本章
去阅读
Burp Suite 官方 MCP：把 AI Agent 接进 Web 安全测试工作台
适用边界：本文只讨论授权 Web 安全测试、内部安全评估、团队工作流和工具治理；不提供真实目标攻击步骤、绕过技巧、payload 构造或未授权测试方法。
目录
先给结论：Burp MCP 的重点不是“自动攻击”，而是“可控使用 Burp”
一、先把连接跑通：Burp 扩展、SSE、stdio proxy 和客户端配置
二、真正开始用之前：三类权限必须先设好
三、工具应该怎么选：按任务而不是按工具名使用
四、从只读开始：让 Agent 整理 Proxy History 和 Organizer
五、交给人工验证：让 Agent 创建 Repeater / HTTP2 Repeater 工作台
六、受控执行：什么时候才让 Agent 发送请求
七、复杂场景手册：12 个可落地工作流
八、Prompt 模板：让 Agent 按证据工程输出
九、排障手册：连不上、工具不可见、审批被拒、结果太长怎么办
十、团队落地：从个人试用到安全团队规范
FAQ：读者最容易误解的 14 个问题
专业术语注释
参考资料
先给结论：Burp MCP 的重点不是“自动攻击”，而是“可控使用 Burp”
Burp 官方 MCP 的正确打开方式，不是让模型替人做渗透测试，而是让 Agent 在授权边界内调用 Burp 的工具能力：读取历史、筛选线索、创建 Repeater 标签页、整理 Scanner 发现、记录 Collaborator 证据、辅助配置治理和输出报告草稿。
如果只讲 MCP 原理，这篇文章就没讲到点上。真正要讲清楚的是：连接成功以后，面对复杂 Web 测试场景，应该让 Agent 调哪些 Burp MCP tools、按什么顺序调、输出什么材料、哪里必须人工确认、哪里绝对不能自动化。
图 1：Burp MCP 接入架构
一、先把连接跑通：Burp 扩展、SSE、stdio proxy 和客户端配置
PortSwigger 官方仓库是 PortSwigger/mcp-server，仓库描述为 MCP Server for Burp，主要语言是 Kotlin，许可证是 GPL-3.0。本文按 v1.3.0 写，release 时间为 2026-05-26T17:56:07Z，资产为 burp-mcp-all.jar，大小 18,817,739 bytes，digest 为 sha256:c4011245ee7da0cb901b9c0435aba3d8458ab5b0e2078e1a87fd025ed93c7892。企业环境建议固定版本、校验 digest，再加载扩展。
官方 README 给出的基础链路是：先把 Burp MCP 扩展加载进 Burp Suite，再在 Burp 的 MCP tab 中启用服务，最后让 MCP Client 连接 Burp 的 SSE 服务或 stdio proxy。默认监听地址是 http://127.0.0.1:9876，这意味着它默认适合本机 Burp 与本机 AI Client 协作，不应该随便暴露到不可信网络。
| 步骤 | 做什么 | 验收标准 | 常见问题 |
| — | — | — | — |
| 1. 获取扩展 | 从官方 release 下载 JAR，或从源码执行 ./gradlew embedProxyJar 构建。 | JAR 来源固定，版本和 digest 有记录。 | 不要加载来源不明的 Burp 扩展。 |
| 2. 加载 Burp 扩展 | Burp 的 Extensions 中选择 Java 扩展并加载 JAR。 | Extensions 无报错，出现 MCP tab。 | Java 版本、JAR 路径、Burp 扩展日志。 |
| 3. 启用 MCP server | 在 MCP tab 打开 Enabled，确认 host/port。 | 默认 127.0.0.1:9876 可用。 | 端口冲突、防火墙、代理、客户端 URL 拼错。 |
| 4. 配置 Client | 支持 SSE 的客户端直连；只支持 stdio 的客户端走 proxy。 | 客户端能看到 Burp tools。 | Claude Desktop 常见模式是 stdio proxy 转 SSE。 |
| 5. 做最小验证 | 先让 Agent 只调用编码工具或只读工具。 | 能返回结果，不触发发包或配置修改。 | 不要一开始就让 Agent 发送请求。 |
手工配置 Claude Desktop 时，README 给出的形态是让 Claude 启动 Java proxy，再通过 –sse-url 指向 Burp MCP server。示意如下：
{
“mcpServers”: {
“burp”: {
“command”: “”,
“args”: [
“-jar”,
“/path/to/mcp/proxy/jar/mcp-proxy-all.jar”,
“–sse-url”,
“http://127.0.0.1:9876”
]
}
}
}
这里有一个容易忽略的工程判断：配置成功不等于可以放开使用。连接只是第一步，真正要配置的是权限。
二、真正开始用之前：三类权限必须先设好
从 v1.3.0 源码看，Burp MCP 不是完全裸奔。HTTP 请求发送会检查请求权限；HTTP history、WebSocket history、Organizer 读取会检查数据访问权限；配置写入默认由 configEditingTooling 控制。也就是说，它本身已经把“读数据”和“发请求”拆成了不同的审批面。
| 权限面 | 对应配置 / 行为 | 默认建议 | 为什么 |
| — | — | — | — |
| 数据访问审批 | HTTP history、WebSocket history、Organizer 读取会触发数据访问确认。 | 新项目先 Allow Once，不要一上来 Always Allow。 | History 里可能有 Cookie、Token、账号、内部接口和个人数据。 |
| 请求发送审批 | send_http1_request / send_http2_request 会走 host/port 审批或自动批准名单。 | 只给授权测试环境加白名单。 | 发请求会影响真实系统，和只读整理不是一个风险等级。 |
| 配置编辑开关 | Enable tools that can edit your config 控制配置写入工具。 | 默认关闭。 | Burp 配置会影响代理、扫描、上游认证、项目行为和证据可信度。 |
| 凭据过滤 | filterConfigCredentials 默认应保持开启。 | 开启。 | v1.3.0 release 明确提到 credential filter 和 malformed JSON fail closed。 |
| 本地监听 | host 默认 127.0.0.1。 | 不改成公网或泛地址。 | Burp 工作台里是敏感安全测试上下文。 |
图 2：Burp MCP 权限边界
安全地使用 Burp MCP，可以把工具分成三层：第一层只读整理，第二层创建工作台入口，第三层受控执行。只读工具可以帮你省时间；工作台入口可以让 AI 和人协作；受控执行必须有授权、审批、日志和回滚。
三、工具应该怎么选：按任务而不是按工具名使用
v1.3.0 源码中最多注册 27 个 tools，其中 3 个只在 Burp Suite Professional edition 下注册。工具很多，但使用时不要从“我能调用什么”出发，而要从“我要完成什么工作”出发。
图 3：Burp MCP v1.3.0 工具全景
| 任务 | 首选工具 | 可选工具 | 不建议一开始用 |
| — | — | — | — |
| 编码/解码/临时字段 | url_encode, url_decode, base64_encode, base64_decode, generate_random_string | get_active_editor_contents | 任何发请求工具 |
| 整理接口清单 | get_proxy_http_history, get_proxy_http_history_regex | get_organizer_items | send_http1_request, send_http2_request |
| 整理 WebSocket 线索 | get_proxy_websocket_history, get_proxy_websocket_history_regex | Organizer 工具 | 自动构造消息重放 |
| 把线索交给人验证 | create_repeater_tab, create_repeater_tab_http2 | set_active_editor_contents | 自动扩大测试范围 |
| 准备参数化测试 | send_to_intruder | Repeater 工具 | 无人值守跑高频测试 |
| 读取扫描发现 | get_scanner_issues | Organizer 工具 | 让 Agent 直接下最终漏洞结论 |
| OOB 证据闭环 | generate_collaborator_payload, get_collaborator_interactions | Scanner issue 关联 | 未授权目标上的外带验证 |
| 配置治理 | output_project_options, output_user_options | set_project_options, set_user_options | 默认开放配置写入 |
| 控制 Burp 状态 | set_proxy_intercept_state, set_task_execution_engine_state | 当前编辑器工具 | 让 Agent 频繁切换影响人工操作 |
图 4：Burp MCP 使用决策树
这个决策树的核心是：让 Agent 先读和整理，再创建工作台入口，最后才考虑受控执行。大多数团队第一次接入时，第一周只应该使用只读和 Repeater 创建能力。
四、从只读开始：让 Agent 整理 Proxy History 和 Organizer
只读模式是最适合落地的第一步。你先用 Burp 正常代理授权测试流量，然后让 Agent 调用 history 和 Organizer 工具，把材料整理成测试清单、接口地图、证据索引和复核任务。
场景 1：从 Proxy History 生成接口资产清单
材料：授权测试期间经过 Burp Proxy 的 HTTP 请求和响应。
工具链：get_proxy_http_history(count, offset) 分页读取；必要时用 get_proxy_http_history_regex(regex, count, offset) 缩小范围。
Agent 输出应该包含：host、method、path、status、content-type、是否登录后访问、是否包含敏感头、是否值得人工复核。不要输出完整 Cookie 和 Authorization 原文。
人工确认点：剔除第三方域名、静态资源、非授权目标和含个人数据的响应；确认接口是否属于本次授权范围。
可用提示词：
只使用 Burp 的只读 history 工具。请按授权目标范围整理接口清单：
-
按 host / method / path / status 聚合。
-
标记登录、上传、管理、支付、导出、回调、WebSocket 入口。
-
不要调用 send_http1_request、send_http2_request、send_to_intruder、set_* 工具。
-
不要输出 Cookie、Authorization、Set-Cookie 原文，只说明是否存在。
-
最终输出：事实、推断、待人工确认问题、不能证明什么。
场景 2：用 regex 工具筛选高价值入口
材料：Proxy History 中已有请求。
工具链：get_proxy_http_history_regex，筛选登录、上传、导出、管理、回调、token、api 等线索。这里的 regex 是筛选，不是漏洞判断。
输出方式：每个候选入口必须写“为什么值得看”和“还缺什么证据”。比如“路径像导出接口”只能算线索，不能直接写成越权或数据泄露。
人工确认点：regex 命中的请求可能只是静态资源、前端路由或第三方服务，必须回到 request/response 和业务语义核对。
场景 3：用 Organizer 做测试任务板
材料：安全工程师在 Burp Organizer 里维护的请求、备注、状态和 id。
工具链：get_organizer_items(count, offset) 和 get_organizer_items_regex(regex, count, offset)。
使用方式：让 Agent 把 Organizer 中的状态拆成“待验证、已复核、误报、待修复、待回归”，再为每个条目补齐证据编号和下一步动作。
人工确认点：Organizer 是协作状态，不是事实本身。Agent 可以整理状态，但不能因为 Organizer 备注里写了“疑似”就把它改写成“确认漏洞”。
五、交给人工验证：让 Agent 创建 Repeater / HTTP2 Repeater 工作台
真正高价值的用法，是让 Agent 把线索交回 Burp 工作台，而不是在聊天窗口里直接给结论。Repeater 标签页是人机协作最自然的边界：Agent 整理材料，人控制请求、观察响应、决定结论。
场景 4：HTTP/1.1 请求进入 Repeater
材料：一条授权范围内、值得人工复核的原始 HTTP/1.1 请求。
工具链：create_repeater_tab(tabName, content, targetHostname, targetPort, usesHttps)。
Agent 应该做：用清晰标签页命名，例如“待验证-订单详情-权限边界”；把原始请求放进 Repeater；同时在文本输出里说明为什么需要人工验证。
人工确认点：检查目标、端口、HTTPS、请求头、body、账号上下文和业务影响。Agent 不应该自动扩展到其他用户、其他目标或其他参数。
场景 5：HTTP/2 请求不要塞进 HTTP/1.1 模板
v1.3.0 新增 create_repeater_tab_http2，这点很重要。HTTP/2 有 pseudo headers，例如 :method、:path、:scheme、:authority。源码里的工具说明也强调：HTTP/2 工具不要把 headers 放进 body。
工具链：create_repeater_tab_http2(tabName, pseudoHeaders, headers, requestBody, targetHostname, targetPort, usesHttps)。
正确用法：pseudo headers 单独放，普通 headers 单独放，body 单独放。Agent 输出里要说明字段映射，而不是只说“已创建 Repeater”。
人工确认点：如果 HTTP/2 请求被错误降级或 header/body 混在一起，验证结果可能不可信。现代 Web、API 网关和移动端网关里，这个问题非常常见。
场景 6：当前编辑器内容辅助，而不是替人乱改
工具链：get_active_editor_contents 和 set_active_editor_contents。
适合场景：你在 Burp 的请求编辑器里选中或聚焦某个请求，让 Agent 读取当前内容，帮你解释字段、整理头部、生成注释或把格式修正成更清晰的版本。
边界：set_active_editor_contents 会写当前可编辑区域。它适合格式整理和工作台协作，不适合让 Agent 在你没看见的情况下改请求并发送。
六、受控执行：什么时候才让 Agent 发送请求
send_http1_request 和 send_http2_request 是真实发请求能力，和读取 history 完全不是一个风险等级。源码里它们会走 HttpRequestSecurity.checkHttpRequestPermission：如果开启请求审批，会弹出目标确认；也可以对 host 或 host:port 做自动批准。
| 使用模式 | 是否建议 | 条件 |
| — | — | — |
| 本地靶场、内部测试环境、明确授权接口 | 可以谨慎使用 | host/port 在授权范围内；请求目的明确；有日志。 |
| 生产环境单点复核 | 谨慎使用 | 人工确认目标、方法、参数、账号、业务影响。 |
| 未知目标批量探测 | 不建议 | 不符合授权边界，风险不可控。 |
| 让 Agent 自己决定下一批请求 | 不建议 | 容易扩大范围、改变业务状态或制造噪声。 |
send_http2_request 还要特别注意字段分层。工具参数中有 pseudoHeaders、headers、requestBody，这不是形式主义，而是避免把 HTTP/2 请求错误地编码成普通文本。
可用提示词：
你只能在我明确批准后调用 send_http1_request 或 send_http2_request。
每次准备发送前，先输出：
-
目标 host、port、HTTPS。
-
请求方法和路径。
-
是否会改变服务端状态。
-
为什么需要真实发送，而不是创建 Repeater 交给人工。
没有我回复“批准发送”，不得调用发送工具。
七、复杂场景手册：12 个可落地工作流
下面这部分是本文的重点。它不是攻击步骤，而是公开工具能力下的授权测试工作流：材料是什么、怎么让 Agent 使用 Burp MCP、人工在哪里接管、最后交付什么。
工作流 1：新项目接入后的“只读盘点”
材料：浏览器代理到 Burp 后的正常业务流量。
工具链：get_proxy_http_history -> 去重聚合 -> 输出接口清单。
Agent 任务：按 host、path、method、status、content-type 做聚合；标记登录后接口、文件上传、导出、回调、管理路径、长响应和错误响应。
输出物：接口资产表、待复核入口、排除项、敏感字段摘要。
不能做：不要自动发请求，不要把 Cookie 原文写进报告，不要把“接口看起来敏感”写成“漏洞成立”。
工作流 2：授权范围核对
材料：授权目标清单和 Proxy History。
工具链：get_proxy_http_history_regex 用 host 或路径筛选。
Agent 任务：把 history 里的 host 与授权清单比对，列出授权内、授权外、无法判断三类。
输出物：范围核对表。授权外请求只用于提醒清理，不进入测试。
工作流 3：登录态与身份边界整理
材料：登录、退出、刷新 token、权限切换相关请求。
工具链：history regex 筛选 login、logout、token、session、auth 等关键词，再人工复核。
Agent 任务：整理身份链路：哪里发放会话，哪里刷新，哪里返回权限信息，哪些请求带认证头。
输出物：身份链路图和待复核问题。不要输出凭据原文。
工作流 4：前后端接口状态机梳理
材料：一段完整业务流程，例如创建订单、提交审批、导出报表、上传附件。
工具链：history 读取 + Organizer 状态整理。
Agent 任务：把请求按时间线还原成状态机：入口、前置条件、状态字段、后续动作、失败响应。
输出物：业务状态机草图、关键请求编号、人工验证清单。
工作流 5：把候选问题送到 Repeater
材料：被标记为“需要复核”的请求。
工具链：create_repeater_tab 或 create_repeater_tab_http2。
Agent 任务：创建标签页，命名清楚，附带验证假设和不能证明的内容。
输出物：Repeater 标签页 + 验证说明。真正的修改请求、观察响应、判断影响由人完成。
工作流 6：HTTP/2 网关与移动端 API 复核
材料：HTTP/2 请求、伪头、普通头和 body。
工具链：create_repeater_tab_http2，必要时才用 send_http2_request。
Agent 任务：把 pseudo headers 与普通 headers 分离，避免把 headers 写进 body；说明哪些字段来自原请求。
输出物：HTTP/2 Repeater 标签页、字段映射表和人工复核点。
工作流 7：WebSocket 业务线索整理
材料：WebSocket history。
工具链：get_proxy_websocket_history 或 get_proxy_websocket_history_regex。
Agent 任务：按连接、方向、时间、消息类型、业务动作整理消息，不自动重放。
输出物：WebSocket 消息时间线、候选状态字段、人工验证点。
工作流 8：Scanner issue 归并和报告草稿
材料：Burp Suite Professional 的 Scanner issues。
工具链：get_scanner_issues(count, offset)。
Agent 任务：按资产、风险类型、严重性、置信度、重复路径归并；把每个 issue 拆成事实、证据、影响推断、待复核项和修复建议。
输出物：报告初稿和复核清单。不能做：只凭 Scanner issue 直接写“确认漏洞”，尤其是业务逻辑类问题。
工作流 9：Collaborator OOB 证据闭环
材料：授权测试中需要记录带外交互的场景。
工具链：generate_collaborator_payload -> 人工在授权场景中使用 -> get_collaborator_interactions(payloadId)。
Agent 任务：记录 payload ID、查询交互、按时间线整理 DNS/HTTP/SMTP 等交互信息。
输出物：OOB 证据链。必须写清“能证明发生过交互”，但不自动夸大成完整影响结论。
工作流 10：Intruder 准备，不是自动攻击
材料：授权测试环境中的参数化请求。
工具链：send_to_intruder。
Agent 任务：把请求送到 Intruder，标注候选参数位置和验证目的。
人工确认点：payload 来源、数量、速率、停止条件、账号、环境和业务影响全部由人决定。
输出物：Intruder 标签页和执行前检查单，而不是自动开始攻击。
工作流 11：Burp 配置快照与变更审计
材料：项目配置、用户配置、团队基线。
工具链：output_project_options、output_user_options；只有审批后才使用 set_project_options、set_user_options。
Agent 任务：导出配置、过滤凭据、生成 diff 摘要、标出会影响代理/扫描/认证/范围的变更。
输出物：配置快照、差异说明、审批记录、回滚路径。
工作流 12：交付报告前的证据索引
材料：history、Organizer、Repeater 标签、Scanner issues、Collaborator interactions 和人工复核记录。
工具链：只读工具 + Organizer 工具。
Agent 任务：把每个结论绑定到证据编号：请求编号、响应摘要、扫描 issue、OOB interaction、人工复核结论。
输出物：报告证据索引。没有证据编号的结论不能进入最终报告。
八、Prompt 模板：让 Agent 按证据工程输出
Burp MCP 最容易出问题的不是工具本身，而是你给 Agent 的任务太松。不要说“帮我测一下这个站”，应该说清楚允许的工具、禁止的工具、输出格式和人工闸门。
模板 1：只读接口盘点
你现在只能使用 Burp MCP 的只读工具：get_proxy_http_history、get_proxy_http_history_regex、get_organizer_items。
禁止调用 send_http1_request、send_http2_request、send_to_intruder、set_*。
请输出：
-
接口清单。
-
授权范围外请求。
-
候选高价值入口。
-
每个入口为什么值得人工复核。
-
不能证明什么。
不要输出 Cookie、Authorization、个人数据原文。
模板 2：创建 Repeater 交接
请从候选请求中选择最需要人工复核的 3 条。
你可以调用 create_repeater_tab 或 create_repeater_tab_http2。
每个标签页命名格式：待验证-业务对象-验证假设。
创建后输出：原始证据、验证假设、人工需要观察的响应字段、不能证明什么。
不得调用 send_http1_request 或 send_http2_request。
模板 3：Scanner issue 归并
只读取 get_scanner_issues。
请按资产、漏洞类型、严重性、置信度归并。
对每一类输出：事实、证据、可能影响、误报可能、人工复核步骤、修复建议。
不要把 Scanner 发现直接写成最终确认结论。
模板 4：受控发请求审批
你准备调用发送请求工具前必须先停下来，输出待审批摘要：
目标 host/port/HTTPS、method/path、请求是否可能改变状态、为什么不能只创建 Repeater。
只有我明确回复“批准发送”后，才允许调用 send_http1_request 或 send_http2_request。
九、排障手册：连不上、工具不可见、审批被拒、结果太长怎么办
| 问题 | 可能原因 | 处理方式 |
| — | — | — |
| Client 看不到 Burp tools | Burp 没开、扩展没加载、MCP server 未启用、stdio proxy 路径错误。 | 先在 Burp MCP tab 确认 Enabled，再核对 –sse-url 和 Java 路径。 |
| SSE 连接失败 | URL 是否需要 /sse、端口冲突、host 配置不一致。 | 尝试 http://127.0.0.1:9876 和 /sse 两种客户端口径。 |
| 读取 history 被拒 | requireDataAccessApproval 开启，用户选择了 Deny。 | 在 Burp 弹窗里 Allow Once 或按项目决定 Always Allow。 |
| 发送请求被拒 | 目标 host/port 未审批，或不在 auto approve targets。 | 人工确认目标后 Allow Once、Always Allow Host 或 Always Allow Host:Port。 |
| HTTP/2 请求异常 | headers 被塞进 body，pseudo headers 没分离。 | 使用 create_repeater_tab_http2 / send_http2_request 的结构化字段。 |
| 配置写入失败 | configEditingTooling 默认关闭。 | 不要直接打开；先导出配置、审 diff，再临时开启。 |
| 返回内容被截断 | 源码对序列化结果有截断保护，长 history 需要分页。 | 使用 count / offset 分批读取，先聚合摘要。 |
| 当前编辑器为空 | Burp 焦点不在可编辑 JTextArea 上。 | 先点击 Repeater 或可编辑请求区域，再调用 editor 工具。 |
十、团队落地：从个人试用到安全团队规范
团队不要一上来把全部工具交给 Agent。建议分三阶段推进。
| 阶段 | 打开的工具 | 禁止或审批的工具 | 验收标准 |
| — | — | — | — |
| 第一阶段：只读辅助 | 编码、history、Organizer、Scanner issue 读取。 | send、Intruder、Collaborator、set options。 | 能整理清单，不泄露敏感数据，不误写结论。 |
| 第二阶段：工作台协作 | create Repeater、HTTP/2 Repeater、当前编辑器辅助。 | send、Intruder、配置修改仍需审批。 | Agent 能把线索交给人工验证。 |
| 第三阶段：受控执行 | 特定测试环境里的 send、Collaborator 查询、配置快照。 | 生产环境无人值守执行、自动扩大范围。 | 每次执行都有审批、日志、证据编号和回滚。 |
落地时还要记录四件事：mcp-server 版本和 JAR digest、Burp 版本、MCP Client 版本、每次测试的授权范围。否则出了问题，很难复盘到底是模型误判、工具误用、配置错误，还是人为越权。
FAQ：读者最容易误解的 14 个问题
Burp MCP 是官方项目吗？
是。本文讨论的是 PortSwigger GitHub 组织下的 PortSwigger/mcp-server 仓库。
它是不是 Burp 桌面版内置功能？
本文不把它写成 Burp Desktop release 的内置新增功能，而是按 PortSwigger/mcp-server 官方仓库和 release 口径写。
它能不能自动完成安全测试？
不应该这样理解。它能调用 Burp 能力，但漏洞判断、授权范围、业务影响、速率控制和修复结论仍然要人负责。
Community 版能不能用？
基础工具可以使用；get_scanner_issues、generate_collaborator_payload、get_collaborator_interactions 按源码逻辑只在 Burp Suite Professional edition 下注册。
为什么读取 history 也要审批？
history 里可能包含 Cookie、Authorization、内部接口、账号信息和个人数据，所以它不是低敏数据。
为什么发请求要单独审批？
发请求会触达真实系统，可能改变状态或产生业务影响；这和读取已有历史不是一个风险等级。
Always Allow Host 和 Always Allow Host:Port 怎么选？
更稳妥的是 host:port。host 级别更宽，适合明确知道该 host 所有相关端口都在授权范围内的情况。
什么时候用 Repeater，什么时候用 send_http？
默认先用 Repeater。只有在授权环境、目的明确、人工批准后，才让 Agent 直接 send。
HTTP/2 工具为什么要单独用？
HTTP/2 的 pseudo headers 和普通 headers/body 要分层，v1.3.0 专门新增 HTTP/2 Repeater 工具就是为了解决这个使用问题。
WebSocket 能不能让 Agent 自动重放？
本文不建议。更稳妥的做法是先读取和整理 WebSocket history，再由人工决定是否、如何在授权环境中复核。
Collaborator 结果能直接证明漏洞吗？
不能。它能证明出现过某类带外交互，但具体影响、触发链路和业务风险仍要人工复核。
Scanner issue 能不能直接进报告？
不能直接进最终结论。它应该先被归并、去重、复核误报，再绑定证据和修复建议。
配置写入工具应该开吗？
默认不开。需要变更 Burp 配置时，先导出、审 diff、审批，再临时开启写入。
最推荐的第一条实践是什么？
只读整理 Proxy History。它风险低、收益高，最容易让团队看见 MCP 的价值。
专业术语注释
MCP：Model Context Protocol，模型上下文协议，用于让 AI Client 通过统一接口访问工具、资源和上下文。
SSE：Server-Sent Events，一种服务器向客户端持续推送事件的 HTTP 机制。
stdio proxy：通过标准输入输出与 MCP Client 通信，再把请求转发给 Burp SSE MCP server 的代理进程。
Montoya API：Burp Suite 现代扩展 API，Burp MCP 通过它访问 Proxy、Repeater、Intruder、Scanner 等能力。
Repeater：Burp 中用于手动修改并发送单个请求、观察响应的工具。
Intruder：Burp 中用于参数化测试请求位置的工具，必须控制授权范围、速率和业务影响。
Scanner：Burp Suite Professional 的自动化扫描能力。
Collaborator：Burp 用于记录带外交互的服务能力，常用于授权测试中的 OOB 证据闭环。
OOB：Out-of-band，带外交互，指目标系统通过 DNS、HTTP、SMTP 等链路与测试方控制服务发生交互。
Organizer：Burp 中用于整理请求、状态、备注和测试任务的工作区能力。
Credential filtering：凭据过滤，导出配置或上下文时识别并过滤敏感凭据。
Auto approve target：Burp MCP 中用于自动批准特定 host 或 host:port 请求发送的目标名单。
参考资料
PortSwigger/mcp-server GitHub repository
https://github.com/PortSwigger/mcp-server
PortSwigger/mcp-server v1.3.0 release
https://github.com/PortSwigger/mcp-server/releases/tag/v1.3.0
Burp Suite MCP Server Extension README
https://github.com/PortSwigger/mcp-server/blob/main/README.md
PortSwigger MCP Proxy repository
https://github.com/PortSwigger/mcp-proxy
Model Context Protocol security best practices
https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
PortSwigger Burp Repeater documentation
https://portswigger.net/burp/documentation/desktop/tools/repeater
PortSwigger Burp Intruder documentation
https://portswigger.net/burp/documentation/desktop/tools/intruder
PortSwigger Burp Collaborator documentation
https://portswigger.net/burp/documentation/collaborator
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全学习之路 lidasimida
lidasimida《Burp Suite 官方 MCP：把 AI Agent 接进 Web 安全测试工作台》