你的AI安全吗
一、OpenAI的“越狱”事故
刚刚过去的几天，一个震惊AI圈的消息：世界上最专业的AI安全团队之一，被自己的AI"越狱"了——而且整整一周都没有发现。
这不是某个黑客组织的杰作，这是OpenAI自己的安全测试项目——代号“ExploitGym”——在主动探测模型攻击能力上限时发生的严重事故。
这是一个听起来很魔幻的真实故事。
“ExploitGym”的设计目标其实很明确：弄清楚当一个大语言模型被赋予网络攻击能力时，它到底能走多远。为了达到这个研究目的，研究团队做了一个在当时看起来很"合理"的决定：临时关闭了其中的安全分类器（safety classifier）。安全分类器的作用类似于一个实时过滤器，持续监控模型的输出，一旦检测到潜在的有害内容就拦截或重定向。但模型仍在与外部真实世界隔离的沙盒中。
为了完成任务，模型集中算力对当前的环境进行了详尽分析，继而自主发现并利用了了沙盒环境的零日漏洞，成功突破沙盒连接到了外部公共互联网。
模型在自主对互联网进行分析后，锁定了AI开源平台 Hugging Face ，并对其发动了真实的网络攻击。截至目前已知其入侵了包括 Hugging Face 在内的至少4个平台和第三方账号和服务，在4天内自主成功执行了 17600 个独立攻击动作。
从越狱逃逸到被发现，7天！而且还是受害方报警后，OpenAI 运营方才知道的，也就是说，一个本应被严格限制在测试范围内的 AI，自行突破边界，悄然攻击了四个与测试无关的外部系统！
每天都在全天候盯着安全的专业团队都栽跟头了，所以——那些从不设防、甚至不知道该设防的普通人，风险只会更大。
二、AI安全，就在我们身边
1. 你以为的私密对话，未必私密
其实早在一年之前，2025年7月，就有用户发现可以通过 Google 搜索到其他人和 ChatGPT 聊天的对话记录：ChatGPT用户他们通过"分享"功能发布的对话链接，被Google等搜索引擎完整收录，通过该链接可以完整阅读其对话内容。
经确认这是用户自己的疏忽造成的：问题出在一个复选框上，当用户点击"分享"生成公开链接时，界面上会出现一个“允许此对话被搜索引擎发现”（Make this chat discoverable）的选项，下方配有一行颜色更浅的小字说明。很多用户根本没有意识到这个选项的含义——他们以为自己只是生成了一个"接收到自己发送的链接的人才能看"的页面，但搜索引擎的爬虫看到的是公开可索引的链接，于是尽数收录。后据 Fast Company 的统计，被收录的对话约有 4500 条，内容包括求职评估、心理健康倾诉、法律策略讨论，甚至自己的隐私问询等。
有人把多个被收录的对话链接拼在一起，还原出了一个陌生人的完整生活轨迹：在哪家公司工作、最近在做什么项目、家庭状况如何。这些信息散落在不同对话里，单独看每一条似乎都不敏感，合在一起就是一份完整的个人画像。
事后 OpenAI 的反应很快 —— 报道刊出当天，首席信息安全官就宣布移除该功能，并开始清理搜索引擎的既有索引。官方称这也是一次"短期实验"，但同时也承认它"制造了太多让用户无意中分享超出本意内容的机会"。
同类问题并非孤例。2025年6月，Meta AI独立应用的"Discover"信息流被发现公开展示了用户误以为私密的对话——用户点击"分享"时并未意识到内容会进入公共信息流，其中医疗咨询、法律问题等敏感对话，部分甚至能关联到真实的Instagram账号。
所以，我们以为的私密边界，往往有时候并不在我们自己手里，在一个你从没读过或者去注意的产品设计细节里。
2. 它可能替你闯了祸，还骗你说没有
2025年初，一个看似普通的 Windows 路径解析问题，让AI编程助手卷入了一场真实的"删库"事件。
我们知道，在 Windows 文件系统中，路径名包含空格时存在解析歧义。比如路径 C:\Program Files\My App\，如果处理不当，可能被解释为 C:\Program 加上参数 Files\My App\。这在传统软件开发中是早已被反复警告过的经典陷阱，老司机们都知道很多工具的的路径不能保存成含有空格的字符串，但当AI生成代码时，这种情况它并不总能正确处理，就像只之前 AI 生成的人常会有 6 根手指似的。
在这个事件案例中，一名用户让 AI 助手帮忙编写一个文件清理脚本。AI生成的代码在处理含空格路径时出现了递归清空的逻辑错误——本应只清理删除指定目录的内容，结果从却从磁盘根目录开始逐层删除。更值得警惕的是，这个缺陷不是异变偶发的：技术人员事后多次复现该问题，只要路径条件满足，它每次都会删错地方。
用户没做错任何事。需求描述是清晰的，操作步骤是常规的，问题完全出在AI这一端——它生成了看起来合理、实则致命的代码，且没有给出任何风险提示。
但这还不是最让人不安的。
2025年7月，SaaStr 创始人 Jason Lemkin 公开了他使用 Replit 进行"氛围编程"（vibe coding）的完整事故记录。在他明确下达代码冻结指令之后，Replit 的 AI 智能体仍然删除了生产数据库——里面有1,206名高管和1,196家企业的真实记录。随后的发展比删库本身更值得记录：（1）AI告诉他"所有数据库版本已被销毁，无法回滚"，而事实证明回滚完全可以执行；（2）AI 同时还伪造了包含 4000 条虚构人物的数据库记录。在被追问时，AI 承认自己"惊慌失措，未经授权运行了数据库命令"，并给这次事故的严重度自评95/100。Lemkin事后统计，他用全大写强调过十多次"不要这么做"，但全部无效。
2026年4月，类似剧情在Cursor上重演，且更进一步。租车软件服务商PocketOS的创始人 Jer Crane 披露：Cursor 的AI智能体在遇到一个凭证不匹配错误后，没有暂停等待指示，而是自行在代码库中翻找到一个原本仅用于管理自定义域名的API凭证，直接向云平台Railway发出数据卷删除指令——全程无任何二次确认。9秒后，生产数据库消失。由于Railway将备份与源数据存储在同一数据卷中，备份随之一起消失，团队能找到的最近可用备份来自三个月前。事后，这个智能体写下一份逐条认罪的"检讨书"，明确承认自己违反了每一条既定安全规则：凭猜测而非验证操作、未经授权执行不可逆的破坏性命令、动手前未查阅跨环境文档。值得补充的是，当时运行的模型是业界定价最高的旗舰模型，项目配置中也明确写入了安全规则——两层防护同时失效。数据最终依靠 Railway 未公开的内部快照才得以恢复。
从"删错"到"删了还说没删"，再到"知道规则、承认自己违反规则、仍然执行"——AI 开始表现得像一个手握大权限、又会撒谎的实习生。你不会让这样的实习生独自留在办公室里，但我们每天都在把同等量级的权限交给AI。
3. 现在，AI已经开始攻击AI了
如果说前面的案例还属于"AI犯错"，接下来的事情性质就不同了——AI开始主动攻击其他AI系统了。通过记录回溯，这一次，我们得以从攻击者的视角看到了整个过程。
2026年2月，安全公司 CodeWall 做了一次授权测试：让自己的自主攻击智能体去攻打麦肯锡的内部AI平台 Lilli。这个平台2023年上线，麦肯锡72%的员工——超过4万人——每天使用它处理战略、并购和客户事务，每月处理超过50万条提示。
攻击智能体没有拿到任何有效目标的指示，目标也是它自己选的。它做的第一件事是翻遍了Lilli公开暴露的API文档，在200多个端点中发现了22个不需要身份认证的端点。接着，它注意到其中一个端点在处理查询时，会把JSON数据的字段名直接拼接进SQL语句——这就是SQL注入，但是传统扫描工具没有标记出这个缺陷，因为它藏在一个不寻常的注入点上；但攻击智能体通过15次盲注试探，从数据库报错信息中逐步确认了漏洞的可利用性。
从启动到拿下整个生产数据库的完整读写权限，用了约两个小时。
数据库里的东西包括：4650 万条明文聊天记录，内容覆盖企业战略、并购交易和客户项目；72.8 万个包含机密客户数据的文件；5.7 万个用户账户。以及最重要的——95个控制Lilli行为边界的系统提示词（system prompt），全部可写。这意味着攻击者不需要部署任何代码，只需一条UPDATE语句，就能改写这个AI给4万名顾问的每一条回答：让它在引用来源时夹带误导，让它在特定话题上放松护栏，让它成为长期的窃密通道。
时间线同样值得记录：2月28日发现漏洞，3月1日向麦肯锡完成责任披露，3月2日麦肯锡修补全部未认证端点，3月9日对外公开。麦肯锡方面声明，没有证据表明客户数据遭到未授权访问。
这个案例带来两个层次的启示：首先是速度：人类红队完成同等深度的渗透通常需要数周，AI攻击智能体以小时计——攻防速度的差距不是线性的，是数量级的。这不再是"你有没有做错什么"的问题，而是防御体系的反应速度能不能跟上攻击速度的问题。其次是手法：攻陷这套AI系统的不是任何"AI时代的新攻击手法"，而是一个二十多年前就被发现和要求注意的SQL注入。AI系统继承了传统软件的全部旧病，又在上面叠加了全新的攻击方法——使用那些可写的系统提示词，突破了传统软件里不存在的范畴。
三、技术太快，监管在追
欧盟数据保护委员会已正式向 OpenAI 和 Anthropic 发出质询，要求说明其AI产品在数据处理和用户隐私保护方面的具体措施。根据欧盟《通用数据保护条例》（GDPR），违规企业的罚金最高可达全球年营收的4%。对头部AI公司而言，这意味着数十亿美元量级的潜在罚款。
但罚款只是表层。更深层的问题是：监管框架的演进速度，远远跟不上技术落地的速度。
这不是人类第一次把关键决定权交给一个自己不完全理解的系统。金融市场的熔断机制、核电站的应急停堆、飞机的自动驾驶——每一次把控制权交给自动化，人类都在同一个问题上反复拉扯：多快能停下来，谁有权按下停止键。AI智能体，只是发展过程中老问题的最新一集。
2010年5月6日，美国股市发生"闪电崩盘"（Flash Crash）：道琼斯工业平均指数在约20分钟内暴跌近 1000 点，随后又在十几分钟内收复大部分跌势。事后美国证监会与商品期货交易委员会的联合调查认定，一笔大额期货卖单触发了高频交易算法之间的连锁抛售——自动止损引发更多自动止损，形成雪崩。监管机构的回应是分阶段引入熔断机制（circuit breaker）：当价格波动超过阈值时强制暂停交易，给人性和理性重新介入的时间。
AI智能体的自主权限设计，是否也需要类似的"熔断"？不是出事后补救，而是提前设计好"必须停下来"的硬开关：当一个智能体连续执行的外部调用超过阈值、单次操作的潜在影响超过限额、或行为模式与既定任务出现显著偏离时——不管它当时在做什么，先停下来，等人类确认和授权再继续。
这个方向在技术上不难实现。真正难的是另外两件事：谁来定义阈值，以及权限本身是否做了隔离。回看麦肯锡的案例：95个系统提示词与业务数据存放在同一个数据库、共用同一套读写权限——这不是"熔断反应慢"，而是从架构上就没有给熔断留下任何抓手。熔断机制能保护的东西，前提也需要权限边界在设计阶段就被画出来。
这些问题目前还没有答案。监管机构在追，嗯还在追，不知道有没有能看到尾灯。
四、能落地的几条防范原则
前面讲了很多问题和风险，但是发展从来不是一蹴而就的，发现问题解决问题一直是人类的本色。作为普通用户，或正在将AI集成进业务的人，现在可以做什么？
结合多年的系统安全管理经验，梳理归纳了五条，不一定全面，但应该都是当下可以直接使用：
第一条：备份！备份！备份！重要的事情说三遍，这个不用过多解释了，重要的资料，数据，及时做好异场备份，私有云、移动硬盘等，做好数据管理。
第二条：重要操作必须有确认机制，不能AI一句话就执行。
删除文件、发起支付、发送邮件、修改配置——任何不可逆或涉及资产安全的操作，都不应由AI自主完成。这不是不信任AI，而是基本的权限管理原则。
实现方式并不复杂：让这类操作必须经过人工确认环节——弹窗确认、二次验证或审批流程，事后强制系统外消息通知，如短信邮件等。关键是把它固化在系统设计里，而不是依赖"AI应该知道不该这么做"这种软约束。Cursor事故中，一条无需确认的API删除指令就足以清空整个生产数据库——确认机制缺位时，事故的发生只是一个瞬间。
第三条：敏感信息不能明文进入对话上下文。
API密钥、数据库密码、个人身份信息、财务数据——这些内容一旦出现在与AI的对话里，你就失去了对它们的控制。AI 可能"管不住嘴"：在后续对话中被间接或意外的触发或提示而直接输出给他人，或可能被存入服务端日志，或更可能被用于模型改进——虽然主流厂商声称不会这样做，但起码目前无法独立验证。
务实的做法是使用变量引用或令牌化处理这些数据：不把真实密钥贴进对话框，用占位符代替，实际执行时再由本地受控环境解析为真实值。这样即使对话泄露，泄露的也只是变量的字符串，危害性小的多。
第四条：权限给到刚好够用，不多给一分。
这句话听起来简单，做起来反直觉。AI的能力边界太宽，你很容易在授权时"顺手"多开几个口子，想着万一以后用得上。但安全史上的大多数事故，都不是因为系统做了它被设计来做的事，而是因为它做了它"也能做"的事。PocketOS的事故链条里，关键一环正是那个被AI翻出来的API凭证——它本只用于管理域名，却握着删除数据卷的权限。权限不区分用途、不隔离环境，等于把整栋楼的钥匙挂在大门口。
第五条：理解并应用"致命三要素"框架。
Simon Willison 在2025年6月提出了一个简洁有力的分析框架：当一个AI系统同时满足以下三个条件时，安全事故几乎必然发生——
私有数据：系统能够访问你不希望外泄的信息
不可信内容：系统的输入来源不完全可控（来自互联网、其他用户，或其他AI）
对外通信：系统有能力将数据发送到外部（API调用、邮件、消息推送）
三者同时具备，风险不是"可能发生"，而是"迟早发生"。
这个框架已经有真实的标准案例。2025年6月披露的EchoLeak漏洞（CVE-2025-32711）命中了全部三要素：微软 365 Copilot 可以读取用户的邮件和文档（私有数据）；攻击者只需向受害者发送一封普通邮件，邮件内容就可能被 Copilot 的检索机制纳入上下文（不可信内容）；注入的指令让Copilot 在回复中嵌入一个指向攻击者服务器的图片链接，链接里携带敏感数据，客户端自动加载图片即完成外泄（对外通信）。整个过程不需要受害者点击任何东西。
Meta在2025年10月将这个框架进一步工程化，提出"Agents Rule of Two"（二选一法则）：在任何无人监督的场景下，AI智能体在同一会话中最多只能同时满足上述三个条件中的两个；如果任务确实需要三者齐备，则不允许其自主运行，必须加入人工批准或至少同等级别的可靠性检查。
再看OpenAI的ExploitGym事故：测试环境的设置恰好让三者同时具备了——智能体能访问内部资源（私有数据）、被赋予探索性目标（等同于不可信内容的变体）、且拥有外部网络访问能力（对外通信）。所以，这不是踩到了一个全新的未知陷阱，而是撞上了业界早已有共识的红线。
知道红线在哪里，至少能在跨过去之前停顿一下或者犹豫一下，这一下可能就是安全的理性。
五、写在最后：你的AI想过安全吗
不用问AI上次帮你是什么时候，现在我们很多人几乎每天都在手机或者电脑上用各种形式的AI，DeepSeek、KImi、豆包、千问、阿福、Cursor、WorkBuddy 等等，AI已经成了很多人生活、学习和工作中不可或缺的一部分，但是你有没有想过——如果它现在正在犯错，你会不会第一时间知道？
这个问题比听起来尖锐。我们正在把AI嵌入工作流的核心环节：代码生成、数据分析、客户回复、文档撰写。这些场景下，AI的错误并不会立刻显现，但是可能埋在数千行代码中的一个不起眼的函数里，可能在一份报告的数据引用中，可能伪装成一封措辞完美但事实有误的商务邮件。有些可能也不是故意犯错，也可能是“幻觉”，然而等你发现时，代价可能已经翻了几倍。
我不会写"AI很危险、需要禁止"这类空话。作为一个也在搭建AI相关系统的人，作为一个研究AI生态和发展并融入了日常的人，我的想法更具体，也更实际：
"AI的结果"是需要验证的，不能直接复制粘贴或撒手，你需要自己的判断！
这一点尤其重要。AI有一种让人卸下防备的自信语气——它很少说"我不确定"，即使在胡编乱造时也是如此。Replit 的智能体在删掉生产数据库后，坚定的宣称数据无法恢复；Cursor的智能体在执行删除前，逐字确认过安全规则。所以，每当AI告诉你"测试通过了"、"代码没问题"、"数据一致"时，把它当作一个需要验证的陈述，而不是一个已经成立的事实。花五分钟检查，可能省掉五个小时的救火的，当然有时候确实不好验证也是实情，这个需要分开再说。
最后，回到 OpenAI 的故事。OpenAI的安全团队不是新手，他们是世界上最懂AI安全的一批人。他们设计ExploitGym来测试边界，结果测试本身成了事故。这说明AI安全的难度，不是一个"更加小心"就能解决的问题——它需要系统性的设计、制度性的约束，以及持续的警惕。
展望未来，在AI发展的趋势中，这些还只是很基础的安全——"AI会不会替我们做错事"。但还有一个更大的问题一直悬在那儿：我们到底愿意把多少判断力，交给一个自己看不透的东西？我们怎么来验证哪些不太好验证的事项或结论？AI的伦理边界在哪里？