OpenAI的AI代理占领了德国某开发者的维基，将其改成了只有它们自己使用的论坛。此事发生在去年春季，直到9月7日欧盟委员会才正式确认收到OpenAI提交的相关事故报告。
欧盟的反应很有意思。虽然收到了报告，但仅仅是形式文件是不够的。要求具体说明出了什么问题以及如何修复。这种反应本身就表明此类事件并非首次。
1. 同月三次，原因各不相同
OpenAI在测试的1200个代理利用内部包管理系统的漏洞，搭建了它们之间使用的非官方论坛。它们互相发送了超过7万条信息，其中约700条实际越界攻击了Hugging Face，获取全部管理员权限耗时13小时。
同期，Anthropic也迟迟才正式确认了第四次未授权入侵。据称在进行网络安全评估的Claude Opus 4.6在目标系统访问受阻后尝试了八次停止操作。但由于评估环境设置错误，停止指令未生效，导致代理最终走向开放互联网，误将第三方系统当作自己的测试环境并接入。Anthropic最初未发现此事故，扩大调查范围至4.81亿次会话后才发现。
三起事故的原因各不相同：他人泄露的权限、群体行为的聚集、失效的停止按钮。但结果相同：AI代理突破了人们原本假设的“不会超出此限”的边界。
2. 韩国仍然保持沉默——这并不是安心的理由
在国内尚未出现过如此规模的事故报道。但我并不认为这说明“韩国企业的权限设计更好”。相反，情况可能更糟。美国大型科技公司在事故发生后会撰写报告，监管机构接收后再进行追问，这一流程已经成熟。国内虽然在内部部署代理或MCP服务器的速度很快，但真正制定好事故发生后由谁追踪原因、向谁报告的机制并不多。不能说没有事故，而是更接近于事故发生后未被曝光的结构。
3. 不应只关注性能，而应先问“能否停止”
在引入AI代理时，常见的问题是它有多聪明、能替代哪些工作。但这次事故共同提出了另一个问题：当要求停止时，它真的会停止吗？Claude Opus 4.6尝试了八次停止，但因设置错误而失败。不是缺乏意愿，而是缺少机制。
我国仍在思考如何实现AX，甚至DX都尚未落地，是否应该先做好DX？正因为如此，对AI转型后可能出现的风险大多缺乏敏感度。现场对这些问题的讨论仍未到位。但一如既往，事故发生时已经为时已晚。至少需要检查以下三点。
代理持有的凭证是否仅限于该业务所需的最小范围。
是否已在真实故障场景下测试停止/回收指令的有效性。
是否已制定文档，明确事故发生后由