AI Agent 的身份与授权：一套可落地的最小权限设计
AI Agent 接入邮件、代码和云 API 后，提示词不能替代权限系统。本文给出身份拆分、动作级授权、人工审批与审计日志的实施框架。
3 分钟阅读
当 AI Agent 能读邮件、访问代码仓库、调用云 API，安全问题就不再只是“模型会不会答错”，而是：它以谁的身份行动、能碰哪些资源、谁批准了这次操作，以及出事后能否还原全过程。
2026 年 5 月，NIST 发布了对 AI Agent 安全意见征集的总结。参与者普遍认为，传统网络安全原则仍然有效，但需要针对 Agent 的自主规划、外部数据和工具调用进行改造。NIST 此前的身份与授权概念文件也把识别、认证、授权、审计和不可否认性列为核心问题。对开发团队而言，这意味着提示词不是权限系统，模型的“判断”也不能替代服务端授权。
先画出三种身份
一个可审计的 Agent 系统至少需要区分三种主体：发起任务的人、执行任务的 Agent，以及真正调用工具的工作负载。把三者共用一个长期 API Key，看似方便，却让日志无法回答“这一步究竟代表谁”。更稳妥的做法是让每个任务获得短期、可撤销、范围受限的凭证，并在工具端同时验证用户、Agent、任务和目标资源。
权限矩阵应按动作，而不是按应用划分
| 动作 | 默认策略 | 额外控制 |
|---|---|---|
| 读取公开网页、只读搜索 | 可自动执行 | 限制域名、频率与响应大小 |
| 读取私有仓库或客户数据 | 按任务授权 | 字段级脱敏、短期凭证、访问日志 |
| 修改文件、创建分支 | 沙箱内允许 | 限定目录、保存 diff、可回滚 |
| 发送邮件、发布文章、付款 | 执行前人工确认 | 展示目标、内容、金额与不可逆后果 |
| 删除、生产部署、提升权限 | 默认拒绝 | 双人审批或独立策略服务 |
关键不是把每一步都弹窗，而是在副作用边界上确认。审批界面必须显示真实参数，不能只问“是否继续”。OWASP 的 Agent 安全指南同样建议最小权限、逐工具授权，并让执行组件独立检查权限与批准状态。
外部内容一律当作数据
网页、邮件、PDF、代码注释甚至工具返回值都可能夹带指令。NIST 的红队研究把这类“间接提示注入”称为 Agent hijacking：模型在完成正常任务时读到攻击者留下的文字，进而调用工具做出非预期动作。仅在系统提示里写“忽略恶意指令”并不构成可靠隔离。
- 解析外部内容的组件默认没有写权限；
- 工具参数由可信代码做类型、范围和资源所有权校验；
- 高风险动作重新绑定原始用户意图，不继承网页里的指令；
- 凭证不进入模型上下文，日志也不记录完整秘密；
- 对循环次数、调用费用和外发数据量设置硬上限。
一条操作必须留下什么证据
每次工具调用至少记录：任务 ID、用户身份、Agent 版本、工具与参数摘要、策略决定、批准人、执行结果和资源版本。日志用于回答授权与结果，不应保存不必要的提示词、客户原文或密钥。对写操作保留 before/after 或提交哈希，才能真正回滚。
这也解释了为什么桌面 Agent 的竞争最终不会只看模型能力。企业真正购买的是可控执行：清楚的权限边界、可恢复的状态、稳定的审计证据，以及人在关键节点拥有最后决定权。关于 Agent 越权问题，可以继续阅读本站的权限边界分析和桌面 Agent 趋势文章。
上线前的七项检查
- 列出 Agent 能看到的数据和能调用的工具。
- 将读、写、外发、支付、删除拆成独立权限。
- 使用任务级短期凭证，并测试撤销。
- 让服务端校验资源所有权，不信任模型声明。
- 为外部内容建立无工具解析区。
- 对高风险动作展示完整参数并二次批准。
- 用无害测试工具回放提示注入、越权和重试场景。