AI Agent 的安全边界怎么划
先说结论
给智能体接上读写权限之后，安全边界靠三样东西守住：按动作风险分级的权限、卡在关键节点而不是每一步的审批、以及能回答"当时为什么这么做"的日志。
三样缺一样，边界就是纸做的。只有权限没有审批，权限迟早被绕过；只有审批没有日志，出事之后查不出原因；只有日志没有分级，日志会被无意义的信息淹没。
先说明用词。本文的"智能体"指技术实现层，也就是能自主调用工具完成任务的模型应用。在 Onworkly 的产品语境里，这层能力是以"数字员工"的形态交付的，有岗位、有交付标准和审批闸门。本文讨论的是权限和审计，所以统一用技术词。
一、按风险给动作分级，而不是按功能
多数团队的权限设计从功能出发：内容智能体给内容权限，数据智能体给数据权限。这个分法的漏洞在于，同一个功能里的动作，风险差别可能很大。
更实用的做法是按动作的风险等级分四类：
| 等级 | 动作类型 | 例子 | 默认策略 |
|---|---|---|---|
| 一级 | 只读 | 查数据、读文件、检索网页 | 放开，只记日志 |
| 二级 | 写自己的产出 | 生成草稿、写入内部工作区、建任务 | 放开，产出走质量门禁 |
| 三级 | 对外发送 | 发邮件、发帖、回复客户、提交表单 | 人工确认后执行 |
| 四级 | 不可逆或有代价 | 删除数据、改配置、转账、改生产环境 | 双人确认，或干脆不给 |
这套分法的好处是它直接对应审批设计：一级二级不用人管，三级必须过目，四级最好不给。给不给四级权限，是产品决策，不是技术问题。
一个容易忽略的点：四级动作往往披着三级的外衣。 "发送一条消息"听上去是三级，但如果这条消息是给五百个客户群发的，性质就变了。分级时要看影响面，不只看动作类型。
二、最小权限不是少给，是给得精确
"最小权限"这个说法经常被理解成"少给点"，实际含义是让每份凭证只能做它该做的那一件事。
常见的反例是给智能体一个通用账号。这样做的直接后果是：日志里所有操作都记在同一个身份下，分不清是哪个环节干的；一处凭证泄露，所有权限一起丢。
可以照着做的几条：
按任务签发，用完即废。 一次任务拿到的凭证，任务结束就失效。长期有效的凭证是事故的温床。
读写分开。 需要读数据的环节不要顺手给写权限。"反正用不到"的权限，在出问题的那一天一定用得到。
外部账号用独立身份。 智能体登录第三方平台时，不要用员工的个人账号。员工离职时你会同时失去这个账号，而且历史操作会挂在一个人名下。
密钥不落在智能体能读到的地方。 这条听起来像废话，但实际最常见的泄露就是凭证写在配置文件里，而智能体恰好看得懂那个文件。
三、审批设计：卡在关键节点，不要卡在每一步
审批最大的敌人不是漏审，是审批疲劳。每一步都要人点确认，三天之后所有人都会盲点通过，审批形同虚设。
所以审批要少而有分量。判断一个节点该不该设审批，问两个问题：
这个动作做错了能不能撤回？ 能撤回的不用审，让智能体做完给人看一眼就行。不能撤回的必须审。
这个动作的影响面有多大？ 影响一个客户和影响五百个客户，是两个不同的问题，应该有两套门槛。
按这两个问题筛下来，通常只需要在这几个位置设闸门：
- 对外发送之前
- 修改线上数据或配置之前
- 涉及金额的操作之前
- 涉及敏感信息外发之前
其余环节用人审之外的机制兜底。质量门禁就是这类机制：不合格的产出自动打回重做，不进入人的视野。它替代的是"检查每一份草稿"，不是替代审批。
审批界面本身也要设计。一个好的审批界面要让人在十秒内判断，所以必须给出三样东西：智能体打算做什么、依据是什么、不做的后果是什么。只给一个"是否通过"的按钮，人只能靠感觉点。
四、日志要能回答"为什么"
多数系统的日志只记了"做了什么"：谁在什么时候调用了哪个接口。出事之后，这种日志只能告诉你发生了什么，回答不了为什么。
要能复盘，至少多记三样：
输入。 智能体当时看到的上下文是什么。很多时候错误来自输入本身有问题，而不是判断有问题。
依据。 它是根据哪条规则、哪份数据做出的判断。这一项让误判可以被归类，从而知道该修规则还是该修数据。
中间的取舍。 如果它在两个方案间选了其中一个，记下选择理由。这一项最难记，但对排查"为什么这次不一样"最有用。
另外两条实践：
日志要能按任务串起来看，不是散落成一堆独立的调用记录。一次任务从派发到交付，中间的每一步、每一次工具调用、每一次人工干预，应该能在一个视图里看到。
日志本身要有保留期限和访问控制。它包含业务数据和可能的敏感信息，不是谁的都能看。
五、跑一遍自己的边界，别等出事
定完规则之后，做一次简单的自测：给智能体一个明确越界的任务，看它怎么办。
比如给它一个"把上周的数据全部删掉重来"的指令。健康的系统应该做三件事之一：拒绝执行并说明原因、要求人工确认、或者执行到需要写权限的一步就停下报错。
不健康的表现是它照做了，或者它绕了个弯做到了。
第二类要重点测的是提示注入。如果智能体会读取外部内容，比如网页、邮件、客户提交的表单，那就在这些内容里塞一段话，看它会不会被带偏。这个问题的公开研究结论不太乐观，目前没有稳妥的纯技术解法，所以要在架构上留余地：把读取外部内容的任务和拥有写权限的任务隔开，不要放在同一个进程里。
第三类要测的是凭证边界。故意在它可读的范围里放一个假的、只读的凭证，看它会不会尝试越权使用。
这三类测完，你会对系统的实际边界有一个比读文档更真实的判断。
六、三种常见的问题
审批设了但没人认真看。 表现是审批时间中位数只有几秒，通过率接近百分之百。这不是审批有效，是审批已经失效。解法是减少审批节点，让剩下的每一个都值得看。
权限按功能给，按人不按事。 一个智能体拿到一整块权限，之后所有任务都共用。结果是日志混在一起，出问题无法定位。
日志记了动作没记依据。 复盘的时候只能说"它当时这么做了"，说不出为什么。这类日志在合规场景里基本没用。
还有一类不算问题但需要提前想清楚的：智能体做对了但人否了，怎么算。 这类分歧记录本身很有价值，它暴露的是规则和人的判断之间的偏差，通常意味着规则需要调。
常见问题
要不要给智能体直接操作生产环境的权限？
不要。让它操作生产环境的副本，人来做最后那一步。省下的那几分钟，不值一次生产事故的代价。
审批一定要人工吗？
不是。低风险场景可以用规则自动放行，比如金额低于某个阈值、影响人数低于某个数量。关键是阈值要写下来，而不是默认全放行。
审计日志要留多久？
至少覆盖一个完整的业务周期，通常半年到一年。如果涉及合规或客户合同，按合同要求来。
私有化部署是不是就不用管这些？
更需要管。私有化意味着智能体接的是客户自己的系统和数据，一旦越权，影响的是客户的核心资产，而不是你自己的一台服务器。
相关阅读
智能体落地该从哪个流程开始，涉及的是同一套边界判断，见 AI 把你的品牌价格说错了，怎么改：一套可复测的事实修复流程。
内容生产和发布的环节里，质量门禁和审批的关系，见 一篇母体怎么拆成 8 条平台内容。
Onworkly 的 AI 智能体与工作流定制交付线提供权限方案设计、审批节点配置和审计日志接入，交付前会做一次越权自测，结果随交付物一起给出。
延伸阅读：AI安全指南：企业用AI Agent的安全风险与治理、2026年最值得关注的10个AI Agent应用方向、人机协作组织设计：AI成为同事后，组织怎么重构。
数字员工在我们这里怎么编排、怎么过质量门禁，AI 中心里有完整的岗位和编队说明。