本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是
• 我的开源项目完整开源，无未开源部分： 是
• 我的开源项目已链接认可 LINUX DO 社区： 是
• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

---

最近在看 MCP、A2A、本地 LLM 服务时，我发现一个挺有意思的点：很多 AI Agent 相关服务已经暴露在公网或内网里了，但传统扫描工具基本只能看到“这是个 HTTP 端口”。

问题是，它们往往不只是 HTTP。

一个 MCP Server 后面可能挂着文件读写、Shell、数据库、代码仓库、CI/CD；一个开放的 Ollama / vLLM API，可能就是一块没人管的推理算力；A2A 则更像已知资产上的隐藏入口，在内网探测和二次验证里很值得看。

所以我写了个工具：AgentScan。

如果你觉得这个方向有意思，欢迎给个 Star：

GitHub - 7anX/AgentScan · GitHub

---

这个攻击面为什么值得看

以前做资产发现解决的是第一步：哪个端口开着，跑的什么服务。

但 AI Agent 这层不太一样。很多服务看起来只是普通 Web API，真正的风险藏在后面：

• MCP Server 可能暴露高权限工具调用能力
• A2A Agent Card 不适合单纯依赖公网测绘，但适合在已知资产上做路径探测
• LLM 推理 API 可能暴露模型、算力和内部使用痕迹

传统工具扫到 8000/tcp open http 就差不多结束了。但agentscan真正关心的是：这是不是 MCP？有没有认证？挂了哪些工具？能不能继续往内网资产打？

这层语义，传统扫描器基本看不到。

---

三类比较典型的暴露面

1. MCP Server

MCP 本来是给 LLM 调工具用的。文件、命令、数据库、API，只要工具挂上去，模型就能调。

问题在于，很多开发者本地调试或者内网部署时不会认真做认证。服务一旦被端口映射、反代或者测试环境带出去，就变成了一个高权限入口。

简单说：

• 挂了 filesystem，就可能读文件
• 挂了 shell，风险就会升级到命令执行
• 挂了数据库工具，就可能直接查业务数据

用 Quake 粗看一下，app:"Model Context Protocol" 能看到不少公网样本。我这里查到大概 29803 条。这个数量不一定完全准确，但足够说明 MCP 已经不是纯内网玩具了。

2. A2A Agent Card

A2A 的 Agent Card 一般在：

/.well-known/agent-card.json

它本来是 Agent 之间互相认识用的“名片”，里面会写 skills、接口、provider、endpoint 等信息。

不过 A2A 这块不太适合直接拿测绘平台硬搜。更实用的场景，是在已经拿到一批授权资产之后，主动探测这些路径：

/.well-known/agent-card.json
/.well-known/agent.json
/agent.json

如果能拿到 Agent Card，再看里面有没有私网地址、测试环境地址、JSON-RPC endpoint、skills 描述。这个时候它的价值就出来了：不是用来“海量测绘”，而是帮你理解这个 Agent 能做什么、下一步该往哪走。

这里也可以用 Quake 做个很粗的侧面观察，比如 body:"agent-card.json"。我这里能看到大概 1401 条结果。不过 A2A 不像 MCP / LLM API 那么适合直接测绘，这个数字更适合当趋势参考。

3. LLM 推理 API

Ollama、vLLM、SGLang、llama.cpp 这类服务现在太常见了，启动简单，默认配置也经常偏松。

公网暴露最直接的风险是算力被白嫖；内网暴露更值得关注的是数据流向：谁在用、跑了什么模型、有没有敏感内容被投喂进去，而这些往往不在传统 CMDB 的视野里。

识别这类服务，靠单条测绘语句不太稳——框架多，端口不固定，接口形态也有差异。更实用的做法是先按常见端口（11434、8000、8080、3000、1234、4000）拉一批候选，再用只读接口做二次确认：

AgentScan 内置了 25 个推理框架的识别模板，走的也是这套只读探测逻辑，不会往目标发推理请求。

---

公网能看趋势，内网更有价值

企业里现在到处都在试 AI：研发起 Ollama，数据团队用 MCP 连数据库，运维搭 Agent 处理工单，安全团队也会跑本地模型。

这些服务有几个共同点：

• 权限通常不低
• 认证经常很弱
• CMDB 未必登记
• 安全扫描未必覆盖

授权评估里，我更建议先做一轮存活和端口发现，把开放的 HTTP / 推理服务端口整理成目标清单，再交给 AgentScan 做二次识别。这样速度更快，也更符合实际流程。

第一步：用 fscan 拉端口

fscan -h 192.168.1.0/24 -o fscan.txt

第二步：整理成 AgentScan 认识的格式

targets.txt 最终长这样（一行一个）：

192.168.1.10:8000
192.168.1.23:11434
192.168.1.88:7860

第三步：交给 AgentScan 做语义识别

agentscan scan -f targets.txt --skip-port-scan -o results.json

可能会看到这些东西：

服务本身就是为了能干活才存在的，问题是现在谁都可能来调用它。

---

AgentScan 做了什么

AgentScan 是我用 Go 写的一个命令行工具，专门扫这几类 AI Agent 暴露面：

• MCP：支持 Streamable HTTP 和 HTTP+SSE Legacy，探测常见路径，解析协议字段和工具信息
• A2A：抓取 Agent Card，解析 skills、provider、endpoint，检查私网地址和未授权调用面
• LLM API：用 YAML 模板识别 25 个推理框架，尽量只用 GET 请求，降低对目标影响
• 报告：输出 JSON，自动生成 HTML 报告，方便红队复盘和防守方整改

安装：

git clone https://github.com/7anX/AgentScan
cd AgentScan
go build -o agentscan .

常用：

# 对已有资产清单做二次识别，推荐用法
agentscan scan -f targets.txt --skip-port-scan

# 小范围授权网段也可以直接扫
agentscan scan 192.168.1.0/24

# 只扫 MCP 暴露面
agentscan mcp 192.168.1.0/24

我从候选结果里随机抽了 50 个样本做验证，AgentScan 识别出了 15 个无鉴权 MCP 服务，总计暴露 116 个可用 tool；另外还发现 1 个 A2A 服务，以及 9 个无鉴权 LLM 平台，泄露了 154 个模型信息。

这个样本不大，但已经能说明问题：AI Agent 暴露面不是理论风险，已经有实际资产能被识别出来。

以下是 HTML 报告截图：

MCP 扫描结果：

A2A 扫描结果：

LLM API 扫描结果：

---

小结

AI Agent 相关服务正在变成一类新的基础设施。它们的特点很明显：

• 权限高
• 认证弱
• 变化快

对红队来说，这是一层新的入口；对蓝队来说，这是很快就要纳入资产治理的东西。

AgentScan 现在已经开源，欢迎使用、提 issue、补指纹，也欢迎点个 Star 支持一下。

GitHub：GitHub - 7anX/AgentScan · GitHub

---

免责声明：本文仅用于合法授权的安全研究、红队评估和企业自查。请不要扫描未授权目标。