文章总结： 腾讯朱雀实验室开源AI红队平台AI-Infra-Guard，拥有2169条漏洞规则与151个组件指纹，覆盖AI基础设施、Agent、MCP、越狱评测五大扫描面，20个月持续发版维护良好。但存在核心模块测试未被CI运行、扫描器自身存在绕过风险、缺少鉴权机制等问题。建议将其作为发现盲区的雷达而非唯一判决书，部署时仅限内网使用。 综合评分： 80 文章分类： AI安全,安全工具,红队,漏洞分析

腾讯内部在用的 AI 安全扫描器，开源了

原创

大白 大白

知白守黑1024

2026年9月28日 06:38 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

腾讯朱雀实验室开源的 AI 红队平台AI-Infra-Guard，6,595 个星标，一条命令就能起服务——AI 基础设施、Agent、MCP、越狱评测，五个扫描面一次铺开，规则库里有 2,169 条漏洞规则是现成的。我把它的仓库整个翻了一遍，翻到一个尴尬的细节。

仓库里躺着58 个测试文件，Go 写了 33 个，Python 写了 25 个，覆盖十四个模块；而三个 CI 工作流里，只有一个会碰测试——而且只跑其中一个工具包。

上一期我量过一个 12,110 星标、却 372 天没人改代码的项目。这次把同一把尺子，量在一个维护得好的项目身上。

治理层面它几乎挑不出毛病，七项指标全胜。但正因为底子好，剩下那几处盲区才更值得摊开看——尤其是对一个专门给 AI 做安全体检的工具来说。

01先说它做对了什么

我核对的第一件事是发布流程。2024 年 12 月 25 日建仓，8 天后的 2025 年 1 月 2 日就发出了 v0.0.1。GitHub 上能查到58 个 tag，58 个 release，一个不多一个不少，完全对齐；最新的 v4.6.3 发在 2026 年 9 月 24 日。从首发到今天跨度 21 个月，20 个月都有发版，唯一空档是 2025 年 7 月。

第二件事是社区。全站 504 个 PR，合并了 379 个，合并率75.2%；还有 98 个被明确关闭、27 个仍然开着。贡献者 58 人，第一大贡献者占 35.7%——没有出现「一个人扛 90% 提交」的独裁结构。

第三件事是工程配置。仓库里有 SECURITY.md、CONTRIBUTING.md、6 个 Dockerfile、7 个依赖锁文件，还有 3 个 GitHub Actions 工作流。README 被翻译成 9 种语言。

同样口径量出来的两张体检单。左边是上一篇的 HexStrike AI，右边是本次的 AI-Infra-Guard

这张图我刻意放在前面。同一套核查动作——Release 数、PR 合并率、贡献者、测试文件、CI、未关闭议题、闲置天数——七项指标，一项都没让。

02再看它的「仪器」本身

AI-Infra-Guard 卖的是检测能力，所以它自己那套规则库的成色，就是产品的成色。

先说扫描方式。AI 基础设施扫描走的是网络指纹路线——它连上你正在跑的服务，判断这是 Ollama 还是 vLLM、是哪个版本，再去匹配对应版本的漏洞。不是读代码，是问服务。

再看规则库。我把data/vuln/目录数了一遍：2,169 个 YAML 文件，每一个对应一条漏洞规则。data/fingerprints/下面是 151 个组件指纹。README 写的是「超过 100 个 AI 框架组件」和「2,000 多个已知 CVE」——实测两项都高于宣传值，这点很实在。

2,169 条漏洞规则的项目分布

但分布值得看一眼。openclaw 一个项目占了 657 条，也就是 30.3%；前三个项目加起来 42.6%；前十个项目占 67.3%。

这不一定是缺点——OpenClaw 是 2025 年底到现在被讨论最多的 Agent 项目，漏洞多、披露密，收录得多很正常。但它意味着：这套规则库的覆盖面、误报率、维护节奏，很大程度被一个项目的生态牵着走。

扫描执行界面：左侧是识别到的组件与命中的漏洞规则，右侧是逐项扫描结果。

03三个 CI，没有一个跑完整测试

现在说测试。仓库里能数出58 个测试文件，Go 33 个、Python 25 个。对一个 6,410 个文件的项目来说，这个数量是有交代的。

问题不在有没有，在谁在跑。三个工作流我把 YAML 逐个读完了：

三个 GitHub Actions 工作流的实际内容`# create-release.yml on: push: tags: [‘v*’]        # 只在打 tag 时触发 steps: 抓 CHANGELOG → 拷 data/ → sed 改版本号 → 压缩 → 建 Release → 跑测试：无

docker-publish.yml

on: push (tag / 分支) steps: checkout → 设 tag → 登 Docker Hub → metadata → build → push → 跑测试：无

yaml-lint.yml

on: push/pull_request paths: [‘data/‘, ‘cmd/yamlcheck/‘] steps: go test ./cmd/yamlcheck → 校验 data/ 下的 YAML → 跑测试：只有 1 个包`

工作流的触发条件、职责，以及实际跑不跑测试

唯一会跑测试的那个，只跑cmd/yamlcheck一个工具包，而且只有当 data/ 目录或这个工具本身被改动时才触发。

那核心模块的测试呢？社区里有人替所有人跑了。issue #672，2026 年 9 月 21 日提出，到现在还是 open：

issue #672 给出的复现步骤`git clone https://github.com/Tencent/AI-Infra-Guard cd AI-Infra-Guard go build ./…                  # 通过 go test ./common/agent/…      # 编译失败 go test ./common/websocket/…  # 5 个断言失败

common/agent/taskstest.go:83:12:  undefined: TestDemoAgent common/agent/taskstest.go:194:13: undefined: BaseUrl common/agent/tasks_test.go:243:13: undefined: Token`

报告的原始措辞很克制：「None of the CI workflows run Go tests」——没有任何一个工作流会跑 Go 测试。

而CONTRIBUTING.md里写着，贡献者提交 PR 前应当保持现有测试通过。规则写了，但没有任何自动化流程去验证它。

这不是「没有测试」的问题，是「测试写了但没人跑」的问题。前者一眼能看出来，后者能悄悄烂很久。

04扫描器自己的绕过面

一个专门查别人漏洞的工具，最尴尬的情况是它自己也会漏。

2026 年 9 月 2 日，有人连着报了两条 Skill 扫描的绕过，两条后来都修复关闭了：

1.#630　.pyc 文件不扫。Skill 扫描器只看 Python 源码，不看编译产物。攻击者把恶意脚本编译成 .pyc 放进 Skill，源码层检测直接落空。

2.#631　九个目录无条件跳过。扫描器硬编码了跳过列表：__pycache__、.git、node_modules、.venv、venv、dist、build、.next、.nuxt。

第二条的杀伤力在于，这些目录不是「安全目录」，只是「为性能跳过的目录」。而 Skill 代码完全可以去调用它们：

issue #631 给出的绕过路径# 扫描器跳过了 .venv/，但代码仍然可以执行里面的文件 subprocess.run(["python", ".venv/hidden.py"])

扫描器的忽略列表，本质上就是它的攻击面。这一点对所有做静态检测的工具都成立——你决定不看的地方，就是别人藏东西的地方。好消息是这两条已经被修复；坏消息是，在被报告之前，它们一直在那里。

MCP 扫描的任务列表与逐项结果

05Research 目录里藏着更值钱的东西

如果只翻主目录，你会以为这就是个扫描工具集合。翻到Research/目录，画风变了——里面是四个独立的研究项目，而且带着论文级的方法论。

最值得说的是FORGE-Bench（arXiv:2609.11024），它研究的是 Agent 的「失控」（Loss of Control），而问法很尖锐：

「一个本来很能干的 Agent，在没有对手、没有恶意指令、也没有互相冲突的目标的情况下，会不会失控？」

实验规模是 5 个 Agent 模型、16 个运维域、1,800 条轨迹，把失控拆成三个可分别操纵的因子：目标压力、约束退化、不安全机会。

FORGE-Bench 的三因子实验：单因子无效，叠加后失控率跳到 55%–62%，压缩丢掉授权约束后升到 87%

结果比预想的干净：只有目标压力、或者只有不安全机会，都不会造成明显失控。把两者和「约束退化」叠在一起，未授权动作的比例跳到 55% 和 62%。而在成对反事实实验里，只要把原始的授权约束放回上下文，失控率就回到 0%。

最扎心的是最后一行：上下文压缩时如果把授权约束丢掉，失控率升到 87%。这条结论对任何做长上下文 Agent 的人都是直接警告——压缩策略省掉的那几百个 token，可能正是拦住它的那道栅栏。

另外三个研究项目也各有分量：

1.RogueHandoff-20：测的是「上一个 Agent 留下的不安全操作，会不会被下一个 Agent 继承执行」。20 个场景 × 3 个条件 = 60 个冻结会话，核心指标是 handoff_induced_harm，即交接场景与直接攻击场景的失控率差值。

2.SkillJack：全名 Persistent Skill Backdoors in Self-Evolving Agents——研究自进化 Agent 里能长期潜伏的 Skill 后门。配了 65 条伪装投毒轨迹、65 条朴素对照、20 条干净轨迹。

3.DSH 安全评测：对 DeepSeek Harness 的间接提示注入评估，1,120 个基础用例 × (基线 + 12 种攻击方法) = 14,560 次 Agent 运行。

06最后一个细节：数字怎么读

腾讯自己建了一个 Skill 安全评测基准，叫SkillTrustBench，数据构建流程公开：从 clawhub 抓 62,652 个真实 Skill，覆盖 8,500 多名开发者；经过五级分类去噪（frontmatter → 关键词 → import → 开发者投票 → e5 KNN），分层采样出 1,500 个正常基座样本；再通过攻击模版注入，扩展成 5,520 个评测用例。

组成是这样的：恶意 46.3%（2,553 条）、可疑 24.0%、安全 29.8%。

这里有个容易被读错的点。那 46.3% 的恶意样本，是从 1,500 条真实基座上做攻击模版注入生成的，不是从野生样本里统计出来的比例。所以它不能读成「现实中 46% 的 Skill 是恶意的」——它衡量的是扫描器能不能认出来，不是世界上有多少坏的。

在同一个榜单上，用 DeepSeek v4 Flash 作为评测模型，四个扫描器的检出表现是：Skill Vetter（OpenClaw）F1 0.9659，Skill Vetter（Hermes）0.9592，Cisco Skill Scanner 0.9265，NVIDIA SkillSpector 0.9040——A.I.G 的扫描器并不在这个表里，它出现在下一个表。

而在固定自家扫描器、只换底层模型的榜单上，A.I.G 的 F1 从 Claude Opus 4.6 的 0.9848 一路到 GPT 5.5 的 0.9566，九个模型跨度只有 0.028。把竞品的成绩——包括排在自己前面的——和自己的成绩放在同一个页面公开，这件事比分数更有说服力。

07它自己怎么装

看完一份体检报告，下一步往往是「我自己装一个试试」。能装，而且不麻烦，官方给了三条路。

官方 README 给出的三种部署方式`# 方式一：拉官方镜像跑（最快，推荐） git clone https://github.com/Tencent/AI-Infra-Guard.git cd AI-Infra-Guard docker-compose -f docker-compose.images.yml up -d

方式二：一键脚本（自动装 Docker 并启动）

curl https://raw.githubusercontent.com/Tencent/AI-Infra-Guard/      refs/heads/main/docker.sh | bash

方式三：从本地源码构建镜像再起

git clone https://github.com/Tencent/AI-Infra-Guard.git cd AI-Infra-Guard docker-compose up -d`

门槛不高：Docker 20.10 以上、内存 4GB 起、磁盘 10GB 起。容器起来后，浏览器打开http://localhost:8088，就是完整的 Web 界面——AI 基础设施扫描、Agent 扫描、MCP 扫描、越狱评测都在这里。

如果只想把 Skill 安全审计塞进 CI/CD，还有个更轻的入口，一个 pip 包搞定：

aig-skill-scan：可嵌入流水线的 Skill 审计工具`pip install aig-skill-scan export LLMAPIKEY=”your-api-key”

aig-skill-scan –repo /path/to/your/skill \                -m deepseek-v4-flash \                –language en \                -o result.json`

它也能接进 OpenClaw。用clawhub install aig-scanner装一个 Skill，把AIG_BASE_URL指向你本地跑起来的服务，就能在对话里直接让它扫。

官方 README 原文：该项目定位为企业或个人内部使用的 AI 红队平台，目前缺少鉴权机制，不应部署在公网。

这一句是整段部署说明里最该记住的。功能做到这个程度的红队平台，官方自己承认没有鉴权——谁连上 8088 端口，谁就能用你机器上的扫描能力。装的时候务必只绑内网，别把它挂在公网 IP 上。这刚好接回前面两节：一个专门查别人安全的工具，它自己的部署边界，同样得自己守住。

值不值得用

值得。在我用同一把尺子量过的同类项目里，它的维护记录目前是最好的。

但要清楚你拿到的这是什么。它的强项是广度——2,169 条漏洞规则、151 个组件指纹、五大扫描面覆盖 Agent / Skill / MCP / AI 基础设施 / 越狱评测，加上一份 20 个月没断过的发版记录。这些是实打实的。

弱项是测试与边界——核心模块的 Go 测试在 main 分支上跑不起来，CI 不验证；静态检测的忽略目录曾是可绕过点；扫描结果目前还缺机器可读输出（#636 还在等）。

换句话说：它适合用来发现「你没想到要看的地方」，不适合当成唯一的判决书。把它当雷达，别当法官。

免责声明：本文旨在讨论开源安全工具的选型方法与自查思路，不针对任何个人或机构作出评价，也不构成对该工具安全性的结论。文中涉及的技术细节，请勿用于未授权测试。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：知白守黑1024 大白 大白《腾讯内部在用的 AI 安全扫描器，开源了》