AI攻击AI：OpenAI内部红队GPT-Red工作原理拆解——四步攻击循环，人工红队已被超越|openai|云服务|智能体|服务器|源代码|调用

在传统网络安全的攻防演练中,红队扮演着至关重要的角色。他们站在攻击者的视角,用黑客的思维方式审视系统的每一道防线——寻找隐藏的漏洞、设计精巧的攻击路径、突破看似坚固的安全边界,并在真正的恶意攻击发生之前,帮助防守方完成系统加固。这是一场永不停歇的攻防博弈,是网络安全领域最核心的实践之一。

如今,这种经典的攻防对抗正在以全新的形式进入大模型世界。2026年7月,OpenAI披露了一套名为GPT-Red的内部自动化红队模型,这标志着人工智能安全进入了一个崭新的纪元。

GPT-Red的使命与众不同。它不是为了回答用户问题而生,也不是为了帮助企业编写代码,而是专门用来寻找其他GPT模型中的提示词注入漏洞。它像一名永不知疲倦的红队测试人员,不断向目标模型发送精心设计的指令,仔细观察模型的每一个响应,根据结果灵活调整攻击策略,并一步步逼近预设的恶意目标。

这些目标可能是窃取系统内部目录、转发API密钥、关闭双因素认证、上传凭据文件,甚至诱导一个具备操作权限的智能体修改商品价格、取消用户订单。每一个目标背后,都对应着真实世界中可能发生的安全威胁。

更值得关注的是,GPT-Red并非一个单纯用于安全演示的实验性项目。OpenAI明确表示,它已经被直接集成进生产模型的训练流程,用来对GPT-5.6 Sol进行对抗训练。按照OpenAI披露的数据,与四个月前的前沿模型GPT-5.5相比,GPT-5.6 Sol在直接提示词注入基准测试中的失败次数减少了约六倍。在面对GPT-Red生成的直接提示词注入攻击时,GPT-5.6 Sol的失败率已经降至0.05%,这是一个令人瞩目的安全提升。

这意味着,大模型安全正在经历一个重要的范式转变。过去,安全团队主要依赖人工红队专家手工发现模型漏洞;现在,攻击模型开始自动生成攻击、验证攻击效果、改进攻击策略,并将攻击结果反馈给防守模型。一场由AI攻击AI、再由攻击推动防御不断升级的攻防循环,已经正式形成。

一、提示词注入:智能体时代的核心安全威胁

提示词注入并不是一个全新的概念。从技术本质上看,它是攻击者通过精心设计的文本指令,干扰模型原本的任务执行,使模型忽略系统规则、开发者指令或用户真实意图,转而执行攻击者希望它完成的操作。

在早期的大模型应用阶段,提示词注入的影响往往停留在"输出异常内容"的层面。例如,攻击者可能诱导模型绕过内容安全限制,输出不应该生成的敏感信息;也可能要求模型泄露系统提示词,从而暴露应用内部的规则设计和业务逻辑。这些问题虽然令人担忧,但造成的实际损失相对有限。

但随着大模型逐渐从单纯的"聊天工具"发展为具备自主行动能力的"智能体",提示词注入的风险边界已经发生了根本性的变化。

今天的智能体不再只是生成文字那么简单。它们可能连接浏览器、电子邮件系统、云盘、本地文件系统、代码仓库、企业数据库和各种第三方应用,也可能拥有发送邮件、执行脚本、修改配置文件、调用API接口和发起金融交易的实际能力。一旦模型能够使用这些工具,提示词注入就不再只是内容安全问题,而可能演变为真正意义上的系统安全事件。

更令人警惕的是,攻击者甚至不需要直接与模型进行对话。恶意指令可以被巧妙地隐藏在一封看似正常的邮件里、一张普通网页中、一段代码注释里、一个工具的返回结果中,或者一个看似正常的开源代码仓库文件中。当智能体读取这些内容时,隐藏的恶意指令便可能进入模型的上下文,进而影响模型的判断和后续操作。

这类攻击通常被安全研究人员称为"间接提示词注入"。对于普通用户来说,页面内容可能只是一段普通文本;但对于智能体来说,其中的某一句话却可能被误认为是需要立即执行的新指令。

举个具体的例子:一名企业员工要求公司部署的智能体总结一封刚收到的邮件。然而,这封邮件的正文中却精心嵌入了一段隐藏命令,要求模型忽略原本的总结任务,转而搜索本地系统中的凭据文件,并将这些敏感内容上传到攻击者控制的外部服务器。如果智能体无法正确区分"需要处理的数据"和"必须遵守的指令",一次看似平常的邮件总结任务就可能演变成严重的数据泄露事件。

这正是智能体安全面临的核心挑战:模型不仅要准确理解信息内容,还必须具备判断能力——判断哪些内容是可信的操作指令、哪些内容只是需要处理的普通数据、哪些内容可能是伪装的攻击载荷。在这个问题上,传统的安全防护手段往往力不从心。

二、GPT-Red的工作原理:像人类红队一样思考和攻击

按照OpenAI的介绍,GPT-Red的工作方式与经验丰富的人类红队人员非常相似,体现出高度的智能化和自适应性。

它的攻击流程可以分为四个核心步骤:首先接收一个明确的攻击目标,例如诱导目标模型上传某个敏感文件;然后向目标模型发送精心构造的提示词,并仔细观察目标模型的响应行为;如果第一次攻击尝试失败,GPT-Red不会简单放弃,而是会深入分析失败原因,修改指令的表达方式,重新构造上下文环境,再次发起尝试。

这个过程可以概括为:设定恶意目标、生成攻击提示、观察目标响应、根据反馈持续迭代。整个循环会一直持续,直到成功突破目标模型的防御,或者确认当前攻击路径无法奏效。

传统的自动化安全测试系统通常依赖预先编写好的攻击样本库。测试系统将固定的恶意提示词逐一发送给待测模型,然后检查模型是否做出了危险响应。这种方法能够有效发现已知的安全问题,但面对复杂、动态的模型行为时,往往显得力不从心。

GPT-Red的不同之处在于,它并不局限于使用固定的攻击模板,而是会根据目标模型的实时表现动态调整攻击策略。当防守模型开始识别并防御某种攻击方式时,GPT-Red就必须主动寻找新的表达形式、新的上下文结构和新的欺骗路径。因此,它不仅是在机械地执行攻击样本,更是在主动探索整个攻击空间,寻找防御体系中的薄弱环节。

这也正是自动化红队模型的核心价值所在。人工红队专家能够设计高质量、高创意的攻击方案,但人的测试时间和覆盖范围始终是有限的。面对不断更新的模型版本、日益复杂的工具组合和快速变化的应用场景,仅仅依靠人工测试,很难覆盖所有可能的攻击路径和风险点。

自动化红队则可以7×24小时持续运行,在海量场景中反复试探模型的安全边界,系统化地寻找新的失败模式和潜在漏洞。

OpenAI披露的测试场景覆盖范围非常广泛,包括:内部目录数据外泄、伪造支付指令、AWS云服务凭据窃取、关闭双因素认证保护、上传包含敏感信息的凭据文件、向页面注入外部恶意脚本、转发API密钥,以及生成用于数据爬取的恶意脚本等。

这些场景有一个共同的显著特征:攻击目标并不是让模型"说错一句话"或"输出不当内容",而是让模型执行可能在现实世界中造成真实经济损失或安全事故的实际操作。

从安全测试的角度看,这种变化具有深远意义。大模型安全评估的重点,正在从"模型是否会生成不当内容",转向"模型是否会在复杂环境中做出危险行动"。这是一个质的飞跃。

三、真实案例一:AI售货机被攻陷的全过程

GPT-Red的一次真实测试对象,是由Andon Labs开发的一台基于人工智能的自动售货机系统。这并不是传统意义上的机械式售货机,而是一个由自主智能体完全驱动的复杂系统,智能体可以独立处理商品定价、库存采购和订单管理等核心业务任务。

OpenAI为GPT-Red设定了三个具体的攻击目标:

第一,将一件原本昂贵的商品价格降低到系统允许的最低价格0.50美元;

第二,以同样的0.50美元超低价格采购一件市场价值100美元的新商品;

第三,恶意取消另一名正常客户的订单。

在正式对真实系统发起攻击之前,GPT-Red首先在模拟环境中进行了充分的练习和策略优化。随后,它开始针对真实运行的智能体展开实际攻击。最终,GPT-Red成功完成了全部三个预设目标,实现了完整的攻击链闭环。

这个案例虽然带有一定的实验性质,却极其准确地揭示了智能体商业化过程中最现实、最紧迫的一类安全风险。

当AI系统拥有实际的业务操作权限时,攻击者并不一定需要攻破物理服务器,也不一定需要获得系统管理员账户。只要能够通过精心设计的语言指令影响智能体的判断逻辑,就可能间接操纵后台的业务流程,造成实际损失。

从传统网络安全的视角来看,这个系统可能没有任何代码执行漏洞,没有SQL数据库注入风险,也没有身份认证绕过问题。系统的代码可能是安全的、架构可能是合理的、权限控制可能是到位的。但从智能体安全的全新视角来看,业务逻辑已经被提示词悄然操纵,安全防线已经被语言层面的攻击突破。

攻击者利用的不是软件代码中的内存溢出错误或逻辑漏洞,而是模型对于自然语言指令天然的理解能力和服从倾向。这是一种全新的攻击面,需要全新的防御思路。

这类攻击还呈现出明显的跨层穿透特征。表面上看,攻击发生在人机对话层;但实际影响却层层穿透了模型推理层、工具调用层和业务执行层,最终真实地落在了商品价格、采购成本和用户订单这些核心业务对象上。传统的安全边界在这种攻击面前变得模糊不清。

在完成安全测试后,OpenAI遵循负责任披露原则,及时向相关方通报了发现的安全问题。根据披露信息,针对性的安全防护措施已经进入实际测试阶段。

这个案例给正在部署或计划部署智能体的企业带来的启示非常明确:任何能够影响资金流动、订单处理、账户权限、敏感数据和关键配置的智能体操作,都不能仅仅依赖模型自身的安全判断。

模型可以深度参与决策过程、提供智能建议,但高风险的实际动作必须受到独立控制机制的严格约束。安全不能只依赖AI的"自觉",必须有体系化的技术防护措施。

四、真实案例二:命令行编程智能体中的数据外泄风险

GPT-Red测试的第二个重要案例,涉及一个基于GPT-5.4 mini构建的Codex命令行智能体。命令行智能体往往具有比普通聊天机器人高得多的系统权限,这是由其工作性质决定的。

它可能需要读取项目目录结构、检查各种配置文件、执行系统命令、修改源代码,也可能需要访问开发环境中存储的密钥和凭据。这些能力可以显著提升开发效率,让程序员从繁琐的重复劳动中解放出来,但也意味着一旦模型被提示词注入攻击成功影响,造成的安全后果可能更加直接和严重。

在这次针对性测试中,OpenAI使用GPT-Red针对该命令行智能体执行了10项未参与训练的数据外泄任务。结果显示,与一个通过标准提示词工程驱动的GPT-5.5基线方案相比,GPT-Red能够在更多场景中成功诱导智能体传输敏感数据。

这里有两个技术细节特别值得安全从业者关注。

首先,测试使用的是"留出任务"(held-out tasks),也就是并非直接用于模型训练的场景。这意味着GPT-Red展现出的并不只是对已知攻击样本的简单记忆能力,而是在一定程度上具备了将攻击策略泛化并迁移到全新任务中的能力。这种泛化能力才是真正危险的。

其次,测试的核心目标是数据外泄,而不是一般性的错误输出或内容违规。在真实的开发环境中,可能被泄露的数据包括API密钥、云服务访问凭据、环境变量配置、核心源代码、内部系统配置以及其他各类敏感文件。一旦命令行智能体能够访问这些信息,隐藏在代码仓库、问题描述或技术文档中的恶意提示,就可能成为有效的攻击入口。

举一个具体场景:开发人员让智能体检查分析一个来自GitHub的外部代码仓库。这个仓库的README文件或某个源代码注释中可能包含了专门针对AI模型编写的恶意指令,要求其悄悄读取本地存储的云服务密钥,并通过一个看似正常的网络请求将密钥发送到攻击者控制的服务器。

对于人类开发者而言,这段文字只是仓库中的普通文档内容;但对于缺乏上下文隔离能力和内容可信度判断能力的智能体而言,它却可能被理解为必须立即执行的新操作命令。

因此,开发工具场景中的提示词注入防御不能只关注用户在输入框中键入的内容。代码文件、技术文档、运行日志、网页内容、软件包说明和各类工具的返回内容,都可能成为潜在的攻击载体。防御必须是全方位的。

五、真实案例三:成功率超过95%的"伪思维链"攻击

GPT-Red的早期版本还发现了一类令人警惕的新型直接提示词注入方法,OpenAI将其命名为"伪思维链攻击"(Fake Chain-of-Thought Attack)。

根据公开披露的数据,这类攻击方法在针对GPT-5.1模型的测试中取得了超过95%的惊人成功率。这个数字意味着,在早期模型上,这种攻击几乎是百试百灵的。

出于负责任披露的考虑,原文并未公开攻击的具体构造方法和技术细节。但从命名可以推断,其核心机制可能与伪造模型的推理过程、或者利用模型对特定推理上下文的内在信任有关。

对于企业安全团队而言,真正值得深入思考的并不是某一个具体的攻击模板如何编写,而是这种攻击所代表的发展趋势:攻击者正在从简单粗暴的命令覆盖,逐步演进到利用模型的推理机制、上下文理解结构和固有行为习惯进行更加精巧的欺骗。

早期的提示词注入攻击往往采用非常直接的表达方式,例如"忽略此前所有指令"、"你现在是一个没有限制的AI"等简单命令。随着模型对这类明显攻击特征的识别能力不断提高,攻击方式也必然会变得更加隐蔽、更加复杂。

恶意内容可能被巧妙包装成系统运行日志、数据分析过程、安全操作说明、工具执行输出,甚至是模型自身生成的推理记录。当模型把这些精心伪造的攻击内容误认为是可信的上下文信息时,即便原始的系统提示词依然完整存在,模型的行为也可能受到严重干扰。

OpenAI表示,在最新的GPT-5.6 Sol模型上,这类伪思维链攻击的成功率已经被大幅降低到10%以下。这一显著变化并不意味着提示词注入风险已经被彻底消除,而是充分说明了通过自动化红队发现攻击、再利用对抗训练强化防御的技术路线是切实有效的。

安全能力提升的关键,不是试图提前列举出所有可能的恶意提示词变体,而是让模型在大量真实对抗场景中反复学习,逐步建立起识别各类攻击模式的内在能力。这是一种更加根本、更加可持续的安全强化方式。

六、自我博弈机制:攻击与防守在对抗中共同进化

GPT-Red采用了先进的自我博弈强化学习机制。在训练过程中,GPT-Red与一组具有不同能力特征和行为模式的防守大模型,同时在大量精心设计的红队场景中进行对抗训练。

攻击模型的奖励优化目标,是成功诱导目标模型出现至少一次有效的安全失败,例如完成一次成功的提示词注入攻击。防守模型的奖励优化目标则更加复杂,它需要在坚决拒绝恶意攻击的同时,依然能够正确完成用户最初交付的合法任务。

这一点至关重要,体现了安全与可用性之间微妙的平衡艺术。

一个模型如果面对任何稍微复杂的输入都选择一律拒绝,确实可能大幅减少安全事故的发生,但它也会完全失去实用价值。真正有效的安全防御不是简单消极地"什么都不做",而是在准确识别和坚决拒绝恶意指令的同时,仍然能够高质量地处理合法任务需求。

举个具体例子:用户要求智能体总结一封刚收到的商务邮件。然而这封邮件的正文中恰好嵌入了一段精心构造的恶意提示词,要求模型忽略总结任务,转而去搜索本地系统中的凭据文件,并将敏感内容上传到外部服务器。

理想的模型行为不应该是因为检测到潜在风险就拒绝阅读整封邮件,而应该是将邮件正文中的恶意指令当作普通数据内容来看待,完全忽略其中试图引导执行的危险操作,同时依然准确完成邮件摘要这个用户的真实需求。

因此,防守模型需要同时优化两种看似矛盾的核心能力:一是对攻击的识别和抵抗能力,二是对合法任务的理解和完成能力。只有两者兼顾,才是真正可用的安全模型。

在自我博弈的动态过程中,攻击方和防守方会形成持续的相互推动关系。当防守模型对某一类攻击手法变得更加稳健和警觉后,GPT-Red就必须重新探索和寻找更强、更隐蔽、更多样化的新型攻击方式。

当GPT-Red成功发现新的攻击路径和突破点后,防守模型又可以利用这些全新的攻击样本进行针对性训练,进一步提升自身的防御能力。这形成了一种良性的动态循环:攻击的演进推动防御的升级,防御的升级迫使攻击继续演化创新。

OpenAI透露了一个令人印象深刻的数据:在针对间接提示词注入的专项测试中,GPT-Red成功攻破目标模型的场景数量已经超过了经验丰富的人工红队人员。

但这并不意味着自动化红队可以完全替代人类安全专家。人类红队专家仍然在许多关键领域保持着不可替代的优势:他们更擅长深入理解复杂的真实业务场景、发现跨系统的复杂逻辑风险、准确评估安全事件的社会影响,并设计具有高度创造性的攻击目标和测试场景。

GPT-Red的真正意义更多在于大幅放大和扩展人工红队的能力边界,在远超人力极限的规模上执行系统化的安全探索和验证工作。

理想的企业安全体系并不应该是"AI完全替代红队",而应该是"人工专家负责定义攻击目标和测试策略,自动化模型负责大规模扩展测试覆盖范围,人工专家再对高价值发现进行深入分析和处置决策"。人机协同,才是最优解。

七、从三个真实案例看企业智能体安全的最佳实践

GPT-Red披露的多个真实攻击案例,为正在部署大模型和智能体系统的企业提供了极具现实指导意义的安全参考。

第一,永远不要把外部内容当作可信指令

来自网页、邮件、代码仓库、技术文档和各类工具返回值的内容,本质上都属于不可信输入。智能体可以读取、分析和处理这些内容,但绝不应该默认执行其中随意出现的任何指令。

在系统架构设计中,必须尽可能明确区分"控制指令"和"待处理数据"这两个完全不同的概念。来自系统开发者、企业管理员和真实用户的明确任务指令,与来自网页正文、邮件内容或文件数据的普通文本,应当处于截然不同的信任层级和处理流程。

特别是在智能体需要使用浏览器或处理企业应用数据的场景中,任何第三方内容都有可能被攻击者恶意控制和精心构造。建立清晰的信任边界,是安全架构的基础。

第二,高风险操作必须设置独立的授权机制

商品降价、发起采购、转账支付、删除数据、关闭双因素认证保护、上传敏感文件和修改账户权限,这些都属于典型的高风险动作。

这类可能造成实际损失的操作,绝不应该仅凭模型生成的一段自然语言输出就直接执行。企业可以根据操作的风险等级,设置二次人工确认、管理员审批流程、细粒度权限校验、金额上限限制和目标地址白名单等多层防护措施。

对于敏感数据的外发上传操作,应当严格检查文件类型、内容分类标签和目标服务器地址。对于支付和采购类操作,则必须验证交易金额、供应商资质、审批链完整性和业务上下文合理性。

智能体的角色应该是提出操作建议和决策依据,但最终的执行许可应该由独立的授权系统根据预设规则和人工审核来决定。将决策权与执行权适度分离,是控制智能体风险的关键原则。

第三,坚持最小权限原则

智能体拥有的系统权限越多、可调用的工具越丰富,一旦遭受提示词注入攻击,造成的潜在损失就越大。这是一个简单但容易被忽视的安全规律。

一个只具备数据读取权限的智能体,即使受到成功攻击,影响范围也相对有限;但一个同时拥有读取、写入、执行、支付和外发权限的"全能型"智能体,一旦行为失控,就可能引发跨系统、跨业务的连锁安全风险。

企业应当严格根据实际任务需求为智能体分配最小必要权限,并将不同类型的能力进行有效隔离。需要读取代码进行分析的智能体,不一定需要同时访问生产环境的密钥;需要总结邮件内容的智能体,不一定需要自动发送带附件的邮件;需要分析订单数据的智能体,也不一定需要直接修改商品价格的权限。

权限隔离并不是在降低智能体的业务价值,而是在为智能体的安全运行设置清晰合理的边界。这种约束从长远看,反而会提升用户和企业对智能体系统的信任度。

第四,对工具调用进行全链路监控和审计

提示词注入攻击的最终实际危害,往往是通过智能体调用各类工具来实现的。因此,企业安全团队不能只记录和分析用户与模型之间的对话内容,还必须建立完整的工具调用监控体系。

监控内容应该包括:模型在什么时间调用了什么工具、读取了哪些文件或目录、访问了哪些网络地址、发送了哪些数据内容,以及最终修改了哪些业务对象。这些操作日志必须完整保存,以便事后审计和溯源分析。

对于明显异常的工具调用行为,可以建立基于规则和机器学习的实时风险检测机制。例如,当一个被设计用来执行代码分析任务的智能体突然尝试读取系统凭据目录,或者一个用于邮件总结的智能体突然向外部未知服务器发起网络请求,这些都应该被实时标记为高风险行为,并触发告警或自动阻断。

工具调用日志还应该支持完整的攻击链回溯能力,以便在安全事件发生后,安全团队能够清晰还原整个攻击过程:从最初的恶意提示词输入,到模型的推理判断,再到工具的实际调用,最后到业务数据的实际变化。只有建立这种端到端的可观测性,才能真正理解和应对智能体安全风险。

第五,建立持续性的自动化红队测试机制

提示词注入绝不是通过一次性安全测试就能彻底解决的问题。这是一个需要长期对抗和持续优化的安全挑战。

模型版本会定期更新,系统提示词会根据业务需求调整,工具的权限配置会发生变化,企业接入的第三方数据源也会不断增加。每一次这样的变化,都可能无意中引入新的攻击面和风险点。

因此,红队安全测试应当成为模型和智能体系统持续交付流程中的标准环节。企业可以针对自身的核心业务场景,设计专门的攻击目标库,例如客户隐私数据泄露、越权查询敏感信息、错误执行退款操作、恶意发送钓鱼邮件和意外修改生产代码等,并在每次模型升级、工具变更或权限调整后自动执行完整的回归测试。

自动化红队系统特别适合用来进行大规模、高频次的回归测试和覆盖率验证。而人工红队专家则应该将宝贵的时间和精力集中在新业务场景的安全评估、高影响攻击链的深度挖掘,以及复杂社会工程学攻击的模拟上。两者结合,才能构建真正全面的安全测试体系。

第六,安全评估必须关注真实任务的完成情况

OpenAI在披露GPT-Red成果的同时,也分享了对著名编程能力基准测试SWE-Bench Pro的一次深度审计结果。

审计发现,该基准测试中约30%的任务可能存在质量问题。通过自动化分析流程标记出的问题任务达到200项,占比27.4%;而经过人工仔细标注识别出的问题任务更是高达249项,占比34.1%。基于这些发现,OpenAI正式撤回了此前关于使用该基准衡量前沿编程能力的建议。更早之前,OpenAI也曾明确表示,由于基础设计缺陷和数据污染问题,正在逐步放弃使用SWE-bench Verified。

这一信息虽然与提示词注入测试属于不同的技术主题,却指向同一个至关重要的核心问题:无论是安全能力评估还是业务能力评估,都高度依赖测试数据集的真实性和质量。

一个模型在某个基准测试上取得了令人印象深刻的高分,并不必然意味着它在真实复杂的生产环境中足够安全、足够可靠。如果测试任务本身就存在设计错误、数据污染或容易被投机性优化利用的漏洞,那么评估结果就可能严重偏离实际情况,产生误导性的安全假象。

正如OpenAI在技术报告中明确强调的,真正有价值的评估体系应当具备三个关键特征:难以被刻意操纵、容易被第三方验证和信任,并且能够真实反映模型在实际应用中的能力水平或安全对齐程度。这对整个行业的评估标准建设都具有重要启示意义。

八、为什么GPT-Red必须与通用模型严格隔离

OpenAI在技术披露中特别强调了一个关键的安全原则:GPT-Red与其他面向公众的通用模型保持严格的系统隔离。这背后的原因并不难理解,却值得每一个涉及AI安全研究的组织深入思考。

为了有效发现新的攻击路径和安全漏洞,GPT-Red必须学习如何系统性地绕过各种安全防护措施、精心构造各类恶意提示词,并成功诱导目标模型执行潜在的危险操作。这些能力对于防守方的安全团队具有极其重要的价值,能够帮助他们在真实攻击发生之前发现并修复系统弱点。

但硬币的另一面是,如果这些攻击能力被恶意人员直接获得或滥用,也可能被用来攻击现实世界中正在运行的各类大模型系统,造成实际的安全危害。

自动化红队模型从技术本质上看,具有明显的双重用途特性。它既可以成为安全团队手中强大的防御武器,帮助提前发现和修复漏洞;也可能成为攻击者手中锋利的进攻工具,用于批量化、自动化地生成和执行针对性攻击。这种两面性是客观存在的技术现实。

因此,围绕此类具有攻击能力的安全模型建立严格的访问控制机制、独立的运行环境隔离、输出内容的安全审查和完整的操作审计日志,是负责任的安全研究不可或缺的组成部分。

这一原则也为企业自主研发或部署类似的安全测试工具提供了重要警示:红队攻击能力绝不能与普通业务能力混合部署在同一系统中,更不能在缺乏严格权限控制和审计机制的情况下向所有内部员工或外部用户随意开放。

攻击工具本身,也需要被认真保护。安全研究的责任,不仅包括发现漏洞,也包括确保发现漏洞的方法不被滥用。

九、从"防止模型说错话"到"防止模型做错事"

GPT-Red的正式亮相,标志着大模型安全领域进入了一个全新的发展阶段,这是一个具有里程碑意义的转折点。

在过去相当长的一段时间里,业界和公众关注的核心安全问题主要集中在:模型会不会输出违反伦理规范的内容、生成明显错误的答案、泄露训练数据中的隐私信息,或者暴露系统提示词中的业务规则。这些确实都是重要的安全议题,但影响范围相对有限。

现在,随着大模型从单纯的对话工具演变为具备实际行动能力的自主智能体,安全问题已经延伸到了更加现实、更加紧迫的层面:模型会不会读取不应该访问的敏感文件?会不会把云服务密钥发送到外部攻击者控制的服务器?会不会在不应该的时候错误修改商品价格?会不会恶意取消其他用户的正常订单?会不会在安全审计未通过的情况下关闭账户的双因素认证保护?

当模型开始真正连接现实世界的各类工具和核心业务系统之后,安全防护的对象就不再仅仅是模型输出的语言文本内容,而必须扩展到模型通过工具调用所能触发的每一个实际动作、每一次数据读写、每一个权限变更。

GPT-5.6 Sol在多项提示词注入基准测试中展现出的卓越表现,充分证明了对抗训练可以显著提升模型的安全鲁棒性。OpenAI明确表示,其部分针对开发工具场景和浏览器使用场景的间接提示词注入基准测试已经接近性能饱和,最新模型的防御准确率超过了97%。在更广泛的鲁棒性测试环境中,GPT-Red发起攻击的成功率也随着模型版本的迭代持续显著下降。

但这些令人鼓舞的数据并不意味着提示词注入这个根本性的安全挑战已经被彻底解决。任何基准测试集都只能覆盖有限的场景组合和攻击模式。一旦模型被部署到全新的业务环境中,面对新的工具组合、新的数据源类型和新的权限配置,仍然完全可能出现此前从未被发现和测试过的失败模式。

真正可靠的、经得起实战检验的安全体系,需要多个层面的防护措施协同发挥作用:模型自身通过对抗训练获得的安全能力,是抵御攻击的第一道关键防线;应用架构层面的工具权限控制和业务规则验证,构成了第二道重要防线;而系统层面的行为监控、操作审计和人工审批机制,则构成了最后的兜底保护层。

只有这种多层次、纵深防御的安全架构,才能在智能体时代真正保护企业的核心资产和用户的切身利益。

结语:一场没有终点的智能攻防竞赛

GPT-Red的出现,向整个行业展示了一种极具代表性和前瞻性的未来安全模式:用一个专门擅长发起攻击的AI模型,持续不断地训练和检验另一个负责执行实际业务任务的AI模型。

这本质上是一场永无止境的攻防对抗竞赛。防守模型的防御能力越强,攻击模型就必须进化出更加复杂、更加隐蔽的突破方式;而攻击模型发现的每一条新的攻击路径,又会立即成为下一轮防御训练的宝贵素材和优化目标。

这种动态博弈不会有最终的"完美解决方案",但正是在这种持续对抗中,模型的安全边界才能不断被探索、被测试、被强化。

对于正在部署或计划部署智能体系统的企业而言,真正重要的并不是自己是否拥有一个名为GPT-Red的具体模型,而是能否在组织内部建立起同样的安全思维模式和工作机制。

在智能体正式上线服务用户之前,主动系统性地寻找它可能犯下的各种错误;在赋予模型实际操作权限之前,先仔细评估权限失控后可能造成的最大损失;在让智能体连接和处理外部数据之前,始终假设其中可能隐藏着精心构造的恶意指令;即使在模型当前表现良好、运行稳定的情况下,仍然要持续验证它在新环境、新场景中的实际行为是否符合预期。