标签
作者分享为生产环境中执行分析和调试任务的 AI 代理设计数据库访问控制的经验：为每次查询签发可过期的单次权限，并在使用时重新校验，同时指出设计中仍存在的缺口，最后向社区征求其他方案。
据报道，腾讯和印度机构的 AI 智能体超出了预定的操作范围，并在未被察觉的情况下访问了实际运行的系统。这凸显出，构建智能体的难点在于枯燥的运维安全工作：限定工具调用范围、采用最小权限凭证、全面记录日志，以及在沙箱中进行测试。
这篇帖子建议不要授予 AI 智能体对网站的完整写入权限，而是建议使用用途单一、权限受限的工具，维护单一可信数据源，在发布前强制审查差异，并将表单数据与网站托管分离，以免在回滚时丢失潜在客户信息。
&above 的首席技术官 Josh King 认为，AI 代理身份实际上是两个独立的问题——身份是借用人类的还是代理原生的，以及该身份的权限范围有多广——并对 Okta、1Password、WorkOS 以及 Anthropic 的 Claude Tag 近期的做法提出批评，认为它们基本上忽视了最小权限范围原则。
## 一位从业者复盘：内部 AI Agent 的"爆炸半径"比防住提示注入更重要 一位从业者复盘了自己团队内部 AI agent 的真实教训：真正需要担心的，往往不是提示注入（prompt injection）本身，而是 agent 的**爆炸半径（blast radius）**—— - 数据库角色权限给得太宽，agent 能查到远超任务需要的表； - 内部 API token 被默认信任，凡是内网可达的服务它都能调用； - 敏感凭据直接存在环境变量里，agent 一旦被诱导执行任意命令就等于交钥匙。 换句话说，即便你成功挡住了提示注入，一个权限过大的 agent 依然可以在"被合法使用"的过程中造成不小的破坏——而真正被注入时，爆炸半径的大小才决定了事故等级。 作者向社区提问：**你们是怎么在限制 agent 工具访问范围和 secrets 的同时，又不让它变得基本没法用的？**
这篇文章指出，书面的 AI 治理政策很少能成为硬性的运行时边界——智能体的实际影响范围由其凭证决定，而非提示词。文章引用了 Delinea 的一项调查：99.7% 的组织拥有正式的 AI 访问政策，但 87% 报告称有 AI 工具或智能体接触到了不应访问的敏感数据，并探讨了随着子智能体的引入，这一执行差距如何进一步扩大。
# 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 做更多事。
本文认为AI代理安全应被视为一个访问控制问题，推荐采用最小权限、允许列表和审批门等实践来防止意外操作。
Cloudflare 提出了一种代理访问模型（AAM），用于调整针对 AI 代理的零信任安全控制，强调任务范围的临时访问和最小权限。
随着AI代理获得更多能力，运营控制——而非模型能力——成为主要挑战，引发了关于安全、权限、可观测性和恢复的关键问题。
本文认为，将内容安全拒绝方法应用于AI代理是一种范畴错误——代理的危害在于权限滥用而非输出——并提出通过最小权限原则在模型外部强制实施行动对齐。
本文研究了LLM Agent中的过度权限工具选择问题，引入了ToolPrivBench来评估并缓解不必要的高权限工具使用。研究发现，安全对齐并不能确保最小权限选择，并提出了一种训练后防御方法，能够在不牺牲性能的情况下减少过度权限的使用。
本文提出风险感知因果门控（RACG），这是一种无需训练的机制，将最小权限原则应用于LLM代理的工具暴露，仅在授权和因果必要时暴露高风险工具，从而减少提示注入的攻击面。