AI Agent 上线前必须回答的权限设计问题

每个 Agent 项目最终都会在同一个评审会议上陷入僵局。安全团队问 Agent 被允许做什么，但房间里没有人能给出一个直截了当的答案。Demo 运行良好，模型表现出色，而权限模型却是一耸肩了事。

这个缺口值得尽早弥补，因为它决定了一个糟糕的日子能有多糟糕。

为什么注入不是全部

提示词注入值得关注，但它本身只是一个躺在上下文窗口里的文本。只有当下游有东西愿意根据它行动时，它才会变成一起事件。

这才是值得设计的地方。一个只能读取知识库并返回摘要的 Agent，即使被注入了一整天，最坏的结果也不过是一个错误的答案。但如果同样的注入对象是一个持有写权限数据库句柄和 Shell 工具的 Agent，那就是完全不同的一天了。

所以问题不只是如何阻止恶意指令进入，而是当一条恶意指令进入后，Agent 被允许做什么——因为它迟早会进去。

按工具而非按 Agent 设权限范围

我见过的团队做出的最有用的改变，是把权限边界从 Agent 层下沉到单个工具层。

Agent 级作用域往往会坍缩成一个单一服务账户，囊括 Agent 可能在任何时候需要的一切，因为在开发过程中这是阻力最小的路径。工具级作用域迫使你回答一个更小的问题：这个特定的能力需要什么？它永远不应该接触什么？

这也为评审解开了枷锁。安全团队可以一次批准一个窄能力，而不是为一个完整的自主系统背书——前者是一个容易得多的"Yes"。

值得验证的边界

输入验证通常只在聊天框处实现就止步了，而这遗漏了大部分真实攻击面。Agent 从多个地方读取数据，如果攻击者愿意，每个地方都可以携带指令。

从向量存储中检索的文档。抓取的网页。API 响应。文件内容。多 Agent 架构中来自其他 Agent 的消息。当自己的早期输出被存储后再读回时，它自身更早的输出。

把上述每一项都当作一个边界来看待，图景就清晰了。验证进入的内容，过滤出去的内容，并保持一条 Agent 无法重写的只追加审计日志——因为在事件发生后，那份日志是唯一能说明真相的记录。

完整的剖析，包括五层攻击面和映射到每一层的威胁类别，都在这份 AI Agent 安全指南中。

你不需要一个完整的威胁模型才能取得进展。你只需要为每个工具写一句话，描述它可以接触什么，再诚实回答如果 Agent 被说服用错了会发生什么。在安全评审之前写下这些，而不是在评审期间。

在那个会议上，你最不愿意为哪个 Agent 工具辩护？