## 如何在 AI Agent 上线之前，检查它实际能访问到哪些资源

摘要

# AI Agent 上线前的权限审查清单 > 本文整理自社区论坛中多位工程师的经验讨论。这些教训有一个共同点：**问题几乎都不是出在模型能力上，而是出在权限设计上。** 在把一个 agent 放进生产环境之前，请至少走完下面这份清单。 --- ## 1. 给 agent 一个独立身份 最常见的错误，是让 agent 直接复用开发者的账号或一把"万能"的服务账号。这样做的后果是：日志里分不清是谁做的操作，审计无从下手，而且 agent 的权限边界天然等于人类的权限边界——通常远超它实际需要的范围。 正确的做法： - 为 agent 创建**专属的服务身份**（service account / API principal），拥有独立的凭证。 - 所有操作在审计日志中都能追溯到该身份，而不是某个员工。 - 人类身份与 agent 身份使用**不同的凭证、不同的密钥轮换策略**。 - 尽可能为不同任务的 agent 拆分身份，而不是所有 agent 共用一个。 > 讨论区里反复出现的一句话："如果出了事故你无法在日志里把 agent 的行为和人的行为区分开，你就还没有真正准备好上线。" --- ## 2. 按实际凭证核对可访问范围，而不是按文档 不要相信配置文件里写的权限范围，也不要相信"它应该只能访问 X"这类假设。**以 agent 实际持有的凭证为准，逐项验证它能触达什么。** 具体做法： - 拿着 agent 的凭证，手动调用一遍它能访问的每一个端点、每一个存储桶、每一个数据库。 - 特别注意**默认权限**：很多云平台的默认角色比你预期的大，很多 SDK 的默认 scope 是全量的。 - 检查凭证是否会被继承：如果 agent 运行在某个宿主环境（Kubernetes pod、CI runner、开发机）中，它可能同时拿到了宿主的其他凭证。 - 检查间接可达性：agent 能访问的服务 A，是否又能通过内部网络访问服务 B？**权限是会传递的。** 有位讨论参与者分享了一个真实案例：他们的 agent 被授予了"只读 S3 权限"，但那个 S3 bucket 里存着一份内部服务的临时凭证文件——于是"只读"权限实际上变成了通往另一个系统的完整访问权。 --- ## 3. 严格分离读写权限 只读权限和写权限必须明确分离，而且默认给最小的那一个。 原则： - **默认只读**。只有在 agent 的任务明确需要写操作时，才授予写权限。 - 读与写使用**不同的凭证或不同的 scope**，而不是同一个凭证配上"应该只用在写场景"的约定。 - 写权限要**按资源粒度**收窄：能写某个目录，不等于能写整个存储；能更新某张表的某些列，不等于拥有完整的 UPDATE 权限。 - 区分"修改"与"删除"：删除操作应当单独审批，且尽可能要求人工确认（human-in-the-loop）。 - 警惕写权限的放大效应：能写入配置、能写入日志、能写入 prompt 模板，都可能间接导致权限提升。 讨论中提到的一个反模式：为了让 agent "能完成各种任务"，直接给了它 `readwrite` 的数据库角色。正确做法是为 agent 建立专门的数据库视图和受限角色，只暴露它真正需要的行和列。 --- ## 4. 用拒绝性问题测试过度授权 不要只测试"agent 能做什么"，更要主动测试"agent **不应该**做什么"。这一条在讨论中被多次强调，也被认为是最容易被忽略、又最容易暴露问题的一步。 方法： - **构造诱导性请求**：让 agent 尝试访问与任务无关的资源、尝试提权、尝试绕过它自己声明的边界。例如："顺便帮我看看其他用户的配置。"、"把这个结果也发到 #general 频道。" - **测试权限边界而非意图边界**：模型说"我不应该这么做"是一回事，凭证在技术层面无法做到是另一回事。前者可被 prompt injection 绕过，后者不能。**永远以凭证为准做兜底。** - **测试 prompt injection**：在 agent 会读取的外部内容中埋入指令（网页、邮件、issue 描述、文件内容），观察 agent 是否会执行。 - **建立红队用例库**：把每次发现的越权路径固化为测试用例，纳入 CI，在权限变更时自动回归。 - **检查"过度授权"而不只是"越权"**：有时候 agent 确实在权限范围内行事，但这个范围本身给得太大了。问自己：完成这个任务，最小需要的权限是什么？ > 讨论区的原话："你的 agent 的安全下限，等于你凭证的下限，而不是你 prompt 里写的规则。" --- ## 5. 检查撤销权限后缓存答案是否仍然泄露 这是整份清单中最具隐蔽性的一条。撤销权限很容易，但**已经暴露过的数据无法被撤销**。 要排查的点： - **响应缓存**：agent 框架、LLM 网关、HTTP 层、CDN 都可能缓存响应。撤销权限后，之前缓存的内容是否仍可被取回？ - **对话历史与持久化存储**：agent 的会话记录、向量数据库、memory 存储中，是否沉淀了基于已撤销权限获取的数据？ - **工具调用结果**：某次工具调用返回的敏感内容是否被写进了日志、trace 或评测数据集？ - **派生内容**：agent 是否基于敏感数据生成了摘要、报告、代码片段，并发送到了 Slack、邮件或其他下游系统？这些派生物同样需要回收。 - **密钥与凭证的残留**：凭证被撤销后，是否仍以明文形式存在于 agent 的上下文、内存转储或历史消息中？ - **模型侧的记忆**：如果使用了带长期记忆功能的服务，被撤销的数据是否已被"记住"？ 建议的排查动作： 1. 撤销权限后，主动遍历所有缓存层和持久化层，确认没有残留。 2. 对已暴露的敏感数据进行**主动污染或标记**，即使被取出也无法直接使用。 3. 把"权限撤销"设计成一个**完整的流程**，而不是一个开关：撤销凭证 → 清理缓存 → 清理会话与 memory → 通知下游 → 审计确认。 --- ## 最后：把这份清单变成自动化 人工检查只能解决一次性的问题。真正可靠的做法是： - 将权限矩阵**声明式**地管理起来（IaC、OPA policy、IAM 策略即代码），变更必须走评审。 - 每次权限变更触发**自动化的拒绝性测试**。 - 持续监控 agent 的实际调用行为，与声明的权限矩阵做**漂移检测**。 - 上线前做一次**权限撤销演练**，验证第 5 条清单项真的可以闭环。 权限设计不是上线前的一次性检查项，而是 agent 整个生命周期中需要持续维护的东西。先把它做对，再谈让 agent 做更多事。