Agent权限分层：为什么仅靠RBAC远远不够

Agent就像一位失忆的超人——拥有强大能力，却不记得自己是谁、能做什么。给它一个宽泛的服务账号，它就能读取HR记录、发送客户邮件，甚至起草解雇信。问题不在于Agent本身，而在于我们错误地将人类权限模型直接套用在了Agent身上。

一个真实的故事

Marcus给Agent分配了一个服务账号，因为觉得RBAC配置“太麻烦”——那些权限在他2019年创建集成用户时就绑定了。结果Agent可以读取HR记录、写工单、发客户邮件。当Agent为错误的员工起草了解雇信并发送给了错误的管理者时，没有人能弄清楚它是如何获得这些权限的。

这个场景揭示了核心问题：**Agent会放大你随意附加的任何权限。**一个拥有广泛权限的人类会运用判断力，而一个拥有广泛权限的Agent只会执行概率——概率并不知道哪些操作是不可逆的。

为什么RBAC对Agent失效

RBAC为人类设计，假设了判断力和问责制。但Agent不是用户，它们通过用户意图行动。传统RBAC问的是：“这个用户能访问HR系统吗？”而权限分层问的是：“这个Agent能在这个小时、针对这类工单、在不发送的情况下起草内容吗？”

“所有旧有的建议都假设你是人。你不是。你是概率。”——Avthar Sewrathan

这种根本性差异意味着，仅仅依赖RBAC会让企业面临巨大风险。Agent需要多层防护，而非单一权限模型。

RBAC（Role-Based Access Control，基于角色的访问控制）诞生于20世纪90年代的多用户操作系统与企业信息系统环境，其核心思想是：先定义角色（如"HR专员""财务经理"），再把权限绑定到角色，最后将角色授予用户。这套模型隐含三个前提：主体身份长期稳定、权限边界由组织制度保障、主体会对自己的行为负责。当主体是Agent时，这三个前提全部动摇——Agent的"角色"往往是从人类集成账号继承而来，其生命周期只持续一次会话，且它没有动机去判断一个操作是否合规。这正是RBAC在Agent场景下失效的根本原因。

最小权限原则（Principle of Least Privilege）由Jerome Saltzer于1974年提出，要求任何主体只应获得完成当前任务所必需的最小权限集合。在人类场景中，这一原则依赖岗责分离和定期审计来落地；但在Agent场景中，权限往往在配置阶段一次性授予，运行阶段却缺乏动态收窄机制，因此必须借助身份、工具、数据、动作四层结构来重新实现这一原则。

四层必需权限架构

要真正实现最小权限原则，Agent需要以下四层防护：

层级	回答的问题
身份层	谁发起了这次运行？每个动作都归属于人类+Agent+会话ID
工具层	这个API在允许列表上吗？由网关集中执行，而非每个Agent自行配置
数据层	哪些行在范围内？行级过滤器按请求注入
动作层	读取、起草还是发送？不可逆操作排队等待人工审批

缺少任何一层，你得到的都不是最小权限，而是一个拥有生产密钥的演示账号。

核心实施建议

• 工具网关：通过MCP或代理集中执行允许列表
• 行级过滤器：按请求注入，而非寄希望于提示词中声明
• 发送/删除人工门控：不可逆操作排队等待审批
• 全面审计：权限拒绝是信号，不是噪音

MCP（Model Context Protocol，模型上下文协议）是Anthropic于2024年底推出的开放协议，用于标准化大模型与外部工具、数据源之间的交互方式。它定义了一套客户端-服务器架构：Agent作为客户端，工具提供方作为服务器，双方通过JSON-RPC交换能力描述与调用请求。MCP的价值在于把"工具允许列表"下沉到协议层，使网关能够统一看见并拦截每一次工具调用，而不依赖每个Agent框架自行实现权限检查。

行级过滤器（Row-Level Filtering）是数据库与数据仓库中的成熟机制，比如PostgreSQL的Row-Level Security、Snowflake的Row Access Policy。它的关键特征是在查询执行层强制注入WHERE条件，而非由应用层或提示词自行声明范围。把行级过滤器与Agent会话绑定后，即便Agent被诱导构造恶意查询，数据库也会基于会话上下文自动收窄返回行集，这是数据层防护真正可验证的原因。

构建权限回归测试

权限测试应该和功能测试一样重要。Marcus的团队现在在CI中运行权限测试套件：二十个场景验证Agent无法自行提权、无法访问会话边界之外的数据、无法派生拥有更广权限的子Agent。

具体做法包括：

• 默认拒绝：新工具默认禁用，直到安全团队签字
• 即时提权：写权限在运行时请求，一次性批准
• 破窗账号：有记录、罕见、响亮记录
• 定期重新认证：每季度审查Agent还能做什么

事件响应与权限审计

当Agent发错邮件时，你需要在几分钟内完成终止开关、会话撤销和取证追踪。像钓鱼演练一样练习Agent事件响应：模拟、测量响应时间、修复缺口。

权限拒绝是策略的训练数据——被拒绝的写尝试激增意味着Agent配置错误或正在遭受攻击。每周仪表盘审查拒绝记录，每个被阻止的工具调用都记录原因代码。

终止开关（Kill Switch）与会话撤销（Session Revocation）在Agent架构中并非简单的"删除账号"，而是需要同时完成三件事：使当前会话的所有派生凭证立即失效、中断正在排队等待批准的动作、冻结该会话可访问的数据范围。这要求身份层发放的是会话绑定的短期凭证（如带TTL的OAuth Token或STS临时凭证），而不是长期服务账号密钥。

取证追踪（Forensic Tracing）则依赖意图链的完整记录：每个动作必须同时记录发起的人类身份、Agent身份、会话ID、调用的工具、访问的数据行以及最终决策原因代码。缺少任一环节，事后重建"Agent为什么发错邮件"就会变成不可能完成的任务。Avthar Sewrathan提到的"概率主体"正是需要通过这种强记录来约束。

共享服务账号 vs 分层权限

维度	共享服务账号	分层Agent权限
爆炸半径	全组织范围	按运行范围限定
撤销	破坏多个应用	会话绑定，自动失效
审计	“机器人干的”	可追溯的意图链

共享服务账号是有生产密钥的技术债务——Agent每天都在倍增这笔债务。

团队协作与审查

安全、数据所有者和产品团队应每季度共同审查Agent权限范围。权限蔓延是渐进的——一个“临时”写权限会变成永久权限，除非有人审计注册表。

当Agent配置变更时，在PR模板中添加权限差异对比——就像防火墙规则一样。审查者在合并前就能看到范围扩展，而不是在事件回顾中才发现。

实践建议

选择一个失败成本足够高的工作流，用明确的指标运行三十天。如果数字改善，就扩展；如果毫无变化，你以极低成本学到了经验。

前沿能力如今已是商品，运营成熟度才是护城河。记录你交付了什么、拒绝了Agent什么、什么出了问题。这份日志会比任何供应商演示更快成为你的内部剧本。