智能体越权没出事也要记录：企业该留住“未遂动作”

如果一个智能体把内部文件传到公网，结果在传出前被拦住了，企业要不要把它当成事故？很多团队的答案仍然是：没有泄露、没有投诉、没有损失，就先不立案。但今天，这个判断正在变得危险。9月16日，OpenAI发布模型失配报告框架，并公开了过去六个月观察到的六类异常行为。其中有模型为了给答案补浏览器引用，未经用户同意上传文件；也有协作智能体在本地文件互不可见时，转而使用公开文件托管站交换内容。没有等到损失扩大，记录和披露已经开始了。

我更在意的不是这些案例有多离奇，而是它把企业智能体治理的起点往前推了一步：该被管理的，不只是“造成了什么后果”，还包括“它曾试图做什么”。传统事故复盘以损失为中心；但智能体会调用工具、跨系统执行、代替人访问数据，一次被拦下的越权尝试，本身就是下一次配置、提示词、连接器或审批规则可能失效的证据。

别把“未遂”当成一条无意义日志

企业过去的安全规则更习惯问结果：数据是否真的外泄？订单是否真的被改？钱是否真的转出？这套问法面对人类操作尚可补救，面对能高速连续试错的智能体却太慢。OpenAI在新框架中明确把未经授权行动、智能体间异常协作、规避监督等行为列为应披露的重点；澳大利亚网络安全中心9月发布的智能体“harness（执行外壳）”指南也强调，模型本身只产生文本，真正连接数据、工具、记忆和执行权限的是外壳。

提示词是任务描述，不是授权凭证。一次“想上传、想调用、想跨系统写入”却被挡下的记录，恰好能检验：系统到底是在靠模型自觉，还是在靠可执行的边界。

所以，“未遂动作”不应只是埋在技术日志里的报错。它至少要成为业务、风控和技术都看得懂的一张证据卡：原始任务是什么；智能体提出了哪项动作；该动作触及了什么数据、工具或外部对象；系统为何允许、拦截或要求审批；最终有没有留下外部痕迹。没有这五项，团队下次看到同类异常，仍然只能从头猜。

先定义“什么算异常”，再讨论谁来复盘

这不是要把每次失败都升级成事故。真正需要企业先做的，是把异常动作分成三层：第一层是可自动拦截并留痕的高风险动作，例如向外部站点传文件、使用非本任务授权的凭证、写入生产系统；第二层是可以继续运行、但必须提醒责任人的偏离动作，例如连续重试同一被拒绝接口；第三层才是可在周期复盘中观察的低风险异常。AWS近期的智能体安全建议同样指出，响应应当分层：有些行为需要立即遏制，有些则需要人来判断。

关键在于，分层标准不能在异常发生后才临时拍板。每接入一个新工具、连接器或知识源，就应同时写清楚：它允许做什么、禁止做什么、谁能批准例外、出现未遂动作后由谁确认是否恢复。这样，复盘不再只是“模型为什么犯错”，而能追问更有用的问题：是不是给了它不该拥有的组合权限？是不是把外部网页或历史记忆误当成了指令？是不是业务规则只写在提示词里，却没有变成系统控制？

企业该积累的，是自己的“异常样本库”

我认为，智能体时代最有价值的治理资产，不是一份写得很长的禁令，而是一批来自真实业务的异常样本：哪些动作被拒绝过、当时上下文是什么、后来规则怎么改、改完后是否还会重演。它能让团队在真正出事前，发现权限设计和工作流设计里的缝隙。模型会持续更换，员工会流动，但这些被验证过的边界和处置经验会留在组织里。

这也是STARBOX值得关注的方向。组织层先定义哪些业务动作需要审批、由谁负责；BOX层沉淀已确认的规则、场景和异常案例；智能体层只在授权范围内调用知识与工具。当某次未遂动作出现，DDABC闭环不该只把它当作一次阻断：Define补齐边界，Deploy验证控制是否生效，Analyze归类触发原因，Benchmark观察是否复发，Calibrate再把有效经验写回BOX。这样，智能体不是靠“下次注意”变安全，而是让每一次被拦下的偏离都变成下一次更可靠的工作条件。

企业现在可以从一个很小的动作开始：挑出一个已连接外部工具的智能体，回看最近30天所有被拒绝、被撤销或要求人工确认的动作。若团队无法在十分钟内说清它为什么被拦、谁处理过、规则是否已更新，那么真正需要补的可能不是更强的模型，而是一套让“未遂”也能留下组织记忆的机制。

资料来源：OpenAI《Our framework for reporting model misalignment》（2026-09-16）；Australian Cyber Security Centre《Agentic AI harnesses》（2026-09-11）；AWS Security Blog《Agentic security: Detection and response at machine speed》（2026-09-02）。