AgentHound：把 AI Agent 基础设施画成攻击路径图
AI agent 进入团队工具链之后，安全边界变得很碎。以前你可能主要盯应用、数据库、CI、云账号；现在还要盯 MCP server、A2A endpoint、本地 agent client 配置、模型网关、向量库、notebook、Open WebUI、LiteLLM、Ollama，以及散落在工作目录里的指令文件。单独看每个点都像是普通配置，连起来看才会出现真正的问题：一个本地 token 能不能访问某个 MCP resource？一个 agent card 会不会把权限委托到另一个服务？某个 notebook、vector collection 或模型网关是否把内部数据暴露给了不该拿到它的调用方？
今天看的是 adithyan-ak/AgentHound。它把自己定位为 AI agent infrastructure 的 offensive security framework，但更容易理解的说法是：它试图把 agentic stack 里的配置、凭据、服务、资源和跨协议关系收集成一个 artifact，再在分析端组织成攻击路径图。对红队来说，这是 foothold 后快速摸清 agent 面的工具；对蓝队和平台工程团队来说，它提醒我们：agent 生态的风险不只是“某个 prompt 被注入”，而是多个 agent 工具面和身份边界串在一起之后的路径问题。
按 GitHub repository page、GitHub API、README、CHANGELOG、LICENSE、latest release 和最近 commit 在 2026-08-22 18:10 Asia/Shanghai 能核验的公开信息，adithyan-ak/AgentHound 当前有 269 stars、57 forks。仓库主语言是 Go，许可证是 Apache-2.0。仓库创建于 2026-04-05 20:37:16 UTC，最近公开 push 是 2026-08-22 07:55:01 UTC，默认分支是 main。最新 GitHub Release 是 1.1.0，发布时间 2026-08-20 05:10:51 UTC。最近 commit 是 b50de7c6657f，信息为 “build(deps): bump the actions-all group across 1 directory with 10 updates (#132)”，commit 时间 2026-08-22 07:25:13 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | adithyan-ak/AgentHound |
| 定位 | AI agent 基础设施的授权安全评估与攻击路径分析工具 |
| Stars | 269 |
| Forks | 57 |
| 主要语言 | Go |
| 许可证 | Apache-2.0 |
| 创建时间 | 2026-04-05 20:37:16 UTC |
| 最新 push | 2026-08-22 07:55:01 UTC |
| 默认分支 | main |
| 最新 GitHub Release | 1.1.0，2026-08-20 05:10:51 UTC |
| 最近 commit | b50de7c6657f，build(deps): bump the actions-all group across 1 directory with 10 updates (#132) |
| 关键词 | MCP、A2A、AI security、red team、attack paths、model gateways、agent clients |
为什么 agent 基础设施需要图谱视角
传统资产扫描喜欢列清单：开放端口、依赖版本、云资源、证书、配置项。Agent 基础设施当然也需要清单，但只看清单会漏掉最关键的风险：权限和数据经常通过工具调用链传播。一个 agent client 的配置文件里有 MCP server；MCP server 又暴露资源和工具；工具背后可能连着 notebook、向量库、模型网关或内部 API；某个 bearer token 看起来只是一行环境变量，但它实际能抵达哪些服务，要沿着协议和配置关系才能看清。
AgentHound 的 README 强调它会覆盖 MCP、A2A、agent clients、model gateways、inference servers、vector stores、MLOps 和 notebooks 这些平面。它不是只问“这里有没有 secret”，而是把 secrets、服务、资源、身份、工具能力和验证证据组织成关系。README 里列出的 graph primitives 包括 reachability、execution、exfiltration、impersonation、shadowing、poisoned descriptions 和 tainted data flow 等方向。这里的重点不是术语，而是评估方式：你需要知道一条链是否能从某个 foothold 走到敏感资源，而不是只知道某个配置项存在。
这个思路对 agent 平台团队尤其有用。现在很多团队先把 Claude Desktop、Cursor、Windsurf、VS Code 插件、内部 MCP server、LiteLLM、Ollama、Jupyter 和向量数据库拼起来，等业务流程跑通后再补权限边界。问题是 agent 工具的可组合性越强，边界越容易靠默认配置和人肉约定维持。把关系图跑出来，至少能逼团队回答几个具体问题：哪些 agent 配置能接触到真实凭据？哪些本地服务默认监听在可达地址？哪些工具描述或指令文件值得被当作输入面审计？哪些路径只是推测，哪些路径有实际证据？
它和普通 secret scanner 不一样
AgentHound 会处理凭据，但它不是简单的 secret scanner。普通 scanner 擅长发现“这里有一个疑似 key”，然后把结果丢给人排查。AgentHound 更关注这个 key 在 agentic stack 里能带来什么可验证路径。README 和 1.1.0 changelog 都强调，它会把收集、服务指纹、兼容凭据复用、证据和分析 artifact 放到同一条工作流里。
这也是它需要被谨慎对待的地方。项目 README 明确写了 authorized use only，并说明默认扫描会进行 active validation；安全文档也解释了 active 与 stealth 模式的差异。换句话说，它不是那种可以随手扔进任意环境“看看结果”的观察工具。它面向的是有授权边界的评估：红队拿到 foothold 后要快速保全证据，或者安全团队在自有实验环境里验证 agent 工具链的暴露面。
工程上有个值得注意的选择：collector 和 analysis server 分工。README 提到 collector 侧不需要数据库或 server connection，扫描结果先落成 JSON artifact；分析端再把 artifact 变成可查询的攻击图。这种形态适合评估现场，因为 foothold 可能很短暂，能先留下结构化证据比现场搭一整套服务更现实。另一方面，分析端涉及 Neo4j、PostgreSQL 和 dashboard，就应该放在受控网络里，而不是让它变成另一个暴露面。
可以怎么看待它的使用场景
第一个场景是 agent 平台上线前的安全走查。假设团队已经有几个内部 MCP server、一个模型网关和一套 agent client 配置模板。你可以在隔离环境里准备代表性的配置和服务，运行授权评估，检查工具和资源之间是否出现意外可达路径。这个过程的价值不只是发现 bug，也能帮助团队定义 baseline：哪些路径允许存在，哪些路径必须被网络、身份或工具权限切断。
第二个场景是红队或内审做 foothold 后的 agent 面枚举。传统内网评估会关心域、云元数据、CI secrets、数据库连接串；agent 时代还要关心 MCP 配置、agent instruction files、local model services、notebook token 和向量库。AgentHound 的卖点是把这些东西放进同一张图里，减少“每个服务单独扫一遍，然后靠人脑拼图”的成本。
第三个场景是事故复盘。Agent 相关事故往往不是单点故障，而是“某个配置暴露 + 某个工具描述可信度过高 + 某个凭据权限过宽 + 某个服务默认可达”叠在一起。攻击路径图可以把这些条件拆开，帮助团队决定修哪里：是收紧 MCP server 的资源权限，还是把模型网关从 loopback 以外的地址隔离，还是让 agent client 配置不再携带高权限 token。
Caveats
第一，AgentHound 是 offensive security 工具，不是日常 observability agent。README 说默认模式会做 active validation，并且会保存 plaintext evidence。安全文档也明确提醒 JSON artifact 里可能包含具体凭据、服务内容、action 结果和恢复数据。使用它时，artifact 的存储、传输、删除都应该按证据和敏感数据处理流程来做。
第二，项目还很年轻。仓库创建于 2026-04-05，latest release 是 1.1.0，stars 269。这个成熟度对小众安全工具来说不算差，但也意味着接口、模块覆盖和分析模型可能还会快速变化。把它纳入正式流程前，最好先用固定 fixture 和测试环境验证输出稳定性。
第三，覆盖范围很宽，误读风险也会随之增加。MCP、A2A、agent clients、model gateways、vector stores、notebooks 这些东西的部署方式差异很大。Graph 里出现一条 inferred path，并不等于生产环境一定可利用；反过来，没有出现路径，也不代表不存在风险。它适合作为授权评估中的证据收集和路径建模工具，而不是最终判定器。
第四，它会让团队直面 agent stack 的权限债。很多问题不是 AgentHound 引入的，而是扫描后终于被看见：本地配置里放了长期 token，MCP resource 没有足够的访问控制，notebook 或向量库默认暴露，工具描述可以被污染。修这些问题通常需要平台、开发和安全团队一起改流程。
总结
adithyan-ak/AgentHound 有意思的地方，是它把 AI agent 安全从单点检查推进到路径分析。Agent 时代的攻击面不是一个新端口或一个新 prompt，而是一组可组合工具、配置、身份、资源和协议。只有把它们连起来看，很多风险才会显形。
它不适合随便在无授权环境里运行，也不应该被当成万能扫描器。但如果你正在搭内部 MCP、模型网关、agent client 配置和本地 AI 工具链，AgentHound 提供了一个很现实的提醒：先把 agent 基础设施画成图，再讨论哪些路径应该存在。