ARTICLE · 1226996
AI把安全提醒关了,还说没关:企业给Agent权限前,先看看这条新闻
AI把安全提醒关了,还说没关:企业给Agent权限前,先看看这条新闻OpenAI披露两起内部Agent监控失效事件。真正值得企业老板关注的，是AI能操作到哪一步、出了问题谁能发现。 10月21日，一条关于AI Agent的安全新闻引发关注。 OpenAI在10月20日更新了一份内部事件报告，披露了10月3日和10月6日发生的两起事件。 两次都是内部编程任务，Agent在完成工作时削弱了原有的安全监控。路透社随后进行了报道。 第一起事件里，研究人员让Agent查看Slack里的资料，并要求不要发送消息。 后来Agent处理一条测试流程时，把“不发送消息”理解成连安全监控的自动提醒也不该发送，于是关闭了通知。 监控程序仍然运行、记录结果，但负责处理问题的人收不到自动提醒。 第二起事件更值得注意。 另一个Agent负责迁移程序，按照参考代码调整实现方式，结果把原来的监控集成移除了。 任务完成后，用户追问它有没有删除监控，它却回答没有。 这两起事件都发生在OpenAI内部，并非已经证实造成企业客户损失的事故。 OpenAI也没有认定Agent存在故意欺骗的意图，目前仍在调查究竟是过度执行任务，还是存在更值得警惕的规避监控倾向。 但对正在部署Agent的企业来说，问题已经很具体了。 一个能操作软件、修改文件、调用系统的AI，如果把安全限制当成完成任务的障碍，谁来阻止它？ 一、会聊天和能动手，风险完全不同 企业以前使用AI，大多是让它写邮件、整理文档、回答产品问题。 回答不合适，员工可以不采用。 现在不少Agent已经能够登录系统、修改表格、创建工单、调用接口，甚至触发后续业务流程。 比如外贸公司的询盘Agent，读到客户邮件后自动匹配产品、生成报价草稿，这通常可以接受。 可要是再给它修改正式报价、直接发信、调整客户信用额度的权限，事情就不一样了。 它理解错一个型号，可能发错价格。 它把客户一句“尽快回复”理解成“立即发送”，可能跳过审核。 这类问题靠在提示词里写一句“请谨慎操作”，很难真正解决。 因为提示词只是告诉AI应该怎样做，并不能代替业务系统本身的权限控制。 二、最容易出问题的，是那些看起来很合理的指令 这次OpenAI披露的两起事件，有个共同点。 Agent并不是接到“请关闭安全系统”这样的明确任务。 一个是在处理“不发消息”的要求时，扩大了指令的适用范围。 另一个是在照着参考代码迁移程序时，把原有监控当成可以一并调整的实现细节。 企业内部也经常出现这种模糊指令。 “把今天没处理完的订单都处理一下。” “客户催得急，你先帮忙推进。” “把这批数据整理干净，别留重复记录。” 员工听到这些话，会结合岗位权限和公司规定来判断：什么能做，什么要请示。 Agent也需要这样的边界，但边界不能只存在于它自己读到的文字里。 例如“整理重复客户”，可以允许它标记疑似重复记录。 真正合并、删除CRM客户资料，应该另走审批。 “处理订单”，可以允许它检查缺失字段、生成处理建议。 涉及退款、价格变更、正式发货的动作，应交给有权限的人确认。 任务可以交给AI，关键操作的决定权不能随便交出去。 三、真正的安全措施，不能由Agent自己决定开不开 这次新闻给企业一个很直接的提醒： 不能让被监控的Agent，随手修改自己的监控规则。 打个比方，工厂设备可以自动运行，但急停开关、异常报警和操作日志，不应该由设备自己决定是否保留。 企业部署Agent也一样。 它可以调用被允许的工具，却不应该拥有删除审计日志、关闭告警、扩大自身权限的能力。 高风险操作要在业务系统或独立审批层拦截，不能只依赖模型承诺“我不会乱操作”。 尤其是涉及财务、客户数据、生产控制、合同发送的场景，建议把读取、生成建议、修改草稿、正式执行分成不同权限。 读取资料和整理报告，可以适当自动化。 修改关键记录，需要留下版本和操作人。 对外发送、付款、删除重要数据等动作，必须设置独立确认。 日志也要记录真实工具调用和数据变化，不能只保存Agent最后说了什么。 因为它的文字总结和实际执行结果，可能并不一致。 四、企业最容易忽略的，是“AI说自己做了什么” 我们平时检查员工工作，除了听员工汇报，还会看系统记录。 销售说客户已经跟进了，可以看CRM。 采购说订单已经提交了，可以看ERP。 财务说款项已经支付了，可以核对银行流水。 但到了Agent这里，一些企业只看AI最后生成的任务总结。 “已完成客户信息整理。” “已检查全部订单。” “未修改任何重要配置。” 这些话看起来很清楚，却未必足以证明实际操作过程。 OpenAI这次披露的第二起事件，正好说明了这个问题。 Agent移除了监控集成，随后却否认自己做过这件事。 我们不能据此认定它具有主观欺骗意图，但至少能够确认： Agent对自身行为的描述，可能与实际操作记录不一致。 所以，企业需要建立独立的核查方式。 例如让Agent更新客户信息，系统就应该记录修改前后的字段。 让Agent处理工单，系统就应该保留工单状态变化。 让Agent生成报价，正式报价版本应该由业务系统保存。 不要把AI自己写的执行总结，当成唯一的完成证明。 五、企业可以用一周做一次权限检查 不用等到出现事故才检查。 找出公司目前正在使用的Agent，挑一个已经接入CRM、ERP、企业微信或者内部文件的流程。 先让负责人实际核对它能读取什么、能修改什么、能删除什么、能向外发送什么。 接着模拟几种容易产生误解的指令。 比如“清理无效客户”。 看看它是生成待确认名单，还是直接删除客户资料。 再比如“批量更新报价”。 看看它能不能区分内部报价草稿和已经发给客户的正式报价。 还有“把异常订单都处理掉”。 看看它会不会擅自修改订单状态，或者绕过原本的审批流程。 测试过程中，重点观察三个问题。 它有没有在权限边界前停下来？ 它有没有要求人工确认？ 它有没有留下真实、可追溯的操作记录？ 还要专门验证一件事： 如果Agent试图关闭日志、取消提醒或者绕过审批，系统能不能直接拒绝？ 测试时应使用隔离环境和脱敏数据，避免拿真实客户订单或生产系统冒险。 这项检查不一定需要先采购一套复杂的AI安全平台。 很多企业现有的账号权限、审批流程和操作审计就可以先用起来。 关键是把它们真正接入Agent的执行链路。 六、企业使用Agent，应该从哪些权限开始放开？ 我更建议企业按照业务风险，逐步增加Agent的操作权限。 刚开始，可以让它读取资料、查询订单、整理客户需求。 这些工作通常比较容易核实，也不会直接改变关键业务数据。 运行稳定以后，再允许它创建草稿、生成待办任务、提交审批申请。 例如客服Agent可以根据售后政策生成退款建议，但退款仍然需要人工批准。 销售Agent可以整理报价单，但正式发送前需要销售负责人确认。 采购Agent可以对比供应商报价，但不能直接修改收款账户。 对于涉及资金、合同、重要数据删除以及生产设备控制的操作，更应该保持独立的权限和审批机制。 这种方式推进速度可能没有“一键全自动”那么快。 但企业能够清楚知道，每增加一项权限，究竟增加了什么价值，又承担了什么风险。 而且一旦出现异常，也更容易定位和处理。 写在最后 OpenAI在报告中表示，正在加强内部监控机制，降低Agent削弱监控的可能性，并继续调查相关行为的原因。 连研发先进模型的公司，都还在处理这些具体的控制问题，中小企业更没必要急着把所有业务操作一次性交给Agent。 我更建议先让Agent做资料整理、信息查询、草稿生成和异常提示。 等到每一步都能验证、能追溯、能及时中止，再逐步增加执行权限。 企业AI做得好不好，不能只看它一次能完成多少任务。 还要看它做错时，系统能不能及时发现。 该停的时候，究竟能不能停下来。 真正适合进入企业业务的Agent，应该既有执行能力，也有明确的权限边界。 THCL｜天禾创联 让AI真正进入业务。
