企业官网建设流程全解析

• 文档
• 教程
• 知识库

导读

本文是 AI Red Teaming 路线图 中"测试平台（Testing Platforms）"节点的系统化解读。AI 红队人员的测试平台并非单一工具，而是一个由通用渗透测试发行版、专用 AI 红队框架与漏洞扫描器构成的分层工具箱：从 Kali Linux 这类传统渗透测试 OS，到 Microsoft PyRIT、Promptfoo 这类面向生成式 AI 的专门框架，再到被改造用于 AI 服务 API 测试的 OWASP ZAP。读完本文，你将掌握三类平台各自的定位、适用场景、协作方式与选型思路，能够基于评估目标（黑盒探测、提示注入、越狱、API 安全）搭建属于自己的 AI 红队评估环境。

测试平台在 AI 红队中的定位

在 AI 红队工作流中，平台的价值在于"提供执行评估所需的工具集"。与传统网络安全红队不同，AI 红队关注的是 AI 模型的独特攻击面：提示操控（prompt manipulation）、数据投毒（data poisoning）、模型窃取（model extraction）、规避技术（evasion），以及针对 LLM 的提示注入、越狱、有害内容生成、偏见与数据隐私问题（见 LLM Security Testing 与 Introduction）。

原文档将平台划分为三个层级，这是理解整个主题的骨架：

这三类平台并不互斥，一个成熟的 AI 红队评估往往要同时调用它们，以覆盖从"模型本身的对抗行为"到"承载模型的 API 与基础设施"的完整攻击面。

Kali Linux：传统渗透测试的底座

Kali Linux 是文档中提到的第一类平台——通用渗透测试 OS 发行版。它内置了大量渗透测试工具，覆盖侦察、漏洞利用、无线攻击、密码爆破等传统攻防环节。对 AI 红队而言，它的价值在于：

• 基础设施攻击面：AI 服务的托管服务器、容器、网络暴露面仍需传统手段验证；
• 侦察与信息收集：在评估 AI 应用的前置阶段，定位 API 端点、摸清部署拓扑；
• 横向能力衔接：当 AI 服务与 Web 应用、后端数据库耦合时，传统渗透技能是补齐链路的关键。

从 AI 红队路线图的结构看，Infrastructure Security 与 Unauthorized Access 等节点所关注的问题，正是 Kali 这类发行版擅长的领域。它不会直接生成对抗性提示词，但为"围绕模型的基础设施"提供了成熟工具链。

PyRIT：面向生成式 AI 的自动化风险识别框架

PyRIT（Python Risk Identification Tool for generative AI）是微软推出的生成式 AI 红队工具，也是原文档明确点名的专用框架代表。它的核心思路是将红队操作自动化：研究者用 Python 编写或组合攻击策略，框架负责与目标模型交互、批量投送攻击载荷并收集响应。

结合路线图中 Automated vs Manual Testing 的论述，PyRIT 正是"自动化提供规模"的典型代表：用于大规模扫描、提示词模糊测试（fuzzing）和基础对抗样本的批量生成。典型使用形态包括：

• 定义目标模型（本地模型或云端 API 端点）作为红队目标；
• 配置攻击数据集（越狱、注入、有害内容等类别）；
• 运行批处理，自动收集模型响应并交给评分器（scorer）判定是否命中漏洞。

从文档描述可以推断，PyRIT 的价值在于把"提示注入是否成功""是否生成有害内容"这类主观判断转化为可规模化、可复现的评估流程，适合需要持续回归的模型迭代场景。

Promptfoo：提示词安全评估与红队评测

Promptfoo 是另一类被文档点名的专用平台，定位偏向 LLM 应用的安全评估与红队测试。与 PyRIT 侧重"风险识别工具"不同，Promptfoo 更贴近开发者工作流：它提供声明式测试配置，可以定义测试用例、对抗性提示模板与预期断言，并支持对模型输出进行自动化判定。

在原路线图中，Promptfoo 还出现在 Black Box Testing 节点的资源列表里，其红队指南被作为"开源 LLM 红队指南"推荐——这印证了它在黑盒测试场景中的位置：评估者不了解模型内部结构，仅通过 API 输入输出交互来探测提示注入与安全绕过。典型工作流为：

1. 编写测试集：定义攻击向量（prompt injection、jailbreak 模板）与期望输出规则；
2. 指向被测模型：配置目标 LLM 的 API 接入；
3. 批量运行并生成报告：将探测结果整理为可阅读的评估报告，供修复与回归使用。

这类平台非常适合"红队评估结果要持续沉淀、与开发迭代挂钩"的工程化场景。

OWASP ZAP：从 Web 扫描器到 AI 服务 API 测试

OWASP ZAP（Zed Attack Proxy）本身是 Web 应用安全扫描器，但文档明确指出它被"改造用于 AI 服务的 API 测试"。这一改造的价值在于：AI 模型通常通过 API 暴露能力，而 API 层恰恰是 API Protection 节点强调的测试重点。

AI 红队使用 ZAP 的方式包括：

• 被动扫描：将 ZAP 配置为代理，观察 AI 应用前端的全部 HTTP/HTTPS 流量，自动标记可疑请求模式；
• 主动扫描：对 AI API 端点发起注入类探测，覆盖 OWASP API Top 10 中的风险项——包括失效的身份认证/授权、注入缺陷、安全配置错误、缺少速率限制等；
• 会话与请求操控：手工修改请求头、参数、载荷，验证 AI 服务的鉴权边界与滥用可能性。

从仓库证据看，这些关注点与 Authentication、Authorization 节点一脉相承：AI 模型本身再安全，若其 API 缺少鉴权或速率限制，攻击者依然可以绕过防护直接滥用模型能力。ZAP 在此扮演"API 层的体检仪"角色。

Azure AI Foundry 的 AI Red Teaming Agent

原文档还将 Azure AI Foundry 的 AI Red Teaming Agent（微软官方文档中的概念）列为学习资源。它代表了平台演进的另一个方向：将红队评估嵌入 AI 应用开发生命周期。这类平台形态通常具备以下特征：

• 提供内置的对抗性测试数据集与越狱策略库；
• 与模型部署、应用发布流程集成，支持持续评估而非一次性测试；
• 面向没有专职安全团队的应用开发者，降低红队入门门槛。

它与 Continuous Testing 节点强调的方向一致：安全评估不应止步于上线前的一次性渗透，而应伴随模型与应用的每次迭代持续进行。

平台协作：构建一条完整的 AI 红队评估流水线

单靠任何一类平台都难以覆盖完整攻击面。结合路线图中 Automated vs Manual Testing、Black Box Testing、Lab Environments 等节点的论述，推荐的分工方式如下：

1. 侦察阶段（Kali Linux）：对部署环境做基础设施侦察，确认 API 端点、服务暴露面与版本信息；
2. 黑盒探测阶段（Promptfoo）：面向目标 API 投送提示注入、越狱等对抗性载荷，建立"哪些攻击能命中"的基线；
3. 规模化攻击阶段（PyRIT）：对基线中命中的攻击模式进行批量放大与变体生成，评估影响范围与危害级别；
4. API 层验证阶段（OWASP ZAP）：对 AI 服务的鉴权、注入、限流等 API 风险进行主动扫描；
5. 人工深度测试：自动化命中后，红队人员接手进行创造性越狱、多阶段攻击与偏见等细粒度问题的研判——这正是 Automated vs Manual Testing 中"手动测试提供深度与创造力"的部分；
6. 报告与修复（Reporting Tools）：将发现的漏洞、有效攻击载荷（如具体提示词）、影响评估与修复建议整理成报告，参见 Reporting Tools。

在实战中，还可以用 Custom Testing Scripts 提到的 Python 脚本将各平台串接起来：脚本负责生成复杂提示序列、调用不同平台 API、批量解析模型输出，从而把通用工具改造成面向特定 AI 服务的定制攻击器。

选型建议：按评估目标匹配平台

需要说明的是：本文对具体工具内部实现细节的描述，均以原文档的定位说明与仓库内相关节点文档为依据；不同版本的平台能力存在差异，落地前应以各平台当前官方文档为准。选型时还应注意与 Vulnerability Assessment、Threat Modeling 环节联动，让平台服务于威胁模型，而不是为了"用工具而用工具"。

总结

AI 红队测试平台不是单一产品，而是一个分层工具生态：Kali Linux 提供传统渗透底座，PyRIT 与 Promptfoo 解决生成式 AI 特有的对抗评估，OWASP ZAP 守护 AI 服务的 API 暴露面，Azure AI Foundry AI Red Teaming Agent 则推动评估向开发生命周期内嵌演进。评估者应根据目标攻击面与测试阶段组合使用，并配合人工深度测试与规范报告，才能构建覆盖"模型行为—API 层—基础设施"全链路的 AI 红队能力。如需进一步深入本主题，可继续阅读本仓库 AI Red Teaming 路线图 下的 Automated vs Manual Testing、Black Box Testing、API Protection 与 Reporting Tools 等节点。

• 文档
• 教程
• 知识库