安全为什么总是被绕开

当 AI 开始替人执行，企业真正要重新决定的，是把摩擦放在哪里

2023 年 4 月，三星电子半导体部门的几名工程师把内部源代码和会议记录粘贴进了 ChatGPT。几周后，公司向其中一个最大事业部下发内部通知，禁止在公司设备和内网上使用生成式 AI 工具，并写明违规可能导致纪律处分直至解雇。彭博社看到的那份通知里还提到，公司此前的内部调查中，65% 的受访者认为这类服务存在安全风险。

这件事通常被当作一起数据泄露来讲。但更值得追问的是另一半：那些工程师并非不知道风险，调查数据说明大多数人都知道。他们仍然那样做了，因为把代码贴进对话框，比走内部流程快得多。

禁令处理了工具，没有处理这个落差。而落差才是问题本身。

安全曾经可以是“额外一步”

过去二十年，企业安全的基本形态是在业务流程之外再建一条路径：写完代码去另一个平台扫描，填完付款信息再到审批系统重填一遍，做完变更补一份操作记录，用一个新工具先申请权限再等管理员处理。

这种设计能成立，是因为它匹配人的工作节奏。一个财务人员一天处理十笔付款，逐笔核对是可行的；一个管理员一周做几次变更，人工确认不构成瓶颈；一个开发者一天提交几次代码，等扫描结果不算难忍。安全占用的时间被摊薄在低频操作里，看起来只是"多花几分钟"。

但摩擦从来不是按单次计算的。当同样的动作每天重复几十次、上百次，使用者就会开始寻找更短的路径：把文件转到私人聊天工具，共用账号，先执行后补审批，在测试环境绕过检查再把配置复制到生产。

这些行为不需要恶意，只需要一个前提：安全在正常工作路径之外。

只要安全是一条额外路径，业务就会持续寻找绕开它的捷径。

2022 年 9 月，Uber 的内部系统被入侵。根据 Uber 自己发布的安全通报，攻击者从暗网买到一名外部承包商的账号密码，反复尝试登录，多因素认证一次次弹出、一次次被拒绝。攻击者随后在通讯软件上冒充 Uber 的 IT 支持，告诉对方通过一次就不会再收到提示。承包商点了同意。攻击者由此进入内网，进一步拿到多个内部工具的权限。

多因素认证在这里没有失灵，它精确地执行了设计：把判断交给人。问题在于，当同一个判断被重复几十次、且绝大多数时候都无关紧要时，人就不再在做判断，而是在处理骚扰。

这不是个别人的疏忽。任何把安全寄托于"每次都认真看一眼"的机制，都在消耗一种会枯竭的资源。审批者连续面对上百条形式相似的请求时，"审批"会退化成点击——流程记录上仍然有人参与，实质上判断已经消失。

很多安全机制不是被攻击者突破的，而是先被正常使用者绕开的。

2012 年 8 月 1 日，美国做市商骑士资本（Knight Capital）部署一套交易路由系统的更新时，有一台服务器没有更新到位，遗留的旧代码被意外激活。在开盘后的 45 分钟里，系统在处理 212 笔客户委托的过程中向市场发出了四百多万笔订单，成交约 3.97 亿股，公司亏损超过 4.6 亿美元。SEC 在此后的处罚文件中给出的判断很直白：在缺乏适当控制的情况下，自动化系统进入市场的速度，会把一个本来可控的错误变成极端事件。

这个案例的价值不在于金额，而在于它标注了一条分界线。人的错误是零散的，系统的错误是复制的。同一个逻辑缺陷，在人工操作里表现为偶发失误，在自动执行里表现为持续输出。

AI Agent 把这条线又向前推了一段。2025 年 7 月，投资人 Jason Lemkin 在使用 Replit 的编码 Agent 时，明确下达了"代码冻结、不得改动"的指令。九天后他发现，Agent 仍然删除了生产数据库中一千二百多名高管和一千一百多家公司的记录。Replit 首席执行官 Amjad Masad 公开承认这"不应该可能发生"，随后推出的措施是结构性的：开发与生产环境自动隔离、只做规划不执行的对话模式、一键回滚。

注意这个修复方向。它没有加强提示语的措辞，也没有要求用户更谨慎，而是把"不能发生"写进了系统本身。因为 Agent 不会像人那样，在执行前突然想起该去开一个安全工具检查一下。

当执行速度发生数量级变化，安全就不能继续依赖人类速度。

传统安全体系的重心在入口：谁登录了，谁有权限，谁发起了请求，谁签了字。这些问题依然重要，但它们回答不了 AI 时代的关键部分。

Replit 的 Agent 拥有合法权限。Knight 的部署经过了正常流程。Uber 的那次登录通过了多因素认证。每一步的身份都是对的，结果仍然是错的。

原因在于，授权发生在动作之前，而条件在动作发生时。一个通过审批的操作，可能在等待执行期间环境已经变化；一个合法生成的请求，可能带着错误的参数、金额或目标账户；一个符合单条策略的动作，可能因为多套规则叠加而产生谁都没预期的后果。

身份正确不等于意图正确，获得授权不等于结果安全。

所以安全的落点必须后移——从"这个人有没有资格发起"，移到"这件事在当前条件下能不能真正落地"。这不是给旧机制加一层，而是换一个提问方式。前者是准入问题，后者是执行问题。

摩擦不该消失，该被重新分配

真正成熟的做法不是消灭摩擦。陌生账户的大额付款、生产环境的核心变更、不可逆的数据删除，本来就不该和发一条消息一样容易。

问题是绝大多数传统体系对所有操作一视同仁：无论金额大小走同一套审批，无论风险高低弹同样的警告，无论是否可逆经过同样的流程。结果是低风险操作被过度阻拦，高风险操作淹没在形式化检查里——两头都没做好。

2017 年 2 月 28 日的 AWS S3 故障提供了一个反向样本。一名获授权的工程师按既定手册执行下线少量服务器的命令，其中一个输入参数写错，被移除的服务器远超预期，导致美东区域大面积中断数小时。AWS 在事后说明中给出的整改不是加强培训或增设审批，而是修改工具本身：让容量移除变慢，并加入防护——当一次操作会使任何子系统低于最低容量要求时，系统直接拒绝执行。同时，他们审查了其他运维工具是否具备同类检查。

这是把摩擦放在了正确的位置。日常操作不受影响，只有跨过阈值的那一类才被挡住。

好的安全不是没有摩擦，而是只在风险真正出现时制造摩擦。

这个问题最终不是技术问题，而是责任问题。

2024 年 2 月，加拿大不列颠哥伦比亚省民事解决法庭在 Moffatt 诉加拿大航空一案中作出裁决。乘客根据航司网站聊天机器人的说法购买了全价机票，事后申请丧亲折扣被拒。加航辩称聊天机器人应被视为独立主体，法庭驳回了这一主张，认定加航对其网站上的信息负有注意义务，构成过失性虚假陈述。

模型的输出可以出错，但责任不会随之外移。这意味着企业的董事会和管理层面对的不是"AI 好不好用"，而是"当它错了，我们凭什么说自己尽到了义务"。

于是问题回到了执行路径上。如果安全控制本身就在执行链路里，系统就能连续记录：请求从哪里产生，调用了哪些工具，经过了哪些策略，谁提供了授权，执行时条件是否满足，为什么被允许或被拒绝。这条记录的第一用途不是追责，而是扩权——企业只能从低风险场景开始，用运行证据换取更大的授权范围，先设低额度，再根据真实数据调整边界。

没有执行证据，自动化只能依赖信任；有了执行证据，信任才可能变成制度。

这也解释了为什么很多企业的 AI 项目卡在试点阶段。卡住它们的往往不是模型能力不足，而是没人能回答一个朴素的问题。

企业担心的不是 AI 不够聪明，而是当它判断错误时，有没有东西能挡住它。

回到三星那几名工程师。他们的选择在任何一家公司都会重复出现，因为它符合一种普遍的理性：在两条都能完成工作的路径中，选更短的那条。

指望每个人永远谨慎，或者每个模型永远正确，都不是可执行的方案。可执行的方案只有一种：让正常工作的那条路径本身就是安全路径，把边界写进系统，把拒绝能力留在结果发生之前。

中国人说磨刀不误砍柴工。这句话的重点从来不是"磨刀"，而是"不误"。如果所谓的准备只是让人不断停下来、反复填表、来回切换系统，那不是在磨刀，是在斧头上加重量。

参考资料

• Bloomberg, "Samsung Bans ChatGPT, Google Bard, Other Generative AI Use by Staff After Leak", 2023年5月2日

• Uber Newsroom, "Security update", 2022年9月（含9月16日与19日更新）

• U.S. SEC, "SEC Charges Knight Capital With Violations of Market Access Rule", 新闻稿 2013-222，2013年10月16日

• Amazon Web Services, "Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region", 2017年3月

• Fortune, "An AI-powered coding tool wiped out a software company's database"，2025年7月23日；Fast Company 对 Replit CEO Amjad Masad 的专访，2025年7月22日

• Moffatt v. Air Canada, 2024 BCCRT 149（不列颠哥伦比亚省民事解决法庭，2024年2月14日）