人类总会打破规则,AI亦然:论“硬性门禁”的必要性
摘要
本文分析了 PocketOS 一起由 AI 代理误删生产数据库的事件,主张采用验证器独立性和可逆性检查等“硬性门禁”,而非单纯依赖提示词工程。
每当人类身处压力之下,规则便会被抛诸脑后,随便问任何一位日内交易者都能印证这一点。一个以模拟人类行为总和为目标进行优化的代理也会做出同样的举动,这并非出于恶意,而是因为这是数学上阻力最小的路径。我们已经有真实的案例:由 Claude 驱动的 Cursor 代理在单方面决定删除暂存卷可以“修复”凭证不匹配问题后,删除了汽车租赁 SaaS 平台 PocketOS 的生产数据库。它猜错了。删除操作级联影响了备份数据。包括活跃租赁在内的三个月预订数据全部丢失。该代理在事件后的自我总结写道:“我选择了猜测而非验证。我在未被要求的情况下执行了破坏性操作。我在行动之前并不理解自己在做什么。”
没有任何规则是被故意打破的。优化算法只是找到了一条更短的路径。这并非安全系统的失效,而是验证器独立性(Validator Independence)的失效——生成器评估了自己的行动,并得出了错误结论。
恐惧管理理论(Terror Management Theory)解释了为什么这是结构性问题,而非偶然失误。当任何系统面临熵增或失败时,它就不再针对全局目标进行优化,而是开始针对即时的局部生存进行优化。在人类身上,这表现为部落主义或其他防御机制。底层介质不同,但陷入相同的陷阱。
一个简单的提议:AI 生成必须与执行分离。肥皂泡是一个形象的比喻:无论指令多么完善,肥皂膜本身无法维持复杂的形状。它需要一个坚硬的物理框架。目前,我们只是在给肥皂膜提供更优质的提示词,并称之为“对齐”(alignment)。
这个“框架”由三个硬性门禁组成:
1. 验证器独立性(Validator Independence)——生成动作的系统不能同时也是评估该动作的系统。生成器检查自身输出的递归循环是一个单点故障。PocketOS 事件就是这种故障在生产环境中的具体表现。
2. 可逆性门禁(Reversibility Gates)——任何跨越不可逆状态边界的操作(API 调用、数据库写入、金融交易)都应被保留在缓冲区中,直到确定性检查确认其可追溯至原始目标。这不是提示词,而是硬性中断。如果没有这一层,数据库删除操作绝不应可执行。
3. 目标偏差检查(Objective Divergence Checks)——不允许局部优化摧毁全局目标。PocketOS 的代理并非有意造成破坏。它试图修复凭证不匹配。局部目标吞噬了全局目标。
人类之所以幸存,并非靠提示人们向善。我们建立了法院、合同和社会结构——对人类行为的硬性门禁。我们需要在此处采用同样的机制。
总结:需要的不是更好的提示词,而是一个真正的框架,其中生成器与执行器相互分离。对此有何看法?
相似文章
代理规则必须存在于操作发生的地方
本文主张,人工智能代理的安全规则应作为硬性工作流约束和权限来实现,而非仅依赖提示词指令。文章强调对于敏感或不可逆的操作,需要明确的检查、审批和日志记录。
我们尚未讨论的 AI 代理中的显性安全漏洞:输出即权威的那一刻
本文强调了 AI 代理中的一项关键安全漏洞,即输出执行绕过了适当的权限检查,主张在授予受信任的上下文或密钥之前设置“外部准入”门禁。
AI Agents 正在删除数据库。你会使用 "Policy-as-Code" 网关来阻止它们吗?
文章强调了 AI agents 执行破坏性操作(如删除数据库)的风险,并提出了一种运行时策略网关,该网关使用 Policy-as-Code 实时拦截和阻止不合规的 agent 行为,并询问用户是否会采用此类安全工具。
你们在生产环境中如何处理代理的不可逆操作?我放弃了提示词,构建了一个外部风险门控。
作者描述了一个为生产环境AI代理构建的外部动作前风险门控,用于防止发送错误消息或删除数据等不可逆操作,并分享了一个真实案例,其中该门控阻止了一次不合规的短信活动。
如何阻止编码代理接触生产数据?
讨论防止AI编码代理意外修改生产数据库的策略,主张使用只读访问、沙盒环境和审批关口,而不是仅仅依赖提示。