给 AI Agent 上锁:用 Policy Gates 划定行为边界

当 AI Agent 开始发邮件、改记录、删文件,仅靠提示词已经不够。Policy Gates 的核心,是把 Agent 从执行者降级为提议者。

当 AI Agent 只会回答问题时,风险主要停留在生成内容层面;一旦它开始发送邮件、更新记录、发布页面、删除文件,甚至触发部署,安全问题就从“回答得对不对”变成“有没有资格做”。Dev.to 上一篇关于 Agent 安全设计的文章指出,仅靠提示词告诉模型“不要做破坏性操作”并不可靠,更稳妥的做法是在 Agent 与真实副作用之间加入一层 Policy Gate,也就是策略闸门。

提示词不是权限系统,Agent 只能提议不能执行

文章给出的核心判断很直接:模型既是理解指令的组件,也是决定下一步动作的组件,因此“我们已经告诉模型不要这么做”并不能构成强约束。如果某项操作会产生真实影响,就不能把安全边界寄托在模型是否遵守提示词上。

作者给出的基本架构是:用户或工作流先进入 Agent,Agent 提出一个拟执行动作,再由 Policy Gate 判断该动作是允许、需要人工审核,还是直接拒绝。只有被允许的动作才会进入执行器,被拒绝的动作则终止,需要审核的动作进入人工流程。

这里的关键分离是“推理权”和“执行权”。模型可以判断调用 delete_document 看起来有用,但这不等于它天然拥有删除文件的权限。文章引用 OWASP 关于“过度代理”风险的描述指出,过度功能、过度权限和过度自主都会带来风险,对应的缓解方式包括压缩工具权限、对高影响操作要求人工确认,并在下游系统中执行授权,而不是依赖大模型判断某项动作是否被允许。

换句话说,Agent 应被视为“提议者”,而不是最终决策者。

策略闸门不能只看工具名,还要看资源、环境和参数

文章进一步指出,一个有效的 Policy Gate 不能只接收工具名称。同样是 update_file,写入 /tmp/draft.md 和写入 /app/production/config.json 的后果完全不同。如果策略系统只看到“更新文件”,就无法区分低风险草稿和高风险生产配置。

作者给出的动作对象包含多个上下文字段:actorId、userId、tenantId、tool、operation、resource、environment、arguments。其中 environment 被明确区分为 dev、staging 和 production。策略决定也不只是一个简单的 isSafe 布尔值,而应返回 allow、review 或 deny 三类结果,并附带原因。

这种三分法更接近真实业务:有些操作可以自动放行,有些操作永远禁止,还有些操作必须经过人工审核后才能执行。

文章给出了一段示意代码:当动作发生在生产环境且操作是 delete 时,直接拒绝;生产环境中的 write 操作进入人工审核;read 操作可以允许;其余没有明确授权的动作默认拒绝。所有会产生副作用的工具调用都必须经过统一的 dispatch 入口,不允许存在绕过策略闸门、直接调用底层工具的路径。

作者同时强调,这只是示意代码,并不是生产级授权系统,真正重要的是架构形态:策略判断必须先于副作用发生。

默认拒绝、人工审批和可审计状态

文章特别提到一个常见错误:只列出已知危险操作,其余全部放行。这种做法在工具较少时尚可维持,一旦新增工具,就会造成权限边界悄悄扩大。例如,现有规则要求 publish 需要审批,但开发者后来新增 bulk_publish,如果未知操作默认允许,新的批量发布能力就会绕开原有控制。

因此更安全的规则是:没有匹配到权限,就不能执行。新增能力应显式开通,而不是被默认继承。

文章还区分了提示词引导和授权机制。提示词适合影响模型行为,但不能替代权限控制。面对提示注入、上下文过期、幻觉,或模型对模糊指令作出不同理解等情况,策略应在模型决定拟执行动作之后、真实副作用发生之前介入。

作者提到,Open Policy Agent 等系统也体现了类似的“策略决策”和“策略执行”分离思路:策略引擎接收结构化输入,独立于业务逻辑进行评估,再把结果返回给执行点。文章表示,不一定要使用 OPA,真正有价值的是这种架构分离。

在风险上下文方面,文章举例称,仅知道 operation = send_email 并不够,策略还需要判断收件人是内部员工、单个客户,还是一个 8,000 人的邮件列表;同样,deploy 到 staging 与 deploy 到 production 风险也完全不同。相关政策输入可以包括用户、租户、环境、资源、参数等,但文章提醒,如果权威系统已经有这些数据,就不应让模型自行编造,而应从可信应用状态中解析。

文章最后区分了“审计”和“审批”。只是记录某人批准过,并不能算真正的人工审批;真正的审批应改变执行状态,使动作从 PROPOSED 进入经过策略检查后的下一阶段。对需要人工确认的高风险操作,系统必须让人类选择实际改变后续执行,而不是只留下一条日志。

原创文章,作者:点点,如若转载,请注明出处:https://www.dian8dian.com/gei-ai-agent-shang-suo-yong-policy-gates-hua-ding-xing-wei

Like (0)
点点的头像点点
Previous 16小时前
Next 14小时前

相关推荐