用分层防护限制 Agent 越权与误操作

你的 Agent 不需要更聪明的模型。它需要被约束在可控范围内。

没有任何单一过滤器能挡住所有 prompt 注入——OWASP 将其列入 LLM 应用的十大风险，并指出，目前甚至无法确定是否存在万无一失的预防方法。因此，目标不是筑起一道完美的围墙，而是建立分层防御：即使有攻击漏网，也能把影响范围控制在较小范围内，并在真正关键的环节引入人工介入。

第 1 层——输入护栏：把有害内容挡在外面

在推理之前，对所有输入进行验证和清洗：使用 schema、长度限制和允许列表。

检查越狱攻击，以及隐藏在 Agent 所读取文档中的间接注入——把检查作为推理前的关卡，而不是等推理结束后再处理。

尽早清除个人身份信息（PII）。模型从未收到的数据，就无从泄露。

默认拒绝：检查失败或超时时，不执行受保护的操作。

第 2 层——工具与操作护栏：限制 Agent 能做什么

这是投入产出比最高的一层——一套策略就能约束所有不可逆操作。

遵循最小权限原则：尽量精简工具列表。如果工具越来越多，就拆分 Agent。

为每个工具评定风险等级（低／中／高）。退款、删除、付款、对外发送消息——都要设置审批关卡。

将审批绑定到具体操作：这一笔订单、这个金额、这个幂等键——如果状态发生变化，就必须重新获得批准。

为执行循环设限：对每项任务的执行步数、token 数、成本和耗时设置硬性上限。

第 3 层——输出护栏：在输出交付前验证

强制执行 schema 校验，让格式不合规的输出明确报错。

进行依据核验：对照检索到的来源，验证输出中的说法。

审核内容并检查职责范围——客服 Agent 的回答如果远远超出职责范围，即使答案本身无害，也说明职责范围约束失效。

第 4 层——运行时护栏：监控执行循环

审计时做好脱敏——原始日志可能反而成为你原本想要防止的数据泄露源。

监控延迟、错误率、工具调用模式，以及每项任务的成本。

保留紧急停止开关：让人能够快速停止 Agent。需要的是一个按钮，而不是提交一张工单。

安全要落实在执行路径中——审批绑定、状态版本检查、幂等键——而不是写在 prompt 里。如果模型靠一番说辞就能绕过某项策略，那它就算不上护栏。托管服务（Bedrock Guardrails、Azure AI Content Safety）负责处理有害内容和注入等通用风险；你的代码负责处理业务逻辑风险——退款限额、审批流程、紧急停止开关。

这只是一篇浓缩版预告。完整的实施指南发布在 Agentic Affairs，包含高风险退款工具调用的端到端策略流程，以及 Bedrock 与 Azure 的对比：

约束 Agent 风险的四层 AI Agent 护栏

最初发表于 Agentic Affairs

如需进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。