让AI代理继承用户权限而非共享密钥

当 AI Agent 需要真正执行工作时，最危险的捷径很简单：给它一个服务 API key，然后祈祷 prompt 能让它循规蹈矩。

这种捷径无法规模化。一个实用的 Agent 现在可以读取工单、创建 issue、更新 CRM 记录、运行查询、触发工作流，以及调用内部工具。如果所有操作都通过一个权限宽泛的 key 执行，你拥有的就不是用户权限，而是一个借用了万能门禁卡的机器人。

一种更安全的模式是 AI Agent 权限继承：Agent 使用当前用户受限的权限执行特定任务，并具备明确的限制、撤销机制和审计记录。

本指南将介绍如何为生产级 AI 工具设计这种模式。

为什么权限继承在当下如此重要

最近围绕 AI 平台的讨论始终聚焦于同一个问题：Agent 之所以越来越有用，是因为它们不只能回答问题，还能采取行动。但采取行动需要访问权限。

这种压力来自多个方面：

• 内部团队希望 Agent 能够跨客服、销售、工程、文档和数据系统开展工作。

• 开发者正在通过 MCP server、工作流平台、浏览器工具和私有 API 连接 Agent。

• 安全团队开始在实验中发现权限宽泛的 key、复制的 token，以及暴露在 prompt 中的凭据。

• AI gateway 和 Agent 平台正在增加可观测性、访问控制、故障回退和支出控制，因为模型调用正在成为基础设施。

• Agent 环境配置不当引发的安全事件，也在提醒开发者：“测试”和“生产”之间必须存在真正的边界。

实际得到的教训并不是“绝对不要让 Agent 采取行动”。这种结论过于武断。真正的教训是：Agent 应当继承来自用户和任务的有限权限，而不是依赖一个永久共享的 secret。

常见的反模式：所有 Agent 共用一个 key

小型团队通常会从下面这种架构起步：

User request
  -> AI agent
  -> tool router
  -> service API key
  -> internal systems

这种方式看起来很快，也很容易演示，还能避开 OAuth 的复杂性。但它同样会带来一大堆问题：

这不仅是安全问题，也是产品质量问题。如果用户无法理解 Agent 被允许做什么、它实际上做了什么，以及如何撤销操作或权限，那么到了关键时刻，他们就不会信任这项功能。

什么是 AI Agent 权限继承？

AI Agent 权限继承，是指 Agent 获得一份由用户身份、角色、tenant、授权同意和当前工作流派生而来的临时、任务级授权。

Agent 不会获得用户的原始密码，也不会获得权限宽泛的 service key。它得到的是一个 delegation token（委托 token）或 permission envelope（权限信封），其中会说明：

• 谁发起了任务

• 任务属于哪个 tenant 或 workspace

• 可以调用哪些工具

• 哪些记录或资源位于授权范围内

• 哪些操作只能读取、只能创建草稿，或者可以真正执行

• 允许消耗多少费用、时间或工具调用次数

• 权限何时过期

• 必须记录哪些证据

• 哪些操作需要人工审批

一个简单的模型如下：

User session
  -> permission service
  -> task-scoped delegation token
  -> agent runtime
  -> policy-checked tool calls
  -> audit log + revocation path

核心思想是：Agent 的权限不是由 prompt 决定的。prompt 可以说明任务内容，但真正允许执行哪些操作，必须由后端强制约束。

权限信封

先从一个简单对象开始。不要把权限设计藏在 prompt 里。

{
  "delegation_id": "dlg_01J8...",
  "actor_user_id": "user_123",
  "tenant_id": "tenant_456",
  "agent_id": "support_refund_agent",
  "task_id": "task_789",
  "purpose": "draft_refund_response",
  "allowed_tools": ["tickets.read", "orders.read", "refunds.draft"],
  "resource_scope": {
    "ticket_ids": ["ticket_234"],
    "customer_ids": ["cust_987"],
    "max_order_age_days": 90
  },
  "action_mode": "draft_only",
  "budget": {
    "max_model_calls": 12,
    "max_tool_calls": 20,
    "max_runtime_seconds": 180
  },
  "approval_required_for": ["refunds.execute", "emails.send"],
  "expires_at": "2026-08-06T10:30:00Z",
  "policy_version": "agent-policy-v4"
}

这个对象会成为产品、安全、工程和支持团队之间的契约。与“只能访问用户能够访问的内容”这类模糊指令相比，它也更容易测试。

将工具映射到用户权限，而不是模型意图

Agent 可能会声称自己需要某个工具，但仅凭这种说法远远不够。

每次工具调用都应经过策略检查，并综合考虑以下因素：

• 用户权限： 如果没有 AI，这名用户是否有权执行该操作？

• 任务范围： 该资源是否属于当前任务？

• Agent 模式： Agent 当前处于只读、草稿、Copilot，还是 Autopilot 模式？

• 风险等级： 该操作是否可能汇款、删除数据、向客户发送邮件、修改权限或泄露 secret？

• 证据： Agent 用于生成参数的信息是否来自可信来源？

• 预算： 此次运行是否已经超过工具调用量、token 用量或时间限制？

下面是一个简化的 TypeScript 风格策略检查：

type ToolCall = {
  tool: string;
  args: Record<string, unknown>;
};

type Delegation = {
  actorUserId: string;
  tenantId: string;
  allowedTools: string[];
  actionMode: "read_only" | "draft_only" | "supervised" | "bounded_autopilot";
  resourceScope: {
    ticketIds?: string[];
    customerIds?: string[];
  };
  approvalRequiredFor: string[];
  expiresAt: string;
};

function authorizeToolCall(call: ToolCall, delegation: Delegation) {
  if (new Date(delegation.expiresAt) < new Date()) {
    return deny("delegation_expired");
  }

  if (!delegation.allowedTools.includes(call.tool)) {
    return deny("tool_not_delegated");
  }

  if (!userCanUseTool(delegation.actorUserId, delegation.tenantId, call.tool)) {
    return deny("user_lacks_permission");
  }

  if (!resourceInScope(call.args, delegation.resourceScope)) {
    return deny("resource_out_of_scope");
  }

  if (delegation.approvalRequiredFor.includes(call.tool)) {
    return requireApproval("human_approval_required");
  }

  if (delegation.actionMode === "draft_only" && isStateChanging(call.tool)) {
    return deny("draft_mode_blocks_state_change");
  }

  return allow();
}

请注意这里缺少什么：代码中没有“LLM 说这样做是安全的”这一分支。

模型可以提出操作建议，是否允许执行则由 runtime 决定。

使用短期 delegation token

delegation token 应该朴实无华——这是一种称赞。

优秀的 delegation token 应当：

• 仅限一个任务或一次工作流运行

• 与特定用户和 Agent 身份绑定

• 无法在 Agent runtime 之外使用

• 在每次授权工具调用时留下日志

还应当：

• 使用短暂的有效期，通常以分钟而不是天为单位

• 能够立即撤销

• 绑定明确的 tenant 和资源范围

• 防止重放，或仅允许进行有条件的重放

避免使用长期有效的“Agent token”，否则它们会变成影子账号。如果后台 Agent 需要稍后继续执行任务，应持久化工作流状态，并在重新检查策略后签发一份新的委托授权。

对于长时间运行的工作，使用 lease（租约）：

run starts -> delegation valid for 10 minutes
run pauses -> lease released
run resumes -> policy re-check -> new delegation issued

这种机制能够应对以下情况：用户角色发生变化、客户记录被锁定、tenant 禁用了某个集成，或者支持团队经理撤回了审批。

分离读取、草稿和执行模式

大多数实用的 Agent 工作流并不需要从第一天起就具备完全自主权。

权限信封应包含当前模式，并由工具处理程序强制执行。

不要只依赖 UI 标签。如果产品显示“草稿模式”，后端就必须拒绝会改变状态的调用。

在上线前设计好撤销机制

很多 Agent 系统一谈到撤销机制，定义就开始变得模糊。

至少需要提供以下四条撤销路径：

• 用户撤销： 用户取消 Agent 的运行。

• 管理员撤销： 管理员禁用用户、角色、tenant 或集成。

• 策略撤销： 由于限制或证据规则发生变化，风险引擎阻止此次运行。

• 事件撤销： 安全团队禁用某个工具、provider、connector 或 Agent 类别。

Agent runtime 应该在每次工具调用之前检查撤销状态，而不是只在开始运行时检查一次。

async function beforeToolCall(call, delegation) {
  const status = await delegationStore.getStatus(delegation.delegation_id);

  if (status.revoked) {
    throw new Error(`Delegation revoked: ${status.reason}`);
  }

  return authorizeToolCall(call, delegation);
}

这种做法可能显得严格，但它能避免最糟糕的 Agent 故障：在人类以为工作流已经停止后，它仍在继续执行操作。

保存委托凭证

Agent 执行的每一项重要操作，都应该留下凭证。

一份优秀的凭证应当能够回答：

• 是哪个权限信封允许了该操作？

• 涉及了哪些资源？

• 该操作属于读取、草稿还是执行？

• 是否需要审批？

• 能否重放、审查或回滚？

{
  "receipt_id": "rcpt_01J9...",
  "delegation_id": "dlg_01J8...",
  "actor_user_id": "user_123",
  "tenant_id": "tenant_456",
  "agent_id": "support_refund_agent",
  "tool": "refunds.draft",
  "resource_ids": ["order_555"],
  "decision": "allowed",
  "approval_id": null,
  "policy_version": "agent-policy-v4",
  "created_at": "2026-08-06T10:18:14Z"
}

凭证不只是为了审计。它还可以帮助开发者调试错误输出、帮助支持团队解释 Agent 的行为，并帮助产品团队判断哪些工作流已经获得足够信任，可以进一步自动化。

内容缺口：大多数指南忽略了什么

关于 AI Agent、OAuth、MCP 和 API 安全的热门内容，往往只能讲好其中某一个层面：

• 如何构建 OAuth 流程

• 如何添加 prompt guardrail

• 如何记录模型调用

• 如何使用 AI gateway

缺失的实用价值，在于如何连接这些层面。权限继承正是这条连接纽带。

问题不只是“我应该把 key 存在哪里？”，而是：

对于这名用户的这项任务，这个 Agent 究竟应该继承哪些明确权限？系统又该如何证明这些权限得到了严格执行？

这是小型团队应该尽早弥补的架构缺口。

实施检查清单

在允许 Agent 访问真实工具之前，请使用下面这份检查清单。

1. 对每个工具进行分类

• 写入生产状态

• 发送外部消息

如果无法对某个工具进行分类，就不应将它提供给自主运行的 Agent。

2. 每次运行都创建一个权限信封

不要让 Agent 从 prompt 中自行推断权限。检查用户的 session、tenant、角色、套餐、授权同意和集成状态后，再由后端生成权限信封。

3. 将工具调用绑定到可信参数

如果 Agent 想为某笔订单退款，order_id 应来自可信查询结果或 UI 中选定的记录，而不能只来自自由文本。

4. 为高风险操作添加审批门槛

审批界面应显示变更 diff、来源证据和确切操作。“批准 Agent”过于模糊；“批准为 order_555 创建 $42.00 的退款草稿”才是可审查的。

5. 记录凭证，而不只是 trace

模型 trace 展示 Agent 思考了什么，凭证则展示系统允许了什么。两者缺一不可。

6. 测试跨 tenant 拒绝机制

添加回归测试，让 Agent 尝试对错误的 tenant、客户或记录使用有效工具，或者使用已经过期的委托授权。这些测试必须以拒绝告终。

7. 为用户提供停止按钮

清晰可见的停止按钮应该撤销委托授权、取消排队中的步骤，并阻止同一次运行继续发起工具调用。

支持 Agent 可以读取当前工单、查看最近的订单、起草退款方案并准备回复。在人工批准确切操作之前，它不能真正执行退款，也不能向客户发送邮件。

分析 Agent 可以查询用户已有权访问的指标。委托授权中包含行级 tenant 过滤器、指标定义、查询预算和禁用字段。Agent 不能通过使用权限更宽泛的 warehouse role 执行原始 SQL，绕过分析系统的权限控制。

编码 Agent 可以读取 issue、检查仓库文件、创建分支并起草 pull request。未经批准，它不能轮换 secret、修改部署设置或执行 merge。

销售运营 Agent

销售 Agent 可以丰富潜在客户信息、起草 CRM 备注并建议下一步操作。未经用户同意，也没有速率限制时，它不能导出完整客户名单或发送外部消息。

一个简单的参考架构

[User Session]
      |
      v
[Permission Service] ---- checks roles, tenant, consent, integration status
      |
      v
[Delegation Token / Envelope]
      |
      v
[Agent Runtime]
      |
      v
[Tool Policy Gateway] ---- checks tool, resource, mode, budget, approval
      |
      v
[Internal Tools / MCP Servers / APIs]
      |
      v
[Delegation Receipts + Audit Logs]

无论工具是 REST API、MCP server、队列、浏览器操作、SQL 查询，还是内部 SDK 调用，这套架构都适用。关键在于：每一条通往实际操作的路径，都必须经过策略网关。

还应跟踪能够揭示权限继承是否有效的指标：

• 按原因统计被拒绝的工具调用

• 按操作类型统计审批率

• 已过期委托授权的复用情况

• 跨 tenant 拒绝测试的通过情况

• 每个成功委托任务的成本

• 与权限范围过宽有关的事件

• 用户信任信号，例如审批内容的修改和取消率

如果每项操作都需要审批，你的 Agent 可能受到了过多限制。如果没有任何操作被拒绝，你的策略可能根本没有发挥实际作用。

AI Agent 需要访问权限才能真正产生价值。但提供访问权限，并不意味着把权限宽泛的 key、不可见的权限或永久授权交给模型。

权限继承为开发者提供了一条更好的中间道路：Agent 可以在特定任务中使用用户的有限权限采取行动，同时为每次工具调用提供凭证、撤销机制和策略检查。

这才是从令人惊艳的演示，走向真正值得用户信任的 Agent 工作流的方式。

什么是 AI Agent 权限继承？

AI Agent 权限继承是一种模式：Agent 获得由当前用户的权限、tenant、授权同意和工作流模式派生而来的临时、任务级权限。Agent 不会获得权限宽泛的 API key 或原始凭据。

权限继承与 OAuth 相同吗？

不同。OAuth 可以是实现方案的一部分，但权限继承是一种范围更广的产品与 runtime 模式。它还包括任务范围、资源限制、工具策略、审批门槛、撤销机制、预算和审计凭证。

AI Agent 是否应该使用 service account？

有时可以，但 service account 仍应受到 tenant、工具、任务和策略的约束。一个无所不能的宽权限 service account 风险很高。对于由用户发起的工作，应优先采用用户级委托授权。

prompt 能否强制执行用户权限？

prompt 可以描述规则，但不应该成为强制执行层。执行工具调用之前，必须由后端服务检查权限。

delegation token 应该保持多长有效期？

有效期应尽量短。许多交互式任务只需要几分钟。长时间运行的工作流应使用 lease，并在签发新的委托授权前重新检查策略。

小型团队最容易犯的错误是什么？

最大的错误是为了让演示更简单，给 Agent 一个权限强大的 key。这种捷径通常会导致审计日志薄弱、撤销能力不足、故障影响范围过大，以及跨 tenant 风险。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。