AI 越狱(jailbreak)问题不会消失,合规框架也需要跟上
Jun 17, 2026
几周前,美国政府发布了一项 指令,要求 Anthropic 暂停其两款前沿 AI 模型的访问权限,分别是 Fable 5 和 Mythos 5,并称其与一项被报道的越狱(jailbreak)技术相关。Anthropic 按要求执行了,尽管它同时在公开场合对这一发现是否值得如此激烈的回应提出了争议。
我并不是来重新争论那项具体决定的。但这起事件迫使我们必须正视一个问题:我们的行业长期以来一直在回避它。如果连最重视安全的 AI 提供商都承认,完美的 jailbreak 抵抗能力可能无法实现,那么我们到底期待安全团队防御的是什么?又应该用哪些工具来防御?
关于 AI 安全防护的令人不适的真相
有件事大多数 AI 供应商不会直接说:如今部署的每一个模型都容易受到某种形式的 jailbreaking 的影响。提示词注入、角色扮演攻击、间接提示词操纵、上下文漂移。这些方法都有所记录,正日益自动化,并且正在被用于对企业 AI 部署进行攻击。
但许多最危险的 jailbreak 攻击向量根本不针对模型本身。它们攻击的是模型周围的基础设施:配置文件、部署设置、监控控制,以及管理模型在生产环境中如何表现的审计流水线。
禁用正确的安全控制、修改正确的配置参数,你就不需要什么高明的提示词了。你已经赢了。
这就是一个经典的配置完整性问题。而且我们知道该如何思考这个问题。
AI 基础设施篡改的真实样貌是什么
从基础设施角度来谈保护 AI 系统时,我们指的是保护一组特定资产——而大多数组织尚未将这些资产纳入正式的变更控制:
系统提示文件和策略规则集
许多企业级 AI 部署依赖于存储在本地的系统提示文件,用于定义模型行为、内容策略以及访问限制。这些文件可能位于磁盘上,或存放在配置存储中。它们往往可以被任何拥有文件系统访问权限的人编辑。即使系统提示中的一条指令发生更改,也可能从根本上改变模型将会和不会做什么,而且不会触发任何基于模型级别的保护措施。
模型部署配置
用于控制温度、上下文长度、工具访问以及安全过滤器启用情况的参数通常存储在配置文件或环境变量中。对这些设置进行未经授权的修改,可能在不接触模型本身的情况下抑制安全行为。
安全过滤器与内容策略设置
许多 AI 平台将内容过滤作为模型之外的独立层来实现。这些过滤器本身就是软件,包含配置文件、策略定义以及受版本控制的规则集。能够修改这些文件的攻击者,可能在不引起注意的情况下降低模型将要生成内容的门槛。
监控与日志管道
审计跟踪只有在完整无损的情况下才有用。如果攻击者能够禁用或修改 AI 系统的日志配置,他们就可以掩盖自己的活动,并显著增加取证调查的难度。
这些攻击路径都不需要复杂的提示(prompt)。它们需要的是访问权限、机会,以及缺少对变更的监控。配置完整性(configuration integrity)工具正是为弥补这一差距而设计的。
了解 Netwrix Change Tracker 如何帮助检测未经授权的变更,并在支撑您 AI 部署的各个系统中保持可视性。立即获取演示。
Change Tracker 在其中扮演的角色
Netwrix Change Tracker 正是为了解决这类问题而构建:在关键系统中维护已知良好(known-good)的基线,并在任何偏离发生时以实时方式检测到它。
应用到 AI 基础设施中,这意味着:
面向 AI 配置资产的文件完整性监控
Change Tracker 使用加密哈希为每个被监控的文件建立一个经验证的基线。如果系统提示文件、安全策略定义或模型配置发生变化,无论是通过合法更新还是未经授权的篡改,Change Tracker 都会立即检测到。每一次变更都会记录时间戳、执行变更的用户身份以及具体发生变化的属性。没有歧义。也不会缺失上下文。
在 Windows 上,Gen 7 Agent minifilter 驱动在内核级运行,位于 Windows Filter Manager 栈中的 altitude 388790,可在实时捕获文件 I/O 变更的同时,不锁定文件也不增加延迟。 在 Linux 上,Sysdig 集成会在系统调用级别捕获是谁进行了变更。无论哪种方式,检测都是持续的,并且在取证层面非常精确。
以加固基线为前提的安全配置管理
CIS Benchmarks为组织提供用于加固服务器配置的可执行起点。Change Tracker 随附 250+ 个预先构建的合规报告,并已映射到 CIS、NIST 800-53、PCI DSS、HIPAA、DISA STIG 等,覆盖 Windows、Linux、数据库和网络设备。针对 AI 基础设施,同样的加固原则也适用:减少攻击面,在操作系统级别强制执行最小特权,并持续验证你部署的配置是否正是实际正在运行的配置。
用于 AI 系统修改的闭环变更控制
对 AI 部署所进行的每一项合理变更,都应在发生之前获得授权。Change Tracker 的闭环变更控制与 ITIL 和 COBIT 原则直接对齐:计划变更会提前记录、在已批准的变更窗口内进行跟踪,并会自动与实际观测到的活动进行核对一致。未计划的变更(即与已授权变更请求不匹配的修改)会立刻以告警形式暴露出来。
对于使用 ServiceNow、BMC Remedy 或其他 ITSM 平台的团队而言,Change Tracker 的原生集成会自动导入变更请求,并利用这些请求对检测到的变更进行分类。如果你的 AI 基础设施在已批准工单之外发生了变更,你会知道;如果变更发生在工单之内,则会抑制噪声,你的团队就能专注于真正重要的内容。
覆盖混合 AI 环境:有代理与无代理一体化监测
AI 基础设施并不只部署在一个地方。计算资源可能在本地(on-premise)。模型托管可能在 AWS 或 Azure 中。配置管理也可能使用多种工具的组合。Change Tracker 支持通过 Windows 和 Linux 上的 Gen 7 Agent 进行基于代理的监测;对于无法切实部署代理的系统,则通过 SSH 和 WMI 提供无代理覆盖。ESXi 和云环境则通过基于 PowerCLI 的无代理收集进行覆盖。监测模型与基础设施模型相匹配。
用于合规与数字取证的不可篡改审计追踪
当 AI 系统出问题时,无论是出现了意外输出、报告的安全性故障,还是疑似发生了基础设施被攻破,第一 个问题总是:发生了什么变化? Change Tracker 会维护一份持续的、可验证未被篡改的记录,涵盖在被监控系统中发生的每一次配置变更。该记录可立即获取,支持检索,并可导出为满足审计要求、同时支持事件调查的格式。
法规所覆盖不足之处
《欧盟人工智能法案》是一个重要步骤。NIST 的《人工智能风险管理框架》也很周到。但这两者都没有充分解决围绕 AI 部署所需建立的运营安全控制——也就是安全团队真正会落地并按其进行审计的那类控制。
我认为,任何企业级 AI 部署都应当以基线方式、作为强制性要求来落实的内容如下。即使目前还没有完全到位针对 AI 的专门指导,CIS Controls 已经在朝这个方向指引了:
持续的配置监控
应当持续监控 AI 系统配置,防止未经授权的变更:包括版本、参数和防护规则(guardrails)等本地部署的模型;包括系统提示(system prompts)、身份文件(identity files)、内存存储(memory stores)以及工具定义(tool definitions)等代理(agent)的执行环境;以及代理所进行身份验证并写入的外部基础设施(例如 MCP 服务器、密钥库(key vaults)、凭据存储(credential stores)、审计流水线(audit pipelines)和技能市场(skill marketplaces))。不按季度审查。不在部署时检查。持续进行。当任何内容偏离已批准的基线(approved baseline)时实时告警。
正式的变更管理
对 AI 系统的每一次修改都应当需要授权、文档记录和复核。这并不是为了增加官僚式的负担,而是因为未计划的变更正是攻击者和事故都能借此制造突破口(opening)的方式。闭环变更控制(Closed-loop change control)把变更从风险转化为证据。
用于 AI 资产的文件完整性监控
系统提示文件、安全规则集以及模型配置文件应满足与关键操作系统文件相同的完整性要求。SHA-256 哈希校验。与基线进行对比。发现偏差时立即告警。这是用于符合 PCI DSS 的标准做法。AI 部署中也应同样采用这一标准做法。
不可更改的审计追踪
与 AI 基础设施相关的每一次管理操作、配置变更、策略修改以及安全事件,都应以无法轻易被篡改或删除的方式记录下来。该日志既是取证资源,也是合规凭证。
对 AI 基础设施实施最小权限
对 AI 部署环境的特权访问,应当以与管理对 Active Directory 或关键数据库的访问同样的方式来进行治理:实施严格的控制、承担完整的责任,并持续监控谁拥有访问权限以及他们用这些权限做了什么。
纵深防御的必然要求
尽管对提示(prompt)级防护的关注很重要,但它却造成了对“AI 安全”实际意味着什么的错误认知。组织在受控测试中依据模型抵抗越狱(jailbreak)的能力来评估 AI 供应商,却基本放任周边基础设施缺乏治理。
攻击者早就知道这一点。他们并不会把所有时间都花在编写巧妙的提示词上。他们在寻找运营链条中最薄弱的环节:未被监控的配置文件、权限过高的服务账号、被悄悄禁用的安全过滤器、以及无人记录的变更。
这些并不是模型问题。它们是 配置(configuration)和变更控制(change control)问题。而且这些问题有直接了当的解决方案,运营受监管工作负载的组织早就知道如何部署。
下一步需要做什么
监管机构需要更快行动,并且要以更具体的方式行动。关于 AI 治理的宏观原则可以作为起点,但安全团队真正需要的是明确、可审计的控制要求:那种你能够实施、测试,并持续验证的要求。
以 CIS Controls 已经为 IT 基础设施规定的内容为蓝本、并明确扩展到 AI 部署环境的强制性基线控制,将为组织提供一个切实可行的起点,并为审计人员提供有意义的基准。配置监控。变更管理。文件完整性验证。审计追踪要求。它们本质上只是将严谨的安全实践应用到一个迄今尚未受到应有审查的场景中。我们知道这些解决方案会是什么样子。工具已经存在。框架也已经存在。现在是时候让这些控制变为强制要求了。
常见问题(FAQs)
分享到
了解更多
关于作者
Dan Piazza
产品管理经理
Dan Piazza 是 Netwrix 的产品管理经理,负责多种 Endpoint、DSPM 和 Directory 产品。他自 2013 年起从事技术岗位工作,热衷于网络安全、数据保护、自动化和代码。在担任现职之前,他在一家数据存储软件公司担任产品经理和系统工程师,管理并落地了软件与硬件的 B2B 解决方案。