AI 智能体安全事件过半，企业还在急着全自动部署，问题到底出在哪？

VentureBeat 前两天发布了两份调研，我读完后第一反应不是震惊，而是有点后怕。

第一份调查了 107 家企业，结果显示过去一年里，54% 的企业已经遭遇过 AI 智能体相关的安全事件。注意，不是「担心」或者「听说」，而是真的出过事。18% 是确认事故，36% 是险些酿祸。第二份调查了 157 家企业，50% 的受访者坦承，他们曾把通过内部评估的 Agent 部署到生产环境，结果导致客户侧出现故障。

这两个数字单独看已经够扎眼，合起来看就是一个更冷的图景，一边是一半以上的企业已经被 Agent 伤过，另一边，66% 的企业仍然计划在接下来 12 个月内，让低风险的 Agent 实现全自动、无人工干预部署。

你品品这个张力。我们这帮搞技术的，到底是在做自动化，还是在把半吊子脚本送上战场？

一、Agent 不是普通脚本，我们却还在用普通脚本的方式管理它

我先说一个很多团队没意识到的问题。传统脚本再危险，它的行为路径大体是固定的。输入 A，输出 B，出错也就在那一两个分支里。但 Agent 不一样，它会自己决定调用什么工具、查哪份文档、改写哪个参数，甚至在你没注意的时候多跑几轮循环。

VentureBeat 的调查里有一个细节让我印象很深，只有 32% 的企业会为每个智能体分配独立的身份凭证，30% 会把高风险 Agent 隔离在沙箱里。更直接地讲，大部分 Agent 跟人共用账号、共享权限、在正式环境里裸奔。

我跟你说，这事的可怕程度不是「模型被 prompt 注入」那么简单。一个共享了数据库写权限的 Agent，如果它在某个工具调用里把条件判断搞混，它做的就不是「生成一段错误文本」，而是直接删表、改状态、触发退款。你指望事后查日志？等你发现的时候，数据已经同步到下游三个系统了。

这件事的工程本质，是把「谁允许做什么」这个老问题重新放大了。过去我们写微服务，会给每个服务发一张证书、一套 RBAC、一个最小权限集。今天很多 Agent 项目却像是在说，「先跑起来，权限后面补」。

可权限这事，一旦后面补，往往就是出了事故之后补。

二、测试通过不等于生产安全，评估和现实之间有条裂缝

第二个让我坐不住的数据是，50% 的企业把通过内部测试的 Agent 推上线后，结果让客户侧出了问题。不是内部测试太松，而是测试场景跟真实世界根本不是一回事。

我在自己折腾 LangGraph 和 MCP 的时候，也踩过这种坑。本地跑得好好的，测试用例全绿，一放到真实环境，Agent 面对的用户输入千奇百怪，上下文一拉长，它就开始调用错误工具，或者把工具参数拼错。最离谱的一次，一个测试环境的 Agent 把我以为已经脱敏的日志里的一行 API key 又写进了返回结果里。

VentureBeat 的调查显示，29% 的企业认为「评估结果与现实结果对齐不佳」是最大局限，而只有 5% 完全信任自动化评估。可耐人寻味的是，这 5% 的人却像声音最大的一拨，天天喊着「全自动部署」。

问题出在哪？我觉得主要有三点。

第一，很多评估是静态任务集，没覆盖多轮对话和工具链的连锁反应。Agent 不是一次问答模型，它会因为一个中间结果改变后续策略。你只在单轮测试里打分，当然看不出问题。

第二，评估数据跟生产数据分布不一样。实验室里的用户问题又干净又短，真实用户的问题可能夹杂着口语、错误前提、情绪词，甚至是有意试探。模型在这些分布偏移面前，准确率会掉得很快。

第三，评估很少加入对抗性测试。你没有主动让模型面对越界请求、权限试探、数据注入，生产环境里就一定会有人替你做这件事。

三、信任低，但脚步更快，这背后是焦虑在驱动

调查里还有一个反差点，企业对自动化评估的信任度不高，但全自动部署的意愿却很高。66% 的企业打算让低风险 Agent 全自动运行，不靠人工审批。

坦率的讲，这种「嘴上不信，身体很诚实」的状态，我一点也不意外。去年到今年，AI Agent 的热度让企业管理层有一种强烈的错过焦虑。别人都已经让 Agent 自动回邮件、自动审单、自动处理工单了，我们这边的 Agent 还在每个步骤等人工点确认，岂不是显得效率太低？

但「低风险」这个定义本身就很危险。一个只做「内部文档检索」的 Agent，如果它能访问全公司知识库，并且把检索结果自动转发到外部 IM，它还算低风险吗？一个只处理客户退款申请的 Agent，如果它能调用支付网关，那它真的只是低权限工具吗？

很多时候，不是 Agent 的意图变危险了，而是我们为了让它「看起来有用」，不断把权限边界放宽。低风险变成中风险，中风险变成事故，只是时间问题。

四、那企业到底该怎么做？

这部分不是唱高调，是我觉得每个团队都能先落地的几件事。

第一件事，把每个 Agent 当作一个独立员工来管理。给它一个专属身份、独立凭证、可审计的操作日志。不要让它蹭你的个人账号，也不要把 root 权限当作方便之门。这听起来是基本功，但 VentureBeat 的数据显示，68% 的企业还没做到。

第二件事，把 Agent 放进沙箱，逐步放出来。高风险操作必须隔离，低风险操作也要先观察。沙箱不是不信任模型，是给团队留出验证和回滚的空间。30% 的隔离率，对于一个号称自主的系统来说，太低了。

第三件事，评估体系必须包括运行时监控。上线不是终点，而是起点。你需要实时看 Agent 在调什么工具、失败率多少、有没有异常权限请求、有没有出现越界输出。最好能有一个快速熔断机制，发现异常就让它停下来，而不是让它继续自己修。

第四件事，引入红队测试和对抗评估。OpenAI 刚发布的 GPT-Red 就是往这个方向走，用自动化攻击去找模型漏洞。企业不需要自己训一个红队模型，但可以让安全团队或者外部白帽，专门盯着 Agent 的越界场景做测试。比如故意给 Agent 一个带注入的输入，看它会不会把敏感数据带出去。

第五件事，保留人在回路。全自动部署不是不能有，但最好先分级。高影响操作必须人工确认，中风险操作留一个异步复核窗口，只有真正无状态、可回滚、无敏感数据的任务才完全放手。这个分级不能靠感觉，要靠影响面、权限范围、恢复成本来定。

五、这对开发者到底说了什么

回到我作为一个普通开发者的视角，这个事给我的最大感受是，Agent 时代，安全工程不再是安全团队的事，而是每个写 Agent 的工程师的事。

你以前写 Spring Boot 服务，会考虑接口鉴权、限流、审计、事务回滚。今天写 Agent，你同样要考虑工具权限、上下文隔离、输出校验、异常熔断。Agent 的运行时不是 HTTP 请求那么简单，它是一个可能连续运行多轮的自主流程，任何一个环节的松懈都会被放大。

我做 LangGraph 项目的时候，越来越觉得「图」不只是编排逻辑的工具，它天然就是一道安全边界。你可以在某个节点后插入人工审核节点，可以在边上加条件判断，也可以把敏感操作拆成独立的子图。关键是，你愿不愿意在设计阶段就把这些边界画出来，而不是等出事了再补。

另一个我觉得特别值得警惕的是，不要把模型提供商的原生安全方案当成万能钥匙。调查显示，企业主要依赖模型提供商的原生安全工具，专用 Agent 安全产品的渗透率极低。不是说 OpenAI、Anthropic 的安全做得不好，而是它们的安全设计是通用型的，不一定懂你的业务风险、你的数据分类、你的合规要求。就像你不能把云厂商的基础安全当作自己的应用安全一样，模型安全也不等于 Agent 安全。