Agent

为什么我构建了AgentGuard

在观看了一支团队将集成到一个可以读取数据库、调用支付API和发送电子邮件的代理后，我开始构建AgentGuard。这个代理在演示中工作正常，但一个简单的用户查询中的拼写错误导致它将钱转移到了错误的账户。没有人在调用之前检查过代理被允许做什么，也没有办法在错误发生后停止它。

我意识到问题不在于模型本身，而在于缺乏对其行为的边界。我想要一种可重复的方式来列出代理可以访问的每个工具，决定谁可以启用每个工具，测试代理对我们认为它具有的权限，并在出现问题时做出反应。NIST AI风险管理框架为我提供了与这些步骤完全匹配的四个功能。

核心概念：输入过滤器、工具权限、输出检查

输入过滤器

这些检查在调用工具之前运行，用于检查用户提示或代理的内部推理。示例包括：

- 检测尝试忽略先前指令的提示注入模式。

- 检查不允许的关键字或短语，这些关键字或短语可能表示请求访问受限系统。

- 验证提示包含所需的批准令牌，当引用高风险工具时。

我们将输入过滤器实现为轻量级正则表达式引擎，结合一个小的允许列表安全模式。它们每次调用增加的延迟不到两毫秒。

工具权限

工具权限定义了工具可以读取、写入或删除的数据，以及它可以联系的外部服务。我们将每个权限存储为一个元组：

- 工具标识符

- 允许的数据源（例如，仅读取访问客户表，写入访问审计日志）

- 网络目的地（例如，api.paymentprovider.com 端口 443）

- 所需的批准级别（无，同行审查，经理签署）

当代理请求使用工具时，权限服务会检查元组与当前上下文，并允许调用、修改参数或阻止它。

输出检查

工具返回结果后，输出检查会验证响应是否在预期范围内。示例：

- 确保 SQL 查询返回的行数不超过 100 行。

- 确认电子邮件有效载荷不包含外部 URL。

- 扫描响应中的泄露密钥，例如 API 密钥或密码。

将防护栏映射到NIST AI RMF函数

该框架的四个函数为组织防护栏工作提供了清晰的结构。下表显示了哪个防护栏属于每个函数，产生的具体文物，以及一个简短的示例。

NIST函数 | 防护栏类型 | 文物 | 示例 Govern | 审批工作流 | 工具启用记录 | 一份签署的文件，列出谁批准了send_email工具，日期和所需的MFA用于批准者。 Map | 工具库存 | 权限矩阵 | 一份电子表格，枚举每个工具，能够读/写的表格和可能调用的外部端点。 Measure | 测试套件 | 对抗性提示集 | 一组旨在触发权限升级，数据泄露或未经授权的外部调用的提示。 Manage | 运行时响应 | 关闭开关日志 | 一条时间戳的条目，记录代理尝试删除生产记录的时间，阻止的操作和被通知的操作员。

我们如何评估工具调用

步骤 1：识别工具及其权限类

我们首先在权限矩阵中查找工具。矩阵分配一个基本风险级别：

- 只读查找（例如，获取产品目录）→ 低

- 写入内部日志 → 中等

- 外部操作具有副作用（例如，发送钱，删除记录）→ 高

如果工具需要批准令牌，我们将基本风险级别增加一級。

步骤 2：分析提示以检测注入风险

步骤 3：检查数据敏感性

我们检查工具可以访问的数据源。如果任何源包含个人可识别信息（PII）或财务数据，我们将增加另一个级别。

步骤 4：生成最终评级和建议过滤器

最终评级是基本级别、提示级别和数据级别调整的总和。根据评级，我们建议：

- 低 → 无需额外过滤，只需记录调用。

- 中等 → 添加输入过滤器以剥离不允许的关键字和输出检查以限制行数。

- 高 → 需要人工审批，强制执行严格的允许列表参数，并启用完全输出编辑。

什么不是

我想明确说明防护栏的限制，以免您将其误认为是万能的解决方案。

- 防护栏不能保证代理永远不会造成伤害。它们减少了错误的影响范围，但决心强的攻击者或范围不良的工具仍然可以在允许的边界内产生不良影响。 - 它们不是安全编码实践的替代品。如果底层工具存在漏洞（例如，SQL 注入漏洞，如 https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html 中描述的），则防护栏无法修复该漏洞。 - 它们不提供 100% 的安全认证。可以将其视为决策支持工具，帮助您就工具使用做出明智的选择。

实践步骤：审查工作流程的逐步指南

1. 收集AgentGuard的系统提示和工具列表

导出AgentGuard在启动时接收的确切文本和声明其可以调用的每个工具的JSON或YAML文件。

2. 填充权限矩阵

对于每个工具，记录：

- 允许的读取目标

- 允许的写入目标

- 外部端点和所需的身份验证

- 所需的任何批准令牌或角色

3. 运行基线风险评级

应用前面描述的四步评级过程。记录每个工具的初始风险级别。

4. 生成输入和输出过滤器建议

根据风险级别，生成具体的过滤规则（正则表达式模式、行数限制、编辑规则）。将它们存储在工具定义旁边。

5. 执行对抗测试套件

将AgentGuard运行在表格的Measure列中的提示集上。验证过滤器是否阻止或减轻预期的故障模式。

6. 记录结果

创建一个简短的报告，列出：

- 工具名称

- 初始风险评级

- 应用的过滤器

- 测试结果（通过/失败）

- 所需的手动批准步骤

7. 设置监控和警报

配置AgentGuard的运行时环境以记录每个工具调用、应用的过滤器和输出检查结果。将异常路由到您的事件响应渠道。

8. 安排审查触发器

标记工作流程在以下任何情况发生时重复：

- 添加新工具到列表

- 编辑系统提示

- 工具的权限更改（例如，数据库获得一个具有PII的新列）

常见陷阱及其避免方法

陷阱1：过度依赖单一过滤类型

团队有时认为添加关键字阻止器就足够了。我们通过要求任何中高风险工具同时进行输入和输出检查来避免这一点，并记录当任一检查触发时的日志。

陷阱2：忘记更新权限矩阵

当工具获得新功能（例如，支付API现在支持退款）时，必须在代理使用它之前编辑矩阵。我们通过将矩阵作为版本控制文件来强制执行这一点，该文件由CI管道在每次推送时验证。

陷阱3：忽略在上下文中变为高风险的低风险工具

一个只读查找返回用户电子邮件地址的工具可以在代理稍后在密码重置流中使用该地址时变得危险。我们将数据敏感性视为单独的评级因素，因此自动将处理PII的低级工具升级。

陷阱4：跳过高风险工具的人工干预步骤

对于可以移动资金或删除记录的工具，我们要求一个明确的批准步骤，该步骤不能被自动化绕过。批准记录在不可变日志中。

陷阱5：将防护栏设置视为一次性任务

我们将审查工作流嵌入团队的完成定义中，以便在更改代理行为的任何功能中。这样使得该过程可重复，而不是被遗忘的清单项。

参考资料

- https://genai.owasp.org/llmrisk/-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

常见问题

是否可以通过限制来使代理安全?

不。它们只能限制错误的影响范围。一个决心要攻击的攻击者、一个范围不正确的工具或一个有问题的提示仍然可以在允许的边界内造成伤害。

我们需要什么来运行审查?

代理的系统提示和其工具列表。这些足以评估调用和建议过滤器。

EU AI Act 映射是否是法律建议?

不。它是一个映射，帮助您找到正确的义务。分类您的系统并满足义务仍然需要一个合格的审查员。

我们应该多久重新运行一次?

每当工具列表、系统提示或工具可以访问的数据发生变化时。

它是否在运行时测试代理?

它审查提示和工具配置。运行时监控是一个单独的层，您仍然需要它。

如果一个工具真正具有高风险?

需要一个批准步骤，缩小其参数，并记录每次调用。高风险工具通常需要一个人类在循环中，而不是一个过滤器。

参考

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

尝试产品：AgentGuard

相关文章

- AI代理工具允许列表：为什么默认拒绝是更好的选择 - 浏览完整的AI微SaaS主题矩阵 →