用 Agent 审 Agent：腾讯 AI-Infra-Guard 源码走读

给 agent 装第三方技能包的人，大多是凭着一份 README 和一个 star 数按下的回车。这件事到底有多危险，过去只有直觉，没有数字。

现在有了。腾讯朱雀实验室在 Tencent/AI-Infra-Guard 仓库里公开了一份对 DeepSeek Harness 的授权注入评测，14,560 次真实运行：当 agent 通过 load_skill 读入内容时，间接提示注入的完全成功率是 15.2%；同一批攻击换成 read_document 读文档，只有 3.9%。装一个技能的风险，是读一份文档的 3.9 倍。

这份数据来自 A.I.G 自己的 Research/ 目录，而不是它的营销页。这也是我认为这个项目值得读源码、而不是只看 README 的原因。

一个仓库里的五把刀

A.I.G（AI-Infra-Guard）是腾讯朱雀实验室（成立于 2019 年，隶属腾讯安全平台部）开源的 AI 红队平台。截至 2026 年 8 月 23 日，GitHub 上 5,477 star、518 fork、26 个 open issue，最新版本 v4.5.2 发布于 2026-08-17，Apache-2.0 许可。仓库 main 分支共 6,397 个文件，语言构成是 Python 3.51 MB / TypeScript 1.13 MB / Go 777 KB。

这个语言比例本身就说明了架构：Go 写编排，Python 写扫描引擎，Vue/TS 写界面。aig-server（Web UI 挂在 8088）通过 WebSocket 把任务分发给 aig-agent 执行器，v4.1.14 起加了轮询式的负载均衡。

真正要理解的是图最下面那条线：A.I.G 的规则有两种形态，一种是 YAML，一种是 Markdown 提示词。前者可复现、可 diff、CI 里有 cmd/yamlcheck 把关；后者由 LLM 执行，同一份输入不保证同一个结论。五个扫描面里只有一个属于前者。这条分界线决定了你可以把哪部分结果写进合规报告，哪部分只能当线索。

第一层：唯一不需要 LLM 的那部分

AI Infra Scan 是最传统、也最扎实的一层：先用指纹识别目标跑的是什么组件和什么版本，再拿版本去比对漏洞库。

指纹是 148 个文件里的 146 份 YAML，语法是熟悉的 nuclei 味道：

info:
  name: ollama
  author: 腾讯朱雀实验室
  severity: info
http:
  - method: GET
    path: '/'
    matchers:
      - body="Ollama is running"
version:
  - method: GET
    path: '/api/version'
    extractor:
      part: body
      group: 1
      regex: '{"version":"(\d+\.\d+\.?\d+?)"}'

漏洞规则更简单，一条 CVE 一个文件，核心就是一行版本区间表达式：

info:
  name: ollama
  cve: CVE-2024-37032
  summary: Ollama未验证摘要格式（64位十六进制sha256）
  severity: MEDIUM
  security_advise: 升级Ollama至0.1.34版本或更高以解决此问题。
rule: version < "0.1.34"

我数了一下 data/vuln/：2,014 个 YAML 文件，分布在 116 个目录（data/vuln_en/ 是等量的英文镜像，所以 README 的 "2000+ CVE rules" 成立，但不要把两份加起来）。README 在 v4.5.0 时点写的是"130 组件 1,888 条"，组件口径比我按目录数的算法宽——差异来自那些只有指纹、没有独立漏洞目录的组件（data/fingerprints/ 有 146 份）。这里有个值得说的分布——

组件	规则数	占比
openclaw	657	32.6%
praisonai	112	5.6%
langflow	111	5.5%
flowise	97	4.8%
openwebui	87	4.3%
mlflow	79	3.9%
vllm	72	3.6%
其余 109 个组件	799	39.7%

三分之一的漏洞规则押在 OpenClaw 一个生态上。这不是问题，是选择——它反映的是朱雀实验室真实的投入方向（v4.1.15 的 changelog 里有一条就是"openclaw vuln count 628 -> 655"）。但如果你的技术栈里没有 OpenClaw，A.I.G 的漏洞库对你的实际覆盖率要按剩下那 1,357 条算。

另一个细节：组件名同时存在 openwebui（87 条）和 open-webui（44 条）两个目录。v4.5.0 的 changelog 里刚修过一次同类问题（"Remove duplicate fingerprint open-webui.yaml"、"Correct info.name to match fingerprint names (case-sensitive)"）。规则库到了两千条这个量级，命名一致性本身就成了工程问题。

第二层：正则做证据，LLM 做判决

skill-scan 是这个项目里我认为最有想法的一块。它已经拆成独立 PyPI 包 aig-skill-scan，可以脱离平台单跑：

pip install aig-skill-scan
export LLM_API_KEY="your-api-key"
aig-skill-scan --repo /path/to/skill -m deepseek-v4-flash -o result.sarif.json

关键在于它不是一个静态扫描器。

utils/pre_scan.py 里确实有 13 条高危正则——curl|sh 管道执行、169.254.169.254 云元数据端点、~/.ssh 凭据路径、ignore previous instructions 系列注入话术、base64.b64decode 后接 exec、crontab 持久化、从 pastebin 下载可执行文件……但这些正则的输出不是结论，是一段提示文本：

⚠️ 静态预扫描发现以下需要特别注意的模式，请重点审计这些行为是否必要、有何风险……

这段文本被注入给一个真正的 agent，它手里有 7 个工具：ls、dir、grep、read_file、base64_decode、thinking、finish，用 XML 格式调用，每轮只允许调一个，上下文满了走 compact.md 压缩。审计员自己决定读哪些文件、读几遍、什么时候收工，最后调 finish 输出 Markdown 报告，按 SkillTrustBench 的 T01–T09 打标签，转成 SARIF 2.1.0 交给 GitHub Code Scanning。

这个架构的取舍很清楚：正则负责"哪里可疑"，模型负责"这算不算问题"。因为技能包的攻击面根本不在语法层——一个 Skill 可以只有一份 SKILL.md、零行代码，而它的安装指令就等于代码行为。prompt/agents/code_audit.md 里对这一点写得很直白：

SKILL.md 中的安装指令、初始化命令、使用前置步骤，等同于代码行为，必须按照与代码相同的标准进行安全审计

判定分三档：malicious（明确攻击意图）/ suspicious（有漏洞但无明确意图）/ normal。有意思的是 malicious 的第 9 条触发条件——"同时存在 3 项以上 suspicious 信号，综合判定为 malicious"。这是把"单点无害、组合致命"写进了规则，也是纯静态工具永远做不到的判断。

那一处只有读源码才能看见的设计

utils/text_decoder.py 里有个叫 _recover_utf16_mojibake 的函数，它处理的攻击模式我此前没在任何同类工具里见过：

攻击者把指令按 UTF-16 编码写进文件。人打开是乱码，模型读到的也是乱码，静态扫描器一无所获——但运行时换一个解码路径，指令就复活了。A.I.G 的应对是把已经解出来的字符串再 encode('utf-16-le') 回去、用 UTF-8 重解一次，判据是两条：ASCII 可读率提升 ≥ 0.25，或原文里出现 Cf/Co 类（格式控制符/私有区）字符。恢复成功就报一条 reversible_mojibake，并且把恢复出的正文也送去过那 13 条正则——也就是说藏在乱码里的 curl|sh 一样会被抓。

pytests/test_charset_smuggling.py 专门守着这条路径。这是那种"必须真的被这个手法打过一次才写得出来"的代码。

而 v4.5.2 宣称的另一半，我在开源代码里没找到

README 的 v4.5.2 条目写着："Skill-Scan: .pyc bytecode bypass detection + charset smuggling defense"。后半句成立，上一节就是。前半句我做了一次全仓库检索——把 skill-scan、mcp-scan、agent-scan 三个包完整拉下来（main HEAD 4908db1，2026-08-21，晚于 v4.5.2 的发布日 08-17），grep -rniE '\.pyc|bytecode|marshal|dis\.dis|decompile' 的全部命中如下：

skill-scan/skill_scan/utils/pre_scan.py:91:   _SKIP_EXTS      = {'.pyc', '.pyo', '.pyd', ...}
skill-scan/skill_scan/tools/dir/dir_actions.py:8: _IGNORED_EXTS  = {'.pyc', '.pyo', '.pyd'}
skill-scan/skill_scan/agent/agent.py:43:     _TREE_SKIP_EXTS = {".pyc", ".pyo", ".pyd"}
mcp-scan/mcp_scan/utils/pre_scan.py:111:     _SKIP_EXTS      = {'.pyc', '.pyo', '.pyd', ...}
agent-scan/agent_scan/utils/file_utils.py:38: '.wasm', '.pyc', '.pyo',

五处命中，五处都是忽略列表。 没有任何一处读取、反汇编或检查字节码。而且第三处比前两处更要命：_TREE_SKIP_EXTS 作用在展示给 agent 的项目目录树上——.pyc 不只是不被分析，它压根不会出现在审计员看到的文件清单里。审计员甚至不知道有这个文件。

公平地说，这个能力有可能落在没有开源的那部分（平台后端、或者 matrix.tencent.com 上的托管服务）。但对照 charset smuggling 那一条——代码在、测试在、判据在——同一条 release note 里两个能力的可验证程度差了一个量级。写 changelog 的人应该和写扫描器的人对一次账。

也有一处说不通的

prompt/system_prompt.md 是通用编码 Agent 的系统提示词，几乎是逐段的复用——"你的名字是 <{name}>"、"回答不超过 4 行"、"不要在回答中添加不必要的前言或后记"、"为实现目标进行最少的更改"、"处理完一个文件后，直接停止，不要解释你做了什么"。

对一个写代码的 agent，这些约束都对。对一个安全审计员，它们和下游的 code_audit.md 正面冲突——后者要求"报告需包含：每个确认漏洞的具体位置（文件路径+行号）、代码片段、技术分析、影响评估、修复建议、攻击路径"。上游说别废话、下游要长报告，中间靠 instruction 覆盖。这在 F1 0.98 的基准分上大概看不出来，但它是那种会在长尾样本里悄悄扣分的设计债。

第三层：检测规则本身就是 Skill

agent-scan 是整个项目里最"元"的一块。它的 14 条检测规则，每一条都是一份 SKILL.md：

prompt/skills/
├── agentic-supply-chain-detection/SKILL.md
├── authorization-bypass-detection/SKILL.md
├── cascading-failure-detection/SKILL.md
├── data-leakage-detection/SKILL.md
├── direct-injection-detection/SKILL.md
├── file-path-traversal-detection/SKILL.md
├── hardcoded-secret-detection/SKILL.md
├── human-agent-trust-exploit-detection/SKILL.md
├── indirect-injection-detection/SKILL.md
├── inter-agent-comm-security-detection/SKILL.md
├── memory-poisoning-detection/SKILL.md
├── owasp-asi/SKILL.md
├── tool-abuse-detection/SKILL.md
└── unexpected-code-execution-detection/SKILL.md

用被审计的格式来写审计规则，这不是巧合，是同一个判断的两面：既然 Skill 格式足以承载攻击行为，它当然也足以承载检测行为。这和我在 Google 下场做 Agent Skills 里的观察是同一件事的两个侧面——一个格式赢得事实标准之后，攻防双方会同时搬进来。

新增一条检测能力的成本因此变成了写一份 Markdown（v4.5.0 一次性加了 4 条，v4.5.1 又加了 5 条）。代价也一样直白：这些规则的召回率完全取决于执行它的模型，且没有任何静态校验能告诉你新加的规则是不是和旧的重叠了。

第四层：MCP 红队，和它没打的那一枪

mcp-scan 和 skill-scan 共用同一套 agent 骨架，但工具箱多了两把：execute（执行命令）和 mcp_tool（真的去调目标 MCP Server 的工具）。这是动态验证的基础。

它下面还挂了一个 redteam/ 子模块，三个 LLM 角色协作：

角色	职责
Attacker Agent	按攻击目标和对话历史生成下一轮攻击消息，输出 thought / message / attack_technique / reflection
Target Runner	与目标交互
Evaluator Agent	判定 on_topic、打分 1–10、判 is_successful

策略有两种：Crescendo（建立信任 → 试探边界 → 逐步升级 → 发起攻击，四阶段渐进）和 TAP（Tree of Attacks with Pruning，每轮分支出多个变体，先按 on_topic 过滤再按分数留 top-k）。预定义攻击目标 6 个，对齐 OWASP Agentic Top 10：data_exfiltration、indirect_prompt_injection、ssrf_via_agent、rce_via_tool、privilege_escalation、tool_poisoning。

看上去很完整。然后你打开它自己的 README：

Target Runner：当前为源码分析模式——复用 mcp-scan 的代码读取能力收集仓库上下文，由 LLM 模拟 MCP Server 对攻击的响应，不实际启动 MCP 进程。

也就是说，攻击者是 LLM，靶子也是 LLM，评委还是 LLM。整条链路没有一个真实的 MCP 进程参与。这条红队线目前证明的不是"这个 MCP Server 能不能被攻破"，而是"一个模型在读了这份源码之后，认为它会不会被攻破"。

我要给他们记一笔的是：这句话是写在自己 README 的架构说明里的，加粗的。安全工具最容易犯的错就是把模拟结果包装成实测结果，A.I.G 在这里选择了诚实。但用它出报告的人必须知道这个边界——尤其是 mcp_tool 工具在主扫描路径里是存在的，红队路径里反而没接上，很容易误以为跑的是同一套。

第五层：越狱评测是一次 vendored

AIG-PromptSecurity/ 有 505 个文件，目录名叫 deepteam。这是 confident-ai 的开源红队框架 deepteam 的 vendored 版本——changelog 里有一条 "Update DeepTeam repo URL to confident-ai/deepteam" 可以佐证，整个 AIG-PromptSecurity/ 单独带了一份 Apache-2.0 LICENSE。

在此之上他们扩了攻击算子。目前 29 种单轮 + 10 种多轮：

• 单轮：code_chameleon、context_poisoning、deep_inception、encoding（含 a1z26、affine 等多种编码变体）、flip_attack、ica、jam、math_problem、multilingual、past_tense、prefill、promisqroute、stego、super_user、system_override 等
• 多轮：actor_attack、bad_likert_judge、best_of_n、crescendo_jailbreaking、goat_jailbreaking、linear_jailbreaking、many_shot_jailbreaking、pair_jailbreaking、sequential_break、tree_jailbreaking

漏洞维度 16 类（bias、excessive_agency、pii_leakage、prompt_leakage、unauthorized_access、robustness 等），数据集用 AdvBench、CNSafe、SafeBench。

这一层的价值是工程整合而非原创，标注清楚就没问题——而他们标清楚了。

比工具更值钱的，是那 14,560 次运行

Research/ 目录里有两份原创研究，其中 deepseek-harness-security-assessment 是我读到现在最有价值的部分。

实验设计：1,120 个基础用例（16 个载体通道 × text/file 两种投递模式 × 35 个攻击目标），每个用例配 naive 基线加 12 种攻击手法，共 14,560 次 agent 运行，目标是真实的 DeepSeek Harness 运行时（模型 deepseek-v4-flash），source tool 受控、sink 是被追踪的模拟工具——不真发邮件、不真执行 shell、不真转账。评判用两套：J_R 是确定性规则评判器（查污点投递、sink 调用、参数匹配、canary、拒答），J_L 是离线的语义 LLM 评判器。

总体结果并不吓人：J_R 完全成功 5.6%、部分服从 2.0%；J_L 完全成功 5.3%、部分服从 7.3%。真正有信息量的是切片。

第一条：技能是最危险的输入通道。

内容读取工具	运行数	J_R 完全成功	J_L 完全成功
load_skill	910	15.2%	13.7%
fetch_url	2,730	8.6%	6.8%
read_channel	910	5.4%	5.4%
read_email	2,730	4.1%	3.3%
search_knowledge	910	4.1%	4.5%
read_document	6,370	3.9%	4.4%

装技能的成功率比读文档高 3.9 倍，甚至明显高于"从互联网抓一个 URL"。原因不难理解：技能是被当作指令加载的，而文档是被当作数据读取的。模型对前者的默认信任级别本来就更高——攻击者不需要突破什么，他只需要被安装。

第二条：换个投递形态，就是换了个世界。

unicode_hidden 通道（不可见字符藏指令）在 text 模式下 J_R 完全成功率是 0.0%，在 file 模式下是 25.5%——全表最高。他们在 README 里专门解释了为什么这不是"把文本文件改个扩展名"：file 模式会真的生成或修改原生格式的载体文件（改真实 PDF 的元数据、改 XLSX 的单元格、生成 .ics 日历文件、构造真实 HTML），再走各自的解析/抽取路径拿到模型可见的内容。表示层的行为，纯文本近似是测不出来的。

这条和我自己在提示词围栏上的实测对得上：同形字、全角字符这类"看起来像绕过"的手法，在三个模型上是 0/12 全灭；真正能穿透的只有不可见字符那一类。A.I.G 这份数据补上了我没做的那一半——不可见字符的杀伤力全部集中在文件解析路径上，在纯文本投递里它约等于零。这直接改写了防御的落点：清洗要放在文件抽取之后，而不是只在用户输入框那道关。

第三条：fake_completion 是最好用的单一手法。 伪造"任务已完成"的状态框架，text 模式下 J_L 完全成功 17.0%，对照 naive 基线 5.7%。其次是 obfuscation（13.6%）和 escape（9.3%）。这类攻击不去说服模型违规，而是让模型以为当前回合的约束已经结束了——和我在 Agent 上下文注入的扫描方向 里追的那类"历史被改写导致模型答非所问"的 bug，机理上是同一族：污染的不是内容，是模型对自己处境的判断。

顺带一提，被测的 DeepSeek Harness 正是我上周拆过的那批大厂开源 harness 之一。开源 harness 的好处在这里显现得很具体：它让第三方实验室能拿真实运行时做 14,560 次授权测试，然后把结果连同数据集一起公开。这件事在闭源 harness 上不可能发生。

Research/ 下另一份是 SkillJack（自演化 agent 中的持久化技能后门），数据集是 65 条伪装型投毒轨迹（20 条数据外传 + 15 条提权 + 15 条越权转账 + 15 条后门）、65 条直接恶意轨迹一比一配对、20 条干净轨迹。研究的是攻击者把恶意轨迹喂进 agent 的技能提取流水线之后，后门能不能被固化成一条常驻技能、并在后续会话里被路由到。方向比结论更值得注意——技能的攻击面正在从"你装了什么"扩大到"你的 agent 自己学会了什么"。

和 skill-vetter 比：这次不是安全幻觉

2026 年 5 月我评过第一款 AI 技能安全扫描器 skill-vetter，结论是"安全幻觉"：它靠 grep 正则、过不了自己的检查、还给自己加了豁免规则。放在同一张表上对比，差距不在功能条数上：

维度	skill-vetter（2026-05）	A.I.G skill-scan（2026-08）
判定机制	grep 正则直接出结论	正则出线索，LLM agent 出结论
能否读懂无代码的 Skill	否	是（SKILL.md 指令即行为）
混淆对抗	无	base64 工具 + 可逆乱码恢复 + 非 UTF-8 告警
风险分类	自定义	SkillTrustBench T01–T09
输出格式	自定义	SARIF 2.1.0（GitHub Code Scanning 直读）
基准	无	SkillTrustBench，Claude Opus 4.6 F1 0.9848
结论可复现性	高（正则是确定的）	低（换模型换温度就换结论）

最后一行是双向的：skill-vetter 的确定性一文不值，因为它的规则本身就抓不到东西；A.I.G 的不确定性是真代价，因为它的规则真的抓得到。

SkillTrustBench 榜单值得单看一眼：

#	模型	F1	Precision	Recall	FPR
1	Claude Opus 4.6	0.9848	0.9725	0.9974	0.0663
2	GLM 5.1	0.9836	0.9701	0.9974	0.0723
3	Gemini 3.5 Flash	0.9792	0.9947	0.9641	0.0120
4	Kimi 2.6	0.9780	0.9895	0.9667	0.0241
5	DeepSeek v4 Flash	0.9740	0.9868	0.9615	0.0301

五个模型的 F1 挤在 1.1% 的区间里，但 FPR 从 0.0120 到 0.0723 差了六倍。换模型几乎不改变它"能不能找到"，改变的是它"会不会冤枉人"——而后者才决定这东西能不能进 CI 卡门禁。顺带一提，CLI 的默认模型 deepseek-v4-flash 是这张表的第五名：F1 最低，但 FPR 0.0301 只有榜首的一半不到。这个默认值选得比看上去合理。

八维评分

维度	评分	理由
漏洞库工程质量	8/10	2,014 条规则、语法干净、CI 有 yamlcheck；扣分在组件命名不一致和 32.6% 集中于 OpenClaw
Skill 审计机制	9/10	正则做证据 + agent 做判决的分层是对的；可逆乱码恢复是同类工具里的独一份
MCP 审计机制	6/10	静态审计扎实，但红队路径打的是 LLM 模拟靶；mcp_tool 没接进红队编排
Agent 扫描	7/10	检测规则即 Skill，扩展成本极低；但规则质量无静态校验，重叠无法检出
越狱评测	7/10	39 种攻击算子整合到位，署名清楚；原创度有限
研究诚实度	9/10	模拟就写模拟、数据连 CSV 一起公开、明确声明"不是通用漏洞率"
文档与代码的一致性	5/10	".pyc bytecode bypass detection" 在开源代码里五处命中全是忽略列表；组件计数口径在多语言 README 间反复返工
可落地性	8/10	pip install 单跑 + SARIF 直进 GitHub Code Scanning；需要自备 LLM key 和预算

总评 7.4/10。 拉高分的是第二层和 Research/，拉低分的是第四层那个没启动的进程，和一条查无实据的 release note。

值得注意的是，这两项扣分是同一个问题的两面：Research/ 里的自我披露有多克制（"这些数值描述的是本次发布的受控配置，不是所有 DeepSeek Harness 部署的通用漏洞率"），README 的 What's New 就有多松。研究团队和市场文案之间那道缝，在这个仓库里是肉眼可见的。

结论：该装，但别把它当判决书

三条具体建议：

1. 把 aig-skill-scan 挂进 CI，但只用它挡 malicious。 SARIF 2.1.0 意味着零成本接 GitHub Code Scanning。用 malicious 判定卡合并，suspicious 只留标注不阻断。模型就用默认的 deepseek-v4-flash（FPR 0.0301）或者 Gemini 3.5 Flash（0.0120）——榜首 Claude Opus 4.6 的 F1 只高 1.1%，FPR 却是 0.0663，用它卡门禁会持续误伤。同时在流水线里单独加一条 .pyc/.pyo/.pyd 存在性检查：这三类扩展名不会进 A.I.G 给审计员看的目录树，你得自己看见它们。
2. AI Infra Scan 可以直接信，另外四层的结论要留原始报告。 前者是版本区间比对，可复现、可审计；后者是模型判断，报告里的"攻击路径"必须人工复核过才能写进工单。
3. 别用它的 MCP 红队结果做上线决策。 那条链路没有真实 MCP 进程参与。要做动态验证，用主扫描路径里的 mcp_tool，或者自己接一个真实 target 进 redteam/target.py——这个扩展点是开着的。

而如果这篇你只带走一件事，我希望是那 14,560 次运行里的第一行：load_skill 15.2%，read_document 3.9%。工具会迭代，规则会过期，但"技能是被当作指令加载的、而文档是被当作数据读取的"这个结构性差异不会变。你的 agent 每装一个技能，就是在给一个陌生人发一次指令权限——A.I.G 值不值得装是个人选择，先承认这一点不是。

参考资料

1. Tencent Zhuque Lab — Tencent/AI-Infra-Guard GitHub 仓库（数据截至 2026-08-23：5,477 star / 518 fork / 26 open issue）
2. Tencent/AI-Infra-Guard — v4.5.2 Release（2026-08-17）
3. Tencent/AI-Infra-Guard — CHANGELOG.md
4. Tencent/AI-Infra-Guard — skill-scan/README.md（SkillTrustBench T01–T09、SARIF 2.1.0、扣分制）
5. Tencent/AI-Infra-Guard — skill_scan/utils/text_decoder.py 与 pre_scan.py
6. Tencent/AI-Infra-Guard — mcp_scan/redteam/README.md（Crescendo / TAP，Target Runner 为源码分析模式）
7. Tencent/AI-Infra-Guard — Research/deepseek-harness-security-assessment（14,560 次运行的完整数据与聚合脚本）
8. Tencent/AI-Infra-Guard — Research/SkillJack（自演化 agent 的持久化技能后门）
9. confident-ai — deepteam（AIG-PromptSecurity 的上游框架）
10. DeepSeek — deepseek-harness（评测目标）
11. OASIS — SARIF 2.1.0 规范
12. 腾讯朱雀实验室 — SkillTrustBench 榜单（T01–T09 分类法与模型排名）
13. Tencent Zhuque Lab — "Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming"（arXiv:2606.31227）
14. Tencent Zhuque Lab — "MCP Unchained: Compromising The AI Agent Ecosystem Via Its Universal Connector"（Black Hat Europe 2025）
15. Zhaojiacheng Zhou — "Proteus: A Self-Evolving Red Team for Agent Skill Ecosystems"（arXiv:2605.11891，引用 A.I.G 的 19 篇论文之一）
16. Zenghao Duan et al. — "SkillAttack: Automated Red Teaming of Agent Skills through Attack Path Refinement"（arXiv:2604.04989）