MakerChecker开源：给AI Agent做危险能力体检

有人把AI Agent的"危险能力扫描"做成了开源工具

这两天Hacker News上冒出来一个叫 MakerChecker 的项目，做的事情很具体：扫描你的AI Agent，找出它可能执行的危险能力和高风险行为链。不是那种笼统的"Prompt注入检测"，而是把Agent能调的所有工具、能触达的所有资源摊在桌上，穷举组合，然后告诉你——喂，你这套配置下，Agent理论上能干出这些事。

听起来像是static analysis的思路挪到了Agent安全领域。但这个类比只对了一半。真正让它有意思的地方是，MakerChecker关注的不是单个工具调用的风险，而是行为链（capability chain）——多个看似无害的能力组合起来产生的破坏力。

为什么单点扫描没用了

2025年下半年到2026年上半年这半年多，Agent安全这块已经彻底炸开锅。腾讯朱雀实验室扫了ClawHub上5万多个Skill包，检出452个高危恶意样本。LiteLLM那次4.8亿下载量的供应链投毒事件还没过去多久。Agent Skills在2026年初已经把MCP的风头彻底盖过，变成了新的攻击入口。

问题是，传统扫描思路在Agent这里都不太work。原因很简单：

• 单个工具都是"合法"的。读文件合法，发HTTP请求合法，写文件也合法。但"读SSH密钥→POST到外部服务器→清空bash_history"这三步串起来就是数据窃取。
• 权限边界模糊。Agent的工具调用往往共享一个执行上下文，没有像操作系统那样的能力隔离（capability-based security）。
• LLM本身是个非确定性的决策者。同一套工具，不同prompt下会走出完全不同的执行路径。

MakerChecker干的事情，本质上就是把Agent当成一张能力图（capability graph），节点是工具和资源，边是调用关系。然后它做图遍历，找出所有能到达"敏感汇点（sensitive sink）"的路径。汇点包括外网、支付接口、生产数据库、用户凭证这些。

这跟传统的污点分析（taint analysis）思路很像，但对象换成了Agent的工具集。

它到底怎么用

从README看，用法相当直接。你把Agent的工具定义（比如OpenAI function calling schema、或者MCP server manifest）喂给MakerChecker，它输出一份扫描报告：

• 高危能力清单：哪些工具本身就是危险的，比如exec_shell、http_post、file_write_arbitrary_path。
• 危险行为链：具体的攻击路径推演，标注每一步用了哪个工具。
• 风险等级评分：按CVSS风格给出严重度，方便集成到CI里。
• 缓解建议：能不能拆掉某些工具、加上人工审批、或者做参数白名单。

项目名字里的Maker-Checker本身就是金融行业风控的老概念——一个人发起（Maker），另一个人复核（Checker）。作者显然是想把这套思路直接照搬到Agent架构里：任何高风险行为链，都强制走人工或独立Agent复核，而不是让主Agent一路狂奔。

跟同类项目比一下

这块赛道其实已经不冷清了：

• 腾讯朱雀的A.I.G（AI-Infra-Guard）：更偏基础设施层，主打大模型服务、MCP Server、Skill市场的批量扫描。数据集大、覆盖广，但对具体某个Agent的定制化分析没那么细。
• Strix（usestrix/strix）：走的是"AI黑客"路线，用多Agent协作真实攻击目标验证漏洞，产出真PoC。这是主动渗透，跟MakerChecker的静态分析定位完全不同。
• Cursor Security Review：Cursor刚推的功能，在PR层面用AI Agent做代码审查。关心的是代码本身的漏洞，不是Agent配置的能力风险。

所以MakerChecker填的是一个具体的缝隙：在Agent部署前，对它的能力配置做静态审计。这个位置以前基本是空的，大家要么在扫模型、要么在扫代码、要么在做运行时防护，很少有人系统性地看Agent的"能力DNA"。

一个能落地的场景

举个开发者更容易共情的例子。假设你在做一个客服Agent，接了以下工具：

• get_user_info(user_id)：查用户资料
• send_email(to, subject, body)：发邮件
• fetch_url(url)：抓外部页面（用于验证退款链接之类）

单看每个都很正常。但MakerChecker会告诉你：

高风险链 #1：get_user_info → send_email。攻击者可以通过prompt注入，让Agent把任意用户资料发到攻击者邮箱。风险等级：高。

高风险链 #2：fetch_url → SSRF潜在路径。fetch_url未限制内网地址，可能被诱导访问169.254.169.254拿到云上元数据凭证。风险等级：严重。

这种东西人肉review是能发现的，但当你的Agent接了20个工具、300个MCP endpoint的时候，组合爆炸就上来了。工具化扫描的价值就在这。

判断：值得关注，但别期待银弹

直说观点：MakerChecker的思路对，工程实现还早期，但方向本身是Agent安全里少数几个"必然会有人做出来"的品类。

它的长处在于把一个模糊的问题（"我的Agent安全吗？"）变成了一个可枚举、可报告的问题（"这些工具组合出来的危险链有几条？"）。这对于合规、审计、SDLC集成都是巨大的价值。

它的短板也很明显：

1. 静态分析看不到运行时。LLM实际会不会走某条路径，最终还是看模型行为。这就跟传统SAST一样，误报率是绕不开的问题。
2. 对MCP/Skill生态的覆盖度。目前项目还比较年轻，能不能跟上MCP、Agent Skills、A2A协议这些快速演化的规范，是个持续投入的问题。
3. 和运行时防护的配合。理想架构应该是"静态扫描（MakerChecker） + 运行时策略引擎（类似OPA） + 人工复核（真正的Maker-Checker流程）"。单靠一层是不够的。

对开发者的建议是：如果你在做严肃的Agent产品，尤其是接了外部工具、能碰到用户数据或者生产资源的那种，可以拿MakerChecker先跑一遍你的工具schema，至少心里有个底。别等到有人拿你的Agent当跳板攻击客户，再去补锅。

顺带一提

Agent安全这块的开源力量今年明显在加速。从朱雀的A.I.G、到Strix的AI渗透、到现在MakerChecker的能力扫描，几个不同角度的开源工具已经能拼出一个初步的Agent DevSecOps工具链了。加上Cursor这类IDE厂商也在做PR层面的安全Agent，整个安全左移的动作在Agent时代反而比传统软件时代来得更快。

多模型调度层面，OpenAI Hub（openai-hub.com）也在做类似的"聚合+可控"的事——一个Key调GPT、Claude、Gemini、DeepSeek这些主流模型，兼容OpenAI格式、国内直连，对做Agent的团队来说，模型侧的接入复杂度确实能省不少。安全和聚合，本质上都是在给Agent工程化补基础设施的坑。

参考来源

• MakerChecker GitHub 仓库：本文主角，AI Agent危险能力扫描开源项目
• Strix - 开源AI黑客框架：多Agent协作的自动化渗透测试工具，与MakerChecker互补
• 2025开源供应链投毒分析技术报告：包含Skill包高危样本扫描数据，可作为MakerChecker应用背景参考
• 腾讯AI-Infra-Guard：朱雀实验室开源的AI红队测试平台，Agent基础设施安全的另一条路径