AI

默认拒绝比尝试阻止每个恶意调用更有效的原因

当你以默认拒绝的态度开始时，你只需要思考代理真正需要什么。每个其他调用都会被自动停止，而不需要预测每种可能的滥用。这减少了审查者的精神负担，并降低了遗忘危险的滑脱的机会。

考虑一个写报告的代理。它需要读取模板文件，从数据库中拉取数据，并将完成的PDF发送到内部邮件。 如果你只列出这三个调用，任何尝试运行shell命令、查询外部API或删除表的行为都会被立即拒绝。 你不需要写一个规则说“阻止rm -rf”，“阻止curl到evil.com”，或“阻止DROP TABLE”。 默认拒绝规则涵盖了所有这些。

在实践中，我看到团队花费数周时间构建长的阻止列表，但仍然会错过新的攻击向量，而一个只有五个项目的短允许列表却可以在第一天阻止相同的攻击。 维护方面的节省是真实的：你在工具更改时审查允许列表，而不是在新的威胁出现时。

如何为新代理构建允许列表

我遵循一个可重复的检查清单，以保持列表紧凑和可审查.

- 记下代理必须今天执行的确切任务。忽略“可能以后有用”的想法. - 对于每个任务，找到单一工具以最窄的参数执行任务。如果工具提供一个扩大范围的标志，除非任务明确需要，否则不启用它. - 在一个简单的YAML文件中记录工具名称、确切的命令或API端点以及允许的参数值。该文件与代理代码一起存放，以便审查者可以一眼看到它. - 在沙盒中运行代理，并验证每个列出的调用都成功，以及文件中未列出的任何调用都返回错误. - 请同事审查列表。审查者的任务是确认每个条目都映射到实际任务，并且没有额外的功能隐藏在默认值后面. - 将文件存储在版本控制中。将每个提交标记为代理版本，以便您可以跟踪哪个允许列表与哪个版本一起发布. - 设置一个CI步骤，如果YAML文件缺失或包含未在项目工具注册表中批准的工具，则构建失败.

此过程需要我大约一个小时来完成简单代理，并生成任何人都可以审计的文档.

根据工具的可变性进行分类

并非所有工具都带有相同的风险。我将允许的工具分为三个影响类别，以便我知道在哪里添加额外的检查。

影响类别 | 含义 | 示例工具 | 典型安全措施 只读 | 可以获取数据但不能改变状态 | 文件读取、数据库SELECT、公共API GET | 记录调用，无需额外审批 可写或可变 | 可以创建、更新或删除数据 | 文件写入、数据库INSERT/UPDATE/DELETE、内部消息发布 | 需要第二个审批者进行第一次使用，记录用户ID 不可逆的外部影响 | 可以影响信任边界以外的系统 | 发送电子邮件、发布到社交媒体、发起支付、调用外部Webhook | 强制手动审批、详细审计跟踪、调用超时

当我审查新的工具时，我会问：'如果这个调用运行，可能发生的最坏情况是什么？'答案告诉我哪一行表格适用。对于只读工具，我仅添加一个日志行。对于可写工具，我添加一个轻量级的审批工作流。对于不可逆的影响，我强制执行手动门槛并保持调用窗口短。

将允许列表与输入和输出过滤器配对

允许列表可以去除不必要的功能。过滤器可以捕获允许的调用中滑过的坏数据。我将它们视为互补的层，而不是替代品。

在输入端，我运行一个提示注入检查器，用于查找已知的 jailbreak 模式。我使用 OWASP LLM 提示注入防御备忘录（链接）作为启用规则的参考。如果检查器标记一个提示，我要么拒绝它，要么在代理看到它之前清理有问题的段。

在输出端，我扫描代理生成的文本以查找秘密、SQL 注入尝试或不允许的 URL。密钥管理备忘录（链接）帮助我为 API 密钥、密码和令牌构建正则表达式模式。SQL 注入防御备忘录（链接）指导我使用的模式以捕获可能在响应中回显的危险查询字符串。

什么这不是

我想明确允许列表的限制，以便您不会期望它解决它从未打算解决的问题。

- 它不能保证代理永远不会表现出恶意行为。一个决心的攻击者如果找到一种方法以恶意参数调用允许的工具仍然可以造成伤害。

- 它不替代安全的编码实践。如果代理自己的代码包含漏洞，允许列表无法阻止对该缺陷的利用。

- 它不是适当的秘密管理的替代品。即使代理不能调用秘密泄露工具，日志或输出中泄露的秘密仍然存在风险。

- 它不能阻止间接提示注入，这种方法操纵代理以意外的方式使用允许的工具。您仍然需要输入验证和输出过滤。

- 它不是一次性的任务。每当添加工具、其参数更改或代理的目的发生变化时，您必须重新审视列表。

常见的陷阱及其避免方法

即使有明确的流程，团队仍然可能陷入削弱允许列表的习惯。以下是我关注的模式和我采取的具体步骤，以保持列表的真实性。

- 过于宽泛的参数 – 有人添加一个带有“--recursive”或“--all”标志的工具，因为它看起来很方便。我通过询问“满足任务的最小选项集是什么？”来对抗这一点。如果答案是子集，我会在YAML中锁定该标志到该子集。

- 被遗忘的工具更新 – 一个库更新并添加一个新的命令，该命令会被自动暴露。我通过在AgentGuard的依赖文件中固定工具的确切版本并添加一个CI步骤来缓解这一问题，该步骤会在新版本引入未记录的命令时失败。

- 将策略与提示混淆 – 一个开发人员尝试通过在提示中添加“不要调用删除”等指令来强制执行限制。我提醒团队，提示级别的控制可以通过巧妙的重述来绕过；真正的防护必须位于工具注册表或执行层。

通过将每一项视为我工作流程中的一个具体检查，我保持允许列表紧凑，和的blast radius小，的移动更加精确。

参考资料

- OWASP LLM 提示注入防御备忘录 - OWASP SQL 注入防御备忘录 - OWASP 密钥管理备忘录 - AgentGuard 配置文件指南

常见问题

提示指令是否足以限制工具?

不。提示级别的限制可以被规避。应在工具注册表或执行层强制执行允许列表。

什么是不可逆的外部影响?

发送电子邮件或消息、转移资金、删除记录、发布内容——任何无法撤回的操作。

工具太多是什么意思?

没有具体的数量。测试是是否可以解释每个工具在列表中的任务要求和可能造成的破坏。

过滤器是否可以替代允许列表?

不。过滤器捕获恶意内容；允许列表删除不必要的功能。同时使用两者。

这是否涵盖间接提示注入?

它限制了可以造成的损害。检测和阻止注入本身是输入侧的单独控制。

审查是否是安全审计?

不。它是决策支持，评估调用并建议过滤器。部署的完整评估仍然需要安全审查。

参考资料

- OWASP — 大型语言模型应用程序的前 10 项 - NIST — 人工智能风险管理框架

尝试产品：AgentGuard

2026-09-20 · 仅主来源 · 不含虚假流量指标 · 决策支持仅

相关文章

- 将代理防护栏映射到NIST AI RMF - 探索完整的AI微SaaS主题矩阵 →