Agent 的权限边界，是 AI 安全的下一个主战场

过去两年，我们讨论 AI 安全，大多停留在「模型会不会说错话」「会不会泄露训练数据」。这些问题很重要，但它们都还在输出层。

真正让企业安全团队睡不着的，是另一件事：模型开始有了手。

一、风险的位置变了

一个只会聊天的模型，最坏的结果是一句错话、一份错的摘要。一个有工具调用能力的 Agent，最坏的结果可能是一次错误的转账、一次越权的数据导出、一次以你的名义发出的邮件。

这不是模型变坏了，而是风险从「信息」迁移到了「动作」。在信息层，我们可以用审核、过滤、人工复核来兜底；在动作层，一次调用就已经发生，撤回的成本极高。

在企业 IT 和安全行业待久了，会形成一个反射：任何能改变系统状态的操作，都要先回答三个问题——谁在操作、能碰什么、怎么留痕。

这三个问题，恰好可以原样搬到 Agent 上。

二、第一个边界：身份

Agent 不该拥有「超级账号」。

最常见的做法，是给 Agent 配一个服务账号，然后把需要的能力都挂上去，图省事。这和十几年前运维脚本里硬编码 root 密码是同一类错误：一旦泄露，损失没有上限。

更稳妥的思路是让 Agent 继承发起人的身份，而不是拥有独立的高权限身份。用户 A 让 Agent 查一份报表，Agent 就只应该拿到 A 能看的那份数据；用户 B 的请求，不能因为「同一个 Agent」而顺带看到 A 的东西。

说得更直白一点：Agent 是代办人，不是新老板。

三、第二个边界：数据

数据边界要比模型能力更早确定。

我在做企业项目时有个习惯：先画数据流向图，再谈功能。Agent 时代这张图更复杂，因为数据会在「用户 → 模型 → 工具 → 第三方 API」之间来回流动，每一跳都可能是一次出境。

几个具体的检查点：

• 上下文里是否混入了不该出现的字段？日志、备注、内部编号，常常是泄露的起点。
• 工具返回的内容是否会被当作指令执行？这是提示注入最典型的入口。
• 数据在第三方推理服务上停留多久？是否用于训练？

这些问题的答案，不应该由工程师在写 prompt 时临时判断，而应该写进系统设计。

四、第三个边界：动作

动作要分级，而不是一刀切地「允许 / 禁止」。

我倾向于把 Agent 的动作分成三档：

1. 只读：查询、检索、生成草稿。默认放开，但要有速率限制。
2. 可逆写：创建草稿、打标签、写缓存。可以自动执行，但必须可回滚。
3. 不可逆：发送、支付、删除、授权。必须有人确认，且确认信息要足够具体。

第三档是最容易被产品体验裹挟的地方。「让 AI 全自动」听起来很美，但在没有审计与回滚能力之前，省下的那一次点击，可能会变成一次事故。

自动化的价值，不在于去掉人，而在于把人放到真正需要判断的位置上。

五、给正在做 Agent 的团队的一份清单

• 每个工具调用都能回答：谁发起、代表谁、碰了哪些数据、结果去哪了。
• 高风险动作默认需要确认，确认界面展示具体参数，而不是「是否继续」。
• 所有调用链可追溯，至少保留请求 ID、工具名、入参摘要、返回状态。
• 有熔断机制：异常频率、异常数据量、异常时间窗，都能自动降级为只读。
• 定期做「红队演练」：不是测模型会不会骂人，而是测它能不能被诱导去执行不该执行的动作。

写在最后

AI 安全最终会收敛到一句很朴素的话：能力越强，边界越要清楚。

模型会越来越聪明，工具会越来越多，但企业系统里那些古老的常识——最小权限、职责分离、可审计、可回滚——一条都没有过时。它们只是换了一个执行者。

对独立开发者来说，这也是个好消息：你不需要造一个安全平台，你只需要在设计的第一天，就把这三个边界画出来。