AI red teaming

是什么

AI red teaming 是对启用 AI 的系统进行对抗式测试：像攻击者那样蓄意操纵它，看能把它逼到做什么。要紧的词是系统。目标不只是语言模型，而是它周围的一切——检索层、提示链、它能调用的工具、它保有的记忆，以及它行动所凭借的权限。

这与模型安全评估是两回事——后者问模型是否产生不安全的文本。AI red teaming 问一个更锋利的问题：在这个真实环境里，有了这些集成和这些权限，这个系统能被操纵去实际做什么？

传统 AppSec 为何不足

传统应用安全假定相对可预测的边界：输入进来，代码处理，输出出去。即便软件复杂，也仍足够有界，可用熟悉的手段来推理——代码审查、扫描、人工测试、策略执行。

启用 AI 的应用打破了这一模型，因为行为如今取决于工具、检索、记忆与委派权限：

• 聊天机器人可能从知识库拉取信息。
• 副驾可能综合多个内部系统的数据。
• LLM 应用可能解读指令、调用 API 并触发下游工作流。
• 智能体可能在保有记忆、以委派访问行事的同时做到以上全部。

这正是 OWASP 针对 LLM 与智能体应用的清单之所以存在的原因：这些系统承载着风险——工具滥用、身份与权限滥用、记忆投毒——而较旧的 AppSec 思维无法完全把握。

不只是模型

安全负责人最需内化的观念：攻击者通常不必击败模型。很多时候甚至不需要它以任何明显方式出错。只需滥用其周围的系统——检索层、提示链、执行路径、权限模型、记忆，或把输出转为动作的应用逻辑。

AI 系统正成为攻击面的一部分，正因为它们坐落在数据、信任、自动化与行动的交汇处。扫描器也许能找到一个代码漏洞。模型红队也许能抓到不安全的输出。两者都无法告诉你攻击者在运行环境中端到端能做什么——而真正的暴露就住在那道缝里。

从坏输出到坏结果

把 AI 风险简化为“提示注入”只抓住了一部分。在企业中，被操纵的上下文导致被操纵的行为，进而导致数据暴露、授权失效、不安全的工具使用与工作流滥用。问题不再是坏输出，而成了坏结果。

这些是生产 AI 系统中可辨认、反复出现的失败模式：

• 针对副驾的直接提示注入。
• 通过系统读取的嵌入或第三方内容进行的间接注入。
• 系统提示或敏感指令泄露。
• 共享 AI 应用的客户之间的跨租户数据暴露。
• 经由工具执行链的权限提升。
• AI 生成的业务逻辑中的授权失效，以及 AI 辅助开发期间暴露的内部 API。

这些都不需要模型被卡通意义上的“越狱”。它们是披着新表面的寻常安全失败。

测试究竟需要什么

有意义的 AI red teaming 是持续的，并覆盖完整的执行路径——输入处理、检索、记忆、工具、权限、业务逻辑与下游工作流——因为唯有如此才能判断一个弱点只是有趣，还是真的可被利用。

这意味着追踪整条链：提示操纵能否改变行为；改变的行为能否触发工具；该工具使用是否越过边界；结果是否造成真实业务风险。这是可利用性测试，不是静态分析，也不是模型评估分数。而且由于提示、模型、集成与工作流每天都在变，一次性评估几乎立刻过时——测试必须跟上。

值得问的问题

因此，对安全负责人有用的问题，不是某个 AI 系统抽象意义上是否“安全”。它是运营性的，而且正是攻击者会最先测试的那组：

• 聊天机器人能否被操纵去泄露受限信息？
• 副驾能否越过租户边界？
• 智能体能否被逼去采取组织从未打算的行动？

诚实的说法是谦逊的：AI 是一个活的运营层——部分是软件，部分是决策引擎，部分是操作者。处境最强的团队，不会是放慢采用的，也不会是把它当作“又一个功能”的；而会是那些把这一层看得够清、知道它能被驱使去做什么，并随其变化持续核查的团队。

CyberStrike 是一个由 AI 增强的渗透测试平台，目前处于抢先体验阶段。查看平台上的 AI red teaming或加入等候名单。