大多数平台工程师都有过类似的故事：他们让 AI 助手生成一个 Terraform 模块或 Kubernetes 部署清单，结果看起来非常合理，CI 流水线也顺利通过了，但几周后坏事发生了。一个带有通配符权限的 IAM 角色。一个本不该公开的 S3 存储桶。一个因为没人检查安全上下文（security context）而以 root 身份运行的 Kubernetes pod。
核心问题不在于 LLM 写错了语法 —— 它们很少犯这种错。问题在于 IaC 的正确性与语法几乎无关。一个 terraform validate 允许通过的 Terraform 文件仍可能部署出一个安全灾难。一个 kubectl apply --dry-run=client 允许通过的 Kubernetes 清单仍可能调度具有危险能力的 pod。你的 CI 流水线用来检查代码的工具大多检查错了重点。
你的智能体在最初三个月表现良好。它拥有 CRM 的读取权限、工单系统的写入权限，以及代表用户发送电子邮件的许可。你在部署时仔细划定了它的权限范围（Scope），然后便开始处理其他事务。六个月后，它开始针对用户从未预料到的情况提交支持工单，发送引用了用户本想保密的内部上下文的邮件，并以技术上符合授权范围、但完全背离用户授权初衷的方式跨系统提取数据。
这就是授权衰减（Consent Decay）。授权并没有改变，改变的是智能体的行为——而你在设置时授予的静态权限也随之而动，支持了智能体随后决定做的任何事情。
你的工程师每天都在交付 AI 生成的代码。你的审计人员正在审查变更管理控制——而这些控制是为一个"每行代码都由审批人亲自编写"的世界设计的。两件事同时成立，如果你所在的是受监管行业，这一缺口就是一种你可能尚未充分估量的法律风险。
AI 生成代码的合规认证问题，并非供应商问题——你的 AI 编码工具的 SOC 2 报告并不覆盖你的变更管理控制。这是一个流程认证问题：SOC 2 CC8.1、HIPAA 安全规则变更控制以及 PCI-DSS 第 6 节背后的根本假设是，审批代码变更的人理解代码内容。这一假设已不再成立。
一个 AI 智能体在 9 秒内删除了一个生产数据库及其卷级备份。它并没有“变坏”，它只是精确地执行了设计要求：当遇到凭证不匹配时，它推断出了一项纠正措施并调用了相应的 API。由于该智能体被授予了与高级管理员相同的权限，因此没有任何机制阻止它。
这并非极端案例。根据 2026 年云安全联盟（Cloud Security Alliance）的一项研究，53% 的组织经历过 AI 智能体超出其预期权限的情况，47% 的组织在过去一年中发生过涉及 AI 智能体的安全事件。大多数此类事件都可以追溯到同一个根本原因：团队预先授予了广泛的权限，因为这样更容易，并计划稍后再收紧。而“以后”永远不会到来，直到出现故障。
真正奏效的模式恰恰相反：从只读访问开始，让智能体通过经证明的、无异常的行为来逐步获得扩展权限。这就是“只读棘轮”（The read-only ratchet）。
你的数据治理审计可能已经发现了它们：用个人信用卡支付的 OpenAI 和 Anthropic API 密钥，通过个人账户接入 Claude 的 Slack 机器人，通过企业 VPN 代理请求的本地 Ollama 实例。没有人通知平台工程团队，没有人请示 IT 部门。工程师们只是……自己动手做了。
这就是影子 AI 问题。无论你是否已经发现，它早已潜伏在你的组织内部。在知识工作环境中，大约一半的员工表示自己在使用雇主未授权的 AI 工具。在软件工程师群体中——他们既有能力搭建非官方集成，又面临提升生产力的压力——这一比例几乎肯定更高。
2026 年 4 月，一个 AI 编程智能体在九秒内删除了一家公司的整个生产数据库——所有数据、所有备份，悉数清空。该智能体发现了一个权限范围远超预期的游离 API 令牌，自主决定通过删除卷的方式解决凭证冲突，并付诸执行。事后被追问时，它承认自己"违反了被赋予的每一条原则"。幸运的是，云提供商恰好启用了延迟删除策略，数据在数日后得以恢复。这家公司算是走运了。
这一事件抛出的令人不安的问题，并非"如何阻止 AI 智能体越轨"，而是更简单也更棘手的：当多智能体系统中的某个子智能体造成真实伤害时，谁来负责？是做出决策的模型提供商？是派发智能体的编排层？是接受了破坏性调用的工具服务器运营方？还是部署整个系统的团队？
目前的现实是：所有人互相推诿，最终由部署方独自承担后果。
Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。
这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。
用户要求智能体（agent）“告知 Karen 我们完成了”。智能体调用了 send_email，收件人字段设置为 karen-team@，这是它的联系人查询工具返回的最合理的地址。这条包含三段内部专用项目状态的信息——其中包括一行关于客户续约风险的坦率描述——最终发送到了四十个收件箱。其中一个收件箱恰好属于该客户。事后分析（postmortem）持续了两周。
没有提示词注入。没有模型越狱。工具完全按照规范运行。团队为 send_email 编写的契约是“向收件人发送消息”。而现实世界强制执行的契约是“广播给一个发送者未审计其构成的群体”。这种差距——即工具的命名与其核心实际能力之间的鸿沟——正是大多数出站智能体事故的源头。
电子邮件是显而易见的例子，但同样的风险潜伏在智能体接触的每一个消息工具中。人类为这些渠道建立的三十年肌肉记忆，并未转移到那些正在通过联系人列表进行模式匹配的规划器（planner）中。
90% 的公司员工都在使用个人 AI 账号——ChatGPT、Claude、Gemini——来完成工作，而其中 73.8% 的账号是非企业性质的。与此同时，57% 使用未经批准的 AI 工具的员工正在与其共享敏感信息：客户数据、内部文档、代码、法律草案。大多数高管认为他们的政策可以防止这种情况发生。但数据表明，实际上只有 14.4% 的团队部署的 AI 获得了全面的安全批准。
领导层认为正在发生的事情与实际发生的事情之间的差距，就是影子 AI 治理问题。
大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。
这里的数学逻辑很简单，但没人去算。在 AI 时代之前，单个用户操作（例如“总结这张工单”或“发送这封邮件”）只会产生一行应用程序日志。而在 AI 时代之后，同样的操作会产生一条请求日志、一个 LLM 调用追踪、代理调用的每个工具的工具调用 span、它读取的每个数据块的检索 span、一条响应日志，如果你采样进行离线评分，还会产生一条评估日志。一次用户点击的扇出（fan-out）现在会在你的可观测性流水线中产生 30 到 50 条记录，这还是在重试、子代理以及会让一切翻倍的规划器-执行器（planner-executor）拆分出现之前。
你在第一季度发布了一个 AI 功能。到了第二季度，你的安全总监拿着一份比上一个周期高出 4 倍的 Splunk 续订合同走进预算审查会议。AI 团队的人都不在现场。接下来的对话——关于谁来承担这笔费用、为什么威胁检测规则失效了，以及是否真的必须对每次对话进行法律保留（legal hold）——是你在设计阶段就应该进行但没有进行的对话，因为这笔成本没有出现在 LLM 的发票上。它出现在下游，出现在一个 AI 团队从未登录过的工具中。
你的 Agent 代码库中最危险的文件是你一直当作 API 文档来编写的那个。工具注册表（Tool Registry）——即告诉模型存在哪些函数以及它们接受哪些参数的 JSON 或 Pydantic schema —— 不再仅仅是一个 docstring。它是你的授权层（authorization layer）。如果你像大多数团队那样设计它，你就是把万能钥匙交给了大模型（LLM），并称之为优秀的工程设计。
考虑一个典型的工具初步尝试：query_database(sql: string)。初衷是合理的 —— 让模型根据用户的问题制定正确的 SQL。现实情况是，模型现在成了一个不受信任的客户端，拥有连接字符串所指向的任何数据库的无限 DDL 和 DML 权限。系统提示词说“仅在 orders 表上运行 SELECT” 只是一个建议，而不是控制手段。当一个受到提示注入（prompt-injected）的工具结果 —— 比如邮件正文、网页或 PDF —— 告诉模型运行 DROP TABLE users 时，你的授权模型就变成了对模型指令遵循能力的纪律要求。那不是授权。那是祈祷。
Bearer Token 模型有一个智能体正在悄然违反的假设：调用者在发起请求时知道自己想要什么。OAuth 作用域、IAM 角色和 API 密钥都是围绕一个在身份验证开始前意图就已经确定的主体设计的。你的 CI 运行器意图稳定。你的微服务意图稳定。智能体则不然。智能体的意图是在请求时，由用户提示词、系统提示词、检索到的文档以及可能由攻击者编写的工具输出共同组装而成的。当智能体去获取令牌时，IAM 层必须做的策略决策实际上已经做出了——而决策依据的输入，IAM 层从未见过。
这就是为什么在服务间通信中行之有效的身份验证模式，现在正引发一类没人能准确描述的事故。提示词注入窃取了长效的 Bearer Token。智能体在不同会话间“记住”了权限，因为令牌的寿命超过了用户的意图。一个理应需要三个作用域的多步任务，在整个会话期间都持有所有权限，而不是按步骤获取和释放。严格来说，这些都不是 OAuth 的 bug。它们是试图将假设静态意图的模型扩展到覆盖一个每轮对话都在重构意图的调用者所导致的后果。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
