一个人类员工一天审批 20 单、发 50 封邮件、访问 10 个系统。如果权限有漏洞，损害上限是 20 单。
一个 Agent 一秒调 100 次 API。如果权限有漏洞，损害上限是 10000 单。
这不是量变，是质变。传统权限模型（RBAC / ABAC）有一个隐含假设： 操作者是人，操作速度是人的速度。 这个假设在 Agent 时代彻底失效了。
再加上三个新问题：委托链（人委托 Agent A，A 调用 Agent B，B 访问系统 C）、上下文依赖（同一个 Agent 在不同群里有不同权限）、可被操纵（Agent 可能被 prompt injection 劫持）——传统权限模型不是「需要升级」，而是 需要重新设计。
为什么传统权限不够用
RBAC（基于角色的访问控制）的逻辑是：人 → 角色 → 权限。你是「财务总监」角色，所以你有「审批采购」权限。
这个模型在 Agent 时代遇到四个结构性问题：
| 问题 | 传统假设 | Agent 现实 |
|---|---|---|
| 速度 | 人一天做 50 个操作 | Agent 一秒做 100 个操作 |
| 委托链 | 人直接操作，没有中间层 | 人 → Agent A → Agent B → 系统 C |
| 上下文 | 权限是静态的（角色决定） | 权限是动态的（场景决定） |
| 可操纵性 | 人不会被一段文字骗去执行恶意指令 | Agent 可能被 prompt injection 劫持 |
第一个问题意味着：权限检查的 **性能 和 粒度 **都要重新设计。你不能像检查人的权限那样，每次调用都走一遍完整的 RBAC 查询——100 QPS 下这会成为瓶颈。
第二个问题意味着：权限不是「这个 Agent 能做什么」，而是「这个 Agent 在这个委托链上能做什么」。委托链越长，权限应该越窄。
第三个问题意味着：同一个 Agent，在运营群里能看销售数据，在财务群里不能。权限不是绑在 Agent 身上的，是绑在 **场景 **上的。
第四个问题意味着：权限系统必须假设 Agent 可能被劫持。即使 Agent 的推理逻辑被恶意篡改，权限层也要能兜住——权限是最后一道防线，不能依赖 Agent 的「善意」。
五层信任架构
我把 Agent 时代的权限拆解为五层，从底到顶：
L5 审计（Audit） ← 你做了什么
L4 凭证（Credential） ← 你怎么证明
L3 委托（Delegation） ← 你替谁做
L2 权限（Permission） ← 你能做什么
L1 身份（Identity） ← 你是谁
每一层解决一个独立的问题，层与层之间是 递进依赖——没有身份就没有权限，没有权限就没有凭证，没有凭证就没有审计。
L1：身份——你是谁
Agent 必须有 独立身份，不是寄生在人的账号下。
AgentIdentity {
agent_id: "agent://sales-report-001"
type: agent
owner: "user://zhang-san" # 谁创建的、谁负责
org_id: "org://acme-corp"
created_at: "2026-07-01"
expires_at: "2026-12-31" # 生命周期
status: active | suspended | revoked
}
# generated by hugo AI
比人的身份多两个关键字段：
- owner：谁为这个 Agent 的行为负责。Agent 出了事，追溯到人。不是「AI 做的」就完了——是谁创建的、谁授权的、谁在监督
- expires_at：Agent 身份有过期时间。不是「创建了就永远在」。离职的人，他的 Agent 应该自动失效。过期的 Agent 需要重新审批才能续期
我在 当 Agent 有了工牌 中详细讨论过 Agent 身份的设计：Agent Registry 负责注册、Agent Proxy 负责凭证边界、Access Bundle 负责场景化权限。本文在此基础上补齐委托链和审计层。
L2：权限——你能做什么
传统 RBAC 是「角色 → 权限」的静态映射。Agent 时代需要 场景化权限：
Permission {
agent_id: "agent://sales-report-001"
scope: {
context: "group:ops-team" # 在哪个场景下
resource: "crm:customer-data" # 能访问什么
actions: ["read", "write"] # 能做什么
constraints: {
max_amount: 50000 # 金额上限
regions: ["east-china"] # 地域限制
time_window: "09:00-18:00" # 时间窗口
}
}
granted_by: "user://li-si" # 谁授权的
granted_at: "2026-07-01"
expires_at: "2026-10-01"
}
# generated by hugo AI
关键设计： 同一个 Agent 在不同场景下有不同的权限。
一个销售 Agent：
- 在销售群里：能读写 CRM、能查看客户数据、能发报价
- 在财务群里：只能读审批状态，不能看具体金额
- 在全员群里：只能发通知，不能访问任何业务数据
这就是 Access Bundle——按群/场景打包权限。不是「这个 Agent 有什么权限」，而是「这个 Agent 在这个场景下有什么权限」。
在 Agent 是一等公民 中，我讨论了通讯录里的 Capability 字段。Capability 是「能做什么」的声明，Permission 是「被允许做什么」的约束。两者取交集才是 Agent 实际能做的事。
L3：委托——你替谁做
这是 Agent 权限最独特的一层。人不需要委托——人用自己的身份做事。Agent 必须声明 它替谁行动：
Delegation {
agent_id: "agent://sales-report-001"
delegator: "user://zhang-san" # 委托人
scope: {
actions: ["send_email", "update_crm"]
max_amount: 100000
valid_until: "2026-08-01"
}
revocable: true # 委托人随时可以撤回
audit_level: "full" # 审计级别
}
# generated by hugo AI
委托链的核心规则：权限取交集，不取并集。
张三（权限：审批 100 万以下）
→ 委托 → 销售 Agent（权限：审批 50 万以下）
→ 调用 → 数据 Agent（权限：只读）
→ 访问 → CRM
销售 Agent 的权限不能超过张三的权限。数据 Agent 的权限不能超过销售 Agent 的权限。 委托链越长，权限越窄。
这解决了一个关键安全问题： Agent 不能通过委托链提权。 一个只有读权限的人，不能通过委托一个 Agent 来获得写权限。一个只能审批 10 万的人，不能通过多层委托让最终的 Agent 审批 100 万。
L4：凭证——你怎么证明
传统做法：Agent 拿着 API key 或 token 去调系统。
问题是： 如果 Agent 被 prompt injection 劫持了，攻击者就拿到了凭证。 一个被劫持的 Agent 拿着长期有效的 API key，可以做任何这个 key 允许的事——而且你发现不了，因为从系统角度看，所有请求都是「合法的 Agent 调用」。
正确的设计是 凭证不进入 Agent 运行环境 （credential-free）：
┌─────────────────────────────────────────┐
│ Agent 运行环境（沙箱） │
│ - 没有 API key │
│ - 没有数据库密码 │
│ - 没有任何长期凭证 │
│ │
│ Agent：「我需要访问 CRM」 │
└──────────────────┬──────────────────────┘
│ 请求（无凭证）
┌──────────────────▼──────────────────────┐
│ Agent Proxy（凭证边界） │
│ ① 校验 Agent 身份（L1） │
│ ② 校验当前场景权限（L2） │
│ ③ 校验委托链（L3） │
│ ④ 注入短期凭证（5 分钟有效） │
│ ⑤ 记录审计日志（L5） │
└──────────────────┬──────────────────────┘
│ 带短期凭证的请求
┌──────────────────▼──────────────────────┐
│ 目标系统（CRM / ERP / ...） │
└─────────────────────────────────────────┘
Agent 永远不持有凭证。 每次需要访问外部系统时，通过 Agent Proxy 注入一个短期凭证（5 分钟有效）。即使 Agent 被劫持，攻击者拿不到任何长期凭证——最多拿到一个 5 分钟后过期的 token。
这和 企业级 Agent Runtime 的安全沙箱 是一体的：沙箱隔离了文件系统和网络访问，Agent Proxy 隔离了凭证。两层加起来，即使 Agent 的推理逻辑被完全篡改，它能造成的损害也被限制在「5 分钟内、当前场景的权限范围内」。
L5：审计——你做了什么
Agent 的审计和人的审计有一个根本区别： 量级不同。 人一天 50 个操作，Agent 一秒 100 个。如果每个操作都记一条完整日志，日志量会爆炸。
所以审计需要 分层：
| 级别 | 记录什么 | 保留多久 |
|---|---|---|
| 操作日志 | 每一次 API 调用、每一次数据访问 | 30 天 |
| 决策日志 | Agent 的每一个判断和推理过程 | 90 天 |
| 委托日志 | 谁委托了谁、权限范围、撤回记录 | 永久 |
| 异常日志 | 权限拒绝、越权尝试、异常模式 | 永久 |
最关键的是 双轨审计——每一条操作记录同时记录人和 Agent：
AuditEntry {
action: "approve_purchase"
amount: 48000
human_requester: "user://zhang-san" # 谁发起的
agent_executor: "agent://procurement" # 谁执行的
delegation_id: "del://xxx" # 基于哪个委托
permission_id: "perm://yyy" # 基于哪个权限
context: "group:ops-team" # 在哪个场景
timestamp: "2026-07-28T10:30:00Z"
}
# generated by hugo AI
出了事，既能追溯到 Agent，也能追溯到人。 不是「Agent 做的」就完了——是谁委托的、在什么权限下、在什么场景里、基于什么决策。
我在 企业级 AI 必须设计成出错后可以追责到人 中讨论过：可追责性不是事后补丁，是设计前提。双轨审计就是这个前提的具体实现。
权限的动态收回
传统权限是「给了就一直在，直到管理员手动收回」。Agent 时代这不够——因为 Agent 的行为模式可能变化。
需要 权限的自动降级机制：
| 触发条件 | 动作 |
|---|---|
| Agent 连续 3 次触发权限边界（每次都卡在金额上限） | 自动降级，需要人重新确认 |
| Agent 的 owner 离职 | 权限自动冻结（不是删除），等新 owner 接管 |
| Agent 在某场景下 30 天没有活动 | 该场景的权限自动过期 |
| Agent 被检测到异常行为模式 | 权限立即冻结，通知 owner 和安全团队 |
权限不是静态配置，是有生命周期的。 它会过期、会降级、会冻结。这比「给了就永远有」安全得多。
对协同产品的影响
五层架构不只是安全团队的事——它改变了协同产品的基本交互：
通讯录里不只有名字和电话，还有权限和委托关系。 你查看一个 Agent 的资料页，看到的不是「它属于哪个部门」，而是「它能做什么、替谁做、在什么场景下做、谁授权的、什么时候过期」。
IM 里的每一次 @ 都隐含权限校验。 你在群里 @ 一个 Agent 说「帮我审批这个采购」，系统不是直接把消息转给 Agent——而是先校验：你有没有权限发起这个审批？这个 Agent 有没有权限在这个群里执行审批？委托链是否有效？
邮件的发送权限走委托链。 Agent 替你发邮件，不是用你的邮箱密码——而是基于你给它的委托，通过 Agent Proxy 注入短期凭证，以你的身份发送。邮件头里同时记录 From: zhang-san 和 X-Agent-Executor: sales-agent-001。
优先级：先建什么
如果资源有限，五层的建设顺序是：
| 优先级 | 层 | 理由 |
|---|---|---|
| P0 | L1 身份 + L4 凭证 | 安全底线。没有身份就没有追溯，没有凭证边界就没有防线 |
| P1 | L2 权限 + L5 审计 | 运营必需。没有场景化权限就会过度授权，没有审计就无法追责 |
| P2 | L3 委托 | 生态需要。大多数企业现阶段还是「一个人一个 Agent」，委托链还不复杂 |
P0 是「没有就不能上线」，P1 是「没有就不能规模化」，P2 是「没有就不能生态化」。
权限是信任基础设施
回到开头的数字：人一天 50 个操作，Agent 一秒 100 个。
这个 10000 倍的差距，不是通过「更小心地配置 RBAC」能解决的。它需要一套全新的信任架构——从身份到凭证到审计，每一层都为 Agent 的速度、委托链和可操纵性重新设计。
在 Agent 是一等公民 中，我讨论了通讯录、通信和时区的重设计。那些是 体验层——设计错了最多不好用。权限是 信任层——设计错了是安全事故。
没有信任基础设施，Agent 越强大越危险。有了信任基础设施，Agent 才能从「工具」变成「同事」——因为同事是受约束的、可追溯的、可问责的。
你的 Agent，有工牌吗？有权限边界吗？有审计日志吗？
你在企业 Agent 落地中遇到过权限设计的坑吗？欢迎留言讨论。