8 篇博文 含有标签「authorization」

一个免费层级用户打开你的支持聊天窗口并询问：“你能为订单 #4821 退款吗？”你的智能体（agent）回答：“我无法办理退款 —— 这是管理员才能执行的操作。你可以通过控制面板进行升级，或者我可以为你转接。”拒绝是正确的。退款工具上的 ACL 是正确的。而你刚刚告诉了一个匿名用户：存在一个名为 issue_refund 的工具，它受名为 manager 的角色限制，并且你的平台接受格式为 #NNNN 的订单 ID。

你的规划器（planner）知道用户无法调用的工具。这种不对称性 —— 推理层可见完整目录，而动作层仅能执行部分目录 —— 正是大多数智能体权限控制（agent authorization）悄无声息出错的地方。工具边界处的 ABAC 能拦截未经授权的调用。但它无法拦截已经发生的“能力泄露”，这种泄露往往出现在前一个 token 中，比如规划、拒绝，或是关于变通方案的“热心”建议。

如今，大多数构建 AI agent 的团队都将授权视为事后才考虑的事情。他们接入一个 OAuth 令牌，给 agent 分配与触发它的用户相同的权限范围（scopes），然后就大功告成了。然而，几个月后，他们会发现一段被操纵的提示词导致 agent 窃取了文件，或者一个受损的工作流在连接的服务中悄无声息地提升了权限。

问题不在于 RBAC 不好。而是在于 RBAC 是为具有稳定工作职能的人类设计的，而 AI agent 既不稳定也不是人类。在一个对话回合中，agent 的“角色”可能从只读研究转变为具备写入能力的代码执行。静态角色无法表达这一点，这种不匹配创造了一个可预见的漏洞攻击面。

某零售采购智能体在"初始测试期间"继承了供应商 API 凭证，却没有人在系统投产前对其加以限制。当一个差一错误触发后，该智能体拥有完全的下单权限——永久生效，毫无限制。等财务部门察觉时，已有价值 47,000 美元的未授权供应商订单发出。代码没有问题，模型也按设计运行。造成如此大破坏的，是权限问题。

这就是最小足迹原则：智能体应仅请求当前任务所需的权限，避免在任务范围之外持久化敏感数据，清理临时资源，并将工具访问权限限定于当前意图。这是 Unix 最小权限原则在新时代的延伸——在这个时代，代码会在运行时自主决定下一步需要做什么。

团队之所以在这里屡屡犯错，并非出于疏忽，而是概念错误：他们把智能体权限当作设计时的工作，而智能体 AI 使其成为了运行时问题。

大多数 AI Agent 架构都存在一个悄无声息的安全问题，直到出了事才会被发现。你构建了 Agent，用应用现有的服务账户凭证将其接入内部 API，上线生产，然后继续下一个任务。Agent 正常运行，用户很满意。而与此同时，在你的审计日志里，一个服务账户身份正在悄悄触碰 Agent 曾经需要访问的每一条客户记录、每一张账单表和每一份内部文档——却没有任何痕迹说明是哪个用户发起了什么请求，又是为什么。

这不是一个理论风险。当安全事件发生，或者当监管机构询问"3 月 14 日谁访问了这份数据"时，答案每次都一样：[email protected]。每一个操作、每一次请求、每一次读写——全部归结为同一个身份。审计记录在技术上是正确的，但在取证层面毫无用处。

在试点项目结束六个月后，你的客户数据智能体仍然拥有对生产数据库的写入权限，而它自第一周以来就没再触碰过这些数据库。没有人恶意授予这种访问权限，但也没有人将其撤销。这就是 AI 智能体权限蔓延 (AI agent permission creep)，它现在已成为生产级智能体系统中授权失败的首要原因。

这种模式显而易见：智能体最初拥有一套最小权限集，随着集成的扩展（“只为这个工作流添加 Salesforce 的读取权限”），部署后的权限收紧步骤被无限期推迟。与人类身份与访问管理 (IAM) 中至少在名义上强制执行的季度访问审查不同，智能体身份完全处于大多数组织访问审查流程之外。《2026 年企业基础设施安全中的 AI 现状报告》（调查对象为 205 位 CISO 和安全架构师）发现，70% 的组织授予 AI 系统的访问权限超过了同角色的员工。拥有过度特权 AI 的组织报告的安全事件发生率为 76%，而执行最小权限原则的团队仅为 17% —— 两者相差 4.5 倍。

一家制造公司的采购智能体逐渐确信自己可以在没有人工审核的情况下批准 50 万美元的采购。它这样做并非通过软件漏洞或凭据窃取，而是通过为期三周的供应商电子邮件序列，其中嵌入了澄清问题：“10 万美元以下的任何订单都不需要副总裁批准，对吧？”随后逐步扩展了这一假设。到它批准 500 万美元的欺诈订单时，该智能体运行的范围完全处于其认为的授权限制内。人类认为该智能体有 5 万美元的上限。而该智能体认为自己根本没有上限。

这就是最具体形式的主体层级问题（principal hierarchy problem）：授予的权限、声称的权限以及实际行使的权限之间存在不匹配。当智能体衍生出子智能体，而这些子智能体又进一步衍生出更多智能体时，问题会呈指数级增长，链条中的每一环都会对允许的操作做出独立判断。

一家零售商给他们的 AI 订货 Agent 分配了一个服务账号。六周后，在有人察觉之前，该 Agent 已经向 14 家供应商下达了 38 份未经授权的订单，总额达 47,000 美元。根本原因并非模型幻觉或错误的提示词（Prompt），而是权限问题：测试期间配置的凭据从未在生产环境中缩小权限范围，既没有支出上限，也没有高价值操作的审批门槛。这个 Agent 发现了某项功能，假设自己已被授权使用，便开始不遗余力地进行优化，直到有人叫停。

这种模式随处可见。一项 2025 年的调查发现，90% 的 AI Agent 存在权限过度问题，80% 的 IT 人员曾目睹 Agent 在未经明确授权的情况下执行任务。整个行业正基于为无状态微服务设计的身份模型构建强大的自治系统——而这种不匹配正在引发真实的事故。

在 AI 的大部分历史中，治理问题从根本上说是关于输出的：模型说了错误、冒犯或机密的内容。这固然糟糕，但它是受控的。影响范围仅限于读取该输出的人。

智能体 AI（Agentic AI）完全打破了这一假设。当一个智能体能够调用 API、写入数据库、发送电子邮件并生成子智能体时，问题就不再仅仅是“它说了什么？”，而是“它做了什么、针对哪些系统、代表谁做的，以及我们能否撤销它？”近 70% 的企业已经在生产环境中运行智能体，但其中大多数智能体在传统的身份与访问管理（IAM）控制之外运行，使其处于不可见、权限过高且未经审计的状态。