给 AI 系统做安全测试和传统安全测试不是一回事：除了"这个服务有没有 CVE"，还得回答"Agent 会不会被提示词注入劫持、MCP Server 会不会偷凭证、Skill 里有没有藏恶意代码"。这类问题纯规则扫不出来，纯靠 LLM 又贵又不稳定。腾讯朱雀实验室开源的 AI-Infra-Guard（A.I.G，Apache-2.0，5487 stars，今天还在 GitHub Trending 上）给的方案是双引擎架构：Go 写的规则引擎做确定性的指纹识别 + CVE 匹配，Python 写的 LLM agent 做需要推理的代码审计和越狱评估，两条腿走路。上周刚发 v4.5.2（2026-08-17）。本文拆它的架构演进、规则格式、三段式审计流水线，以及接入 CI 时实际会踩的坑。
架构演进：单二进制扫描器 → 多模块红队平台
| 版本 | 能力 | 技术栈 | 架构形态 |
|---|---|---|---|
| v0.1 | AI 基础设施漏洞扫描 + WebUI | Go 单二进制 | 单体扫描器，规则驱动 |
| v2.6 | 基础设施扫描 + MCP 代码分析 | Go 单二进制 | 双引擎，统一 WebUI |
| v3.6+ | Infra + MCP + Agent + 越狱评估 | Go + Python，Docker | 平台化，多模块可插拔 |
v3.6+ 的运行拓扑：
WebUI / CLI / REST API / WebSocket
└─▶ 任务调度器
├─▶ AI Infra 扫描（Go 规则引擎：指纹识别 → CVE 匹配）
├─▶ MCP/Skill 扫描（Python agent：静态规则 + LLM 验证）
├─▶ Agent 扫描（多 agent 流水线：注入/SSRF/泄露测试）
└─▶ 越狱评估（Python：攻击生成 → 目标 LLM → 判定器 → 安全分）四个关键设计决策值得抄：
- Rule-first, LLM-augmented：核心检测保持确定性（YAML 指纹 + 漏洞规则），快且结果可复现；LLM 只叠加在需要推理的场景（MCP 代码审计、Agent 行为模拟）。扫描器最怕"这次报、下次不报"，规则引擎兜底保证了基线稳定。
- 按关注点拆语言：Go 处理高并发网络探测和 Web 平台，Python 处理 LLM agent 循环和评估框架。不用一个语言硬扛所有场景。
- Data 即真相 ：所有检测规则放
data/目录做版本管理，不编译进二进制------目前 143 个指纹文件、116 个组件级漏洞规则、覆盖 2000+ CVE 条目，规则库可以脱离主程序单独更新。贡献新指纹 = 往data/fingerprints/加个 YAML 提 PR，不碰主程序。 - 引擎可插拔：每个扫描模块独立部署、独立版本，通过任务 API 连接。
规则引擎：指纹识别 + CVE 匹配
AI 基础设施扫描的输入是"运行中的服务地址"，不是 GitHub URL。vLLM 填 http://127.0.0.1:8000，Ollama 填 http://192.168.1.100:11434，ComfyUI 填 http://10.0.0.5:8188，支持 CIDR 和 IP 区间批量扫。流程：HTTP 探测 → 指纹匹配 → 版本提取 → 漏洞库匹配。
指纹规则是 nuclei 风格的 YAML，这是 data/fingerprints/ollama.yaml 原文：
info:
name: ollama
author: 腾讯朱雀实验室
severity: info
metadata:
product: ollama
vendor: ollama
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+?)"}'两个设计点：http.matchers 只负责确认"是这个组件"，版本提取单独走 version.extractor 的正则------指纹和版本解耦，CVE 匹配依赖精确版本号而不是 banner 关键词，减少误报。识别出组件版本后，漏洞匹配在 data/vuln/ 的规则里做，支持 Ollama、ComfyUI、vLLM、n8n、Triton 这些 AI 组件，不是通用 Web 漏洞库。
LLM 审计引擎：MCP/Skill 扫描的三段式流水线
MCP Server 和 Agent Skill 的扫描走另一条路：把源码（本地目录或 GitHub URL）交给 LLM agent，跑 Info Collection → Code Audit → Vulnerability Review 三段流水线。agent 通过 XML schema 注册工具（file/ls/grep/dir/base64_decode/thinking/finish）自主浏览代码、定位漏洞、输出结构化结果。CLI 用法：
# Skill 扫描（PyPI 安装，可直接进 CI）
pip install aig-skill-scan
export LLM_API_KEY="your-api-key"
aig-skill-scan --repo /path/to/skill -m deepseek-v4-flash --language en -o result.sarif.json
# MCP 扫描：静态源码 + 动态打运行中的服务
python main.py --repo ./mcp-server -m "anthropic/claude-sonnet-4.5" -o report.sarif.json
python main.py --server_url "http://localhost:8000/sse" --prompt "Test tool poisoning"CLI 默认单阶段模式（只跑 Code Audit），比三段快约 3 倍；输出 SARIF 2.1.0------GitHub Code Scanning、GitLab Security Dashboard、VS Code Problems 面板原生可消费，这是它进 CI 的关键设计。
MCP 风险分类是 MCP01--MCP10 + 3 个补充规则（Name Confusion 仿冒、Rug Pull 先信任后变脸、Tool Shadowing 同名工具覆盖），Skill 风险分类按 SkillTrustBench 的 T01--T09 五层：
| 层 | 风险 |
|---|---|
| A · 指令与记忆 | T01 Skill 指令劫持、T02 记忆投毒 |
| B · 代码执行 | T03 远程 payload 下载执行、T04 内嵌恶意代码 |
| C · 系统权限 | T05 提权与未授权访问、T06 系统持久化 |
| D · 工具链与依赖 | T07 工具劫持与仿冒、T08 不安全依赖 |
| E · Skill 代码质量 | T09 不安全编码实践 |
SkillTrustBench 基准上不同 LLM 做审计的 F1------审计质量是模型选型的函数，不是工具的：
| 模型 | F1 | Precision | Recall | FPR |
|---|---|---|---|---|
| Claude Opus 4.6 | 0.9848 | 0.9725 | 0.9974 | 0.0663 |
| GLM 5.1 | 0.9836 | 0.9701 | 0.9974 | 0.0723 |
| Gemini 3.5 Flash | 0.9792 | 0.9947 | 0.9641 | 0.0120 |
| Kimi 2.6 | 0.9780 | 0.9895 | 0.9667 | 0.0241 |
| DeepSeek v4 Flash | 0.9740 | 0.9868 | 0.9615 | 0.0301 |
Gemini 3.5 Flash 的 FPR 只有 0.012，适合当"先过滤再人工复核"的第一道闸；要低漏报（Recall 0.9974）就上 Opus 4.6。产出分三档判定：malicious（有明确攻击意图）/ suspicious（有漏洞但无攻击意图）/ normal。
Agent 动态黑盒扫描
Agent Scan 不打源码，打运行中的 Agent 平台（Dify、Coze、OpenAI 兼容接口、WebSocket 等），通过 provider YAML 描述被测目标：
targets:
- id: "http"
config:
url: "http://127.0.0.1:18081"
endpoint: "/chat"
method: "POST"
headers:
Content-Type: "application/json"
body:
message: "{{prompt}}"
transform_response: "reply" # 从响应里取 Agent 回复的 JSON key内置 10 个检测技能（默认跑 5 个核心：数据泄露、工具滥用、间接提示词注入、授权绕过、Web 外传），结果映射 OWASP ASI 分类。最大的坑是 transform_response：自定义 HTTP provider 不填它，所有响应被解析成 None，扫描结果为零------这是文档明确标注的必填项，Web UI 里对应"响应解析器"输入框。
实践记录与踩坑
- 无鉴权，别暴露公网。README 原话：平台定位企业/个人内网自检，当前没有认证机制。Docker compose 部署要求 4GB+ 内存、10GB+ 磁盘，Web 端口 8088。
- 恶意代码会藏。v4.5.2 新增 .pyc bytecode 绕过检测和 charset smuggling 防御------攻击者把恶意代码编译进 .pyc 躲过文本审计，或用编码混淆绕过规则匹配（pre_scan 阶段做编码异常检测）。扫第三方 Skill 时这两类要重点看。
- 扫描器自己也会被反打。v4.5.2 在 MCP 动态模式加了工具白名单防 RCE------LLM 驱动的扫描器去连恶意 MCP server 时，对方可能反过来诱导审计 agent 执行命令。给审计 agent 的执行能力设边界，这个设计值得抄进自己的 Agent 测试基建。
- 成本控制 ：三段式（含 Review 阶段）比单阶段贵且慢。CI 里用单阶段 + SARIF 输出卡门禁，平台交互式排查再跑三段。LLM 配置走环境变量（
LLM_API_KEY/LLM_MODEL/LLM_BASE_URL），配置优先级 CLI > 环境变量 > 默认值。 - 模型分工 ：mcp-scan 支持给不同任务配不同模型（
THINKING_MODEL=gemini-2.5-pro、CODING_MODEL=claude-sonnet-4.5），推理用强模型、生成用快模型，能压不少成本。 - 评分口径 ：安全分 =
max(0, 100 - Σ扣分)，Critical -100 / High -40 / Medium -25 / Low-Info -10。接门禁建议按"存在 Critical 即 fail"卡，别用总分------总分会被一堆 Low 刷低，失去拦截意义。
定位与进阶方向
平台化体检和动态红队框架不冲突，可以组合：CI 里 aig-skill-scan 出 SARIF 进 Code Scanning 卡合并，夜间任务跑 Agent Scan 全量，发布前用 RAMPART 这类 pytest 插件做 Agent 行为回归（断言"特定攻击下 Agent 是否表现出预期行为"）。A.I.G 的 API 也支持完整自动化（上传源码 → 创建任务 → 轮询状态 → 拉结果），适合接到自己的测试平台上。
进阶方向：SkillTrustBench 基准对齐（自建 Skill 审计器可以拿它当评测集）；指纹/CVE 规则库的自动化更新（项目已按 CVE/GHSA 源做半自动对齐）；越狱评估的多轮攻击方法（v4.5.1 已支持 Many-Shot、PAIR、GOAT、ActorAttack 四种）。AI 安全测试现在还是"规则 + LLM"双引擎的形态，等 Agent 工具调用边界标准化之后，大概率会往"行为契约测试"收敛------提前把资产体检和运行时断言两条链路都搭好，不亏。