为 AI 代理提供侦察工具箱：将 30+ 安全工具接入 MCP 服务器

Source: Dev.to

介绍

如果你曾看到一名初级渗透测试员在周一上午在全新的 EC2 实例上敲入相同的六条命令，你就已经近距离目睹了侦察环境的开销。

amass enum -passive -d $TARGET
subfinder -d $TARGET -silent | httpx | naabu
# feed surviving hosts into nuclei, dump JSON somewhere, repeat next quarter when the scope changes

工作本身并不难，难的是把它们粘合在一起。我接触的每个团队至少重写过两次这套粘合代码，且每次通常使用不同的语言。

本文讨论的是问题的另一种形态：当你不再自行编写粘合代码，而是将侦察工具箱公开为 MCP 工具，让 AI 代理调用时会发生什么？

为什么选择 MCP，尤其是它

代理已经通过定制的函数调用适配器进行“工具使用”好几年了。这些适配器的问题在于，每个代理框架都想要自己的 JSON 结构，每个工具都需要自己的身份验证，而每个团队又会编写自己的重试/超时/速率限制中间件。

MCP（Model Context Protocol） 将所有这些都压缩成一个服务器端合约。一旦你的工具成为 MCP 工具，任何符合规范的客户端——Claude Desktop、Cursor、你自己的 LangGraph 代理——都可以驱动它们。

对于 Recon（资产侦察），其价值是非对称的。Recon 是少数 迭代 且 分支 的安全工作流之一：

enumerate subdomains → resolve → port‑scan live hosts →
fingerprint services → run targeted vuln checks → pivot to new assets →
loop

这个循环正是 LLM 擅长编排的形态，前提是工具返回结构化数据且代理能够在状态中保存清单。你不希望 LLM 直接运行 nmap，而是希望它决定 何时 运行 nmap 以及 针对什么 目标运行。

我们封装了什么

在 HailBytes ASM（完全披露，这正是我们的产品——专为渗透测试公司和 MSSP 构建）中，MCP 服务器暴露的表面与 REST API 完全相同：

• Discovery：start_subdomain_scan、start_port_scan、start_dns_scan
• Vulnerability：start_nuclei_scan、start_template_scan
• Inventory：list_assets、get_asset_history、diff_scans
• Reporting：export_findings、get_scan_summary

每个工具返回的都是具有稳定模式的 JSON——而不是日志抓取——因此代理能够在不需要模型解析 stderr 的情况下规划多步骤工作流。

工作循环

一次真实的会话如下（摘自我们内部评估运行之一的改写）：

User: "Map the external attack surface for example.com and flag anything that looks like an exposed staging environment."

Agent → start_subdomain_scan(domain="example.com")
Agent → list_assets(scan_id=...)          // 312 hosts
Agent → start_port_scan(targets=[...], top_ports=1000)
Agent → start_nuclei_scan(targets=live_hosts, severity=["medium","high"])
Agent → list_assets(filter="hostname matches /staging|stg|dev|qa/")
Agent → get_asset_history(asset_id=...)   // appeared 6 days ago
Agent → "Found 4 hosts matching staging‑like patterns; one (stg-admin.example.com) appeared 6 days ago and exposes a Jenkins instance with a known CVE..."

有趣的部分在于代理 doesn’t 做的事情：它不执行外部命令，不管理 AWS 凭证，不担心速率限制，也不重新实现扫描差异化。MCP 工具会处理这些。代理真正困难的工作是——选择下一步行动。

什么出了问题（以及我们做了哪些更改）

• 分页会导致代理崩溃。 我们的第一版在单个响应中返回所有资产。实际项目中有 30k+ 子域名时，代理的上下文在进入分析步骤前就已填满。我们添加了游标分页和一个 summarize_assets 工具来返回聚合信息。
• 隐式状态是敌对的。 代理很难记住“最近一次扫描”。现在每个需要 scan_id 的工具都必须显式提供，即使只运行过一次扫描。
• 长时间运行的扫描需要状态协议。 侦察扫描可能需要几分钟到几小时。我们添加了 wait_for_scan(scan_id, timeout)，让代理能够礼貌地阻塞，而不是在紧密循环中轮询。

适用场景

如果你已经在内部运行 recon，则无需购买任何东西来尝试此模式——只需将自己的脚本封装在 MCP 服务器中，你就能获得约 70% 的价值。更困难的部分是那些在生产规模下出现的挑战：扫描差异、跨运行的资产去重、多租户隔离、计划的执行节奏、合规审计日志。这正是我们过去一年所投入的工作。

如果你想看到完整的端到端演示，平台位于 hailbytes.com/asm —— 可从 AWS 或 Azure Marketplace 部署，在你的账户中运行，并且开箱即用地暴露 MCP 端点。

无论如何，我认为 MCP 原生的安全工具将在 18 个月内成为默认。“代理只能读取 Splunk 仪表盘” 与 “代理能够驱动一次 recon 任务” 之间的差距正在快速缩小，提前搭建自有工具箱的团队将拥有真正的优势。