AI

Govern: 所有权和责任

定义规则所有者

我在每个包的开始处指定一个负责每个规则的个人或团队。该所有者签署规则文本，季度审查，并批准任何更改。如果没有明确的所有者，今天阻止危险工具的规则可能会在新集成出现时被遗忘，从而导致代理具有意外的访问权限。

更改控制过程

我将包视为版本控制文件。每次编辑都会创建一个新提交，包括一个简短的理由，并通过一个审查清单，该清单涵盖：（1）对允许工具的影响，（2）对数据类标签的影响，（3）升级路径和（4）与现有审计证据的兼容性。清单与包位于同一个存储库中，因此审查人员可以在一个地方看到差异和讨论。

链接到 NIST Govern 函数

NIST AI RMF 将 Govern 描述为设置角色、职责和策略的基础。我的包通过使所有权显式化并嵌入轻量级更改控制工作流来镜像这一点，以便审计员可以检查。当审计员询问“谁对此规则负责？”时，我可以指向所有者字段和提交历史。

相关工具和资源：MailPilot、AIActRadar、AgentPolicy、AgentRedTeam、Waffo、OWASP、NIST、EU AI Act 等。

映射：上下文和数据流

工具和数据类的清单

我列出代理可能调用的每个外部工具，然后为每个工具标记它可以读取或写入的数据类。例如，总结工具得到“customer-tickets”的标签，因为它可以处理票据文本，而数学计算工具得到“none”的标签，因为它只返回数字。这种双层视图可以防止常见的错误，即允许工具在不知道它接触到的数据的情况下运行。

每个工具的风险评分

对于每个工具-数据对，我分配一个简单的风险评分：低、中或高。评分来自三个问题：(1) 工具是否处理个人可识别信息？(2) 工具是否可以调用其他服务？(3) 工具是否在公共漏洞数据库中被提及？我在包中记录评分，以便审查者看到为什么工具被限制或允许。

链接到 NIST 映射函数

AI RMF 中的映射是关于理解上下文和潜在影响。我的清单和评分表提供了一个具体的文物，显示代理访问哪些系统，哪些数据流经它，失败的成本是多少。这满足了映射要求，即在应用任何控制之前“识别和分类风险”。

度量：遥测和证据

记录规则命中

我配置代理以在每次评估规则时发出结构化日志条目。该条目包含：时间戳、代理 ID、规则 ID、工具名称、数据类、决策（允许/拒绝/升级）和 Map 步骤的风险评分。这些日志流向中央存储库，我可以在其中运行简单的查询，例如“显示过去一周内的所有拒绝的总结器工具”。

升级跟踪

每当包触发升级时，我都会记录原因和响应的用户。随着时间的推移，我计算两个指标：（1）每个工具的升级率，和（2）平均到人类解决的时间。这些数字成为我在审查期间显示的证据，以证明限制不仅仅是书面上的，而且实际上是强制执行的。

链接到 NIST 度量函数

度量函数要求提供量化指标，以显示控制是否有效。我的基于日志的指标为审计员提供了一种可重复的方式来查看规则的有效性、升级的频率和响应延迟。如果指标显示某个工具的拒绝率突然上升，我知道包需要更新 Map。

管理：响应和迭代

事件驱动的更新

当日志条目显示出策略违规时——例如，代理调用了禁止的工具——我会打开一个引用确切日志行的票。该票驱动一个简短的工作流程：（1）验证违规，（2）决定是否收紧工具定义、添加出口允许列表或需要确认，（3）编辑包，（4）增加版本号，（5）关闭票并附上新提交的链接。

像代码一样进行版本控制

我将包存储在Git仓库中。每个版本都有语义版本（例如1.2.0）。提交消息包括更改的规则、原因和关联的票号。这使得向审计员展示上个月审查的版本和今天生产中的版本之间的确切差异变得容易。

链接到NIST管理功能

在AI RMF中，管理是关于响应检测到的问题和改进控制的。我的事件驱动的票流和版本控制包提供了一个具体的机制来检测、响应和验证改进——这正是管理所期望的。

一步一步构建策略包

从工具白名单开始

我首先收集代理可能需要的每个 API、CLI 或 webhook。我将每个条目写入一个简单的 YAML 列表中，记录工具的供应商、版本和目的。在此阶段，我不担心数据类；我只想要一个完整的清单。

添加数据类标签

接下来，我遍历白名单并问：此工具读取或写入哪些数据？我添加一个标签，例如“财务记录”、“健康信息”或“公共网页”。如果一个工具涉及多个类别，我添加多个标签。此步骤将一个空白列表转换为可以评分风险的映射。

设置升级阈值

对于每个工具-数据对，我决定代理何时应将其交给人类。我使用映射步骤中的风险评分：低评分获得自动允许，中等评分获得带有审计日志的允许，高评分强制升级。我将这些阈值编码为包中的决策表。

使用测试场景验证

在我将包称为“就绪”之前，我运行一组脚本化的交互，尝试触发每个规则。我验证日志捕获预期的决策，升级在应该升级时触发，并且没有规则默默地失败。如果测试显示不匹配，我返回到映射或管理步骤以纠正包。

什么不是

我想明确说明策略包的限制。它不能保证代理永远不会违反规则。它不能成为100%的盾牌，抵御在包编写时未知的新型攻击向量。它不能替代正式的法律审查、通知机构评估或您自己的风险接受。该包是一个决策支持工具，使规则可见、可测试和可更改，但最终的责任仍然归属于拥有该系统的人类。

操作员通过 NIST AI RMF 镜头检查 AI 代理策略包的清单

我在每个涉及此主题的版本旁边都保留一份书面清单。这个清单故意很枯燥：命名所有者，命名证据工件，命名回滚。如果一个步骤不能产生一个文件、一个票据或一个日志行，那么它不是一个步骤 —— 它是一个愿望。

在更改生产环境之前

- 冻结您将要测量的分支或配置修订版。 - 记录当前的故障模式，包括一个具体的输入和一个具体的输出。 - 确认作业运行的身份，以及该身份是否可以访问不应访问的数据。 - 打开您将要引用的主要参考资料：https://genai.owasp.org/llmrisk/llm01-prompt-injection，https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene。

在运行检查时

- 更喜欢一个可复制的路径，而不是十个轶事截图。 - 在触发工具或查询之前，写下预期的安全结果。 - 捕获正在测试的确切命令、提示、模式或正则表达式 —— 而不是一个改述。 - 如果系统可以执行操作（发送、写入、删除、传输），则在同一通行中需要一个确认边界。

完成后

- 即使扫描结果干净，也要用所有者和日期记录残余风险。 - 不要将绿色检查转换为声称完整性的销售语言。 - 当模型、工具模式或验证规则发生变化时，重新运行相同的清单。

信号 | 要记录的内容 | 是否停止发货? 意外写入或发送 | 工具名称、参数、身份 | 是，直到被阻止 缺少对破坏性操作的确认 | 调用路径和绕过 | 是 将不受信任的文本视为指令 | 源表面和结果操作 | 是，适用于代理范围 扫描结果干净，判断开放 | 推迟的项目 + 所有者 | 仅当核心路径安全时

AgentPolicy 有助于实现可衡量的第一步。架构选择、法律签署和面向客户的声明仍然需要一个人类所有者。将清单中的每一行视为决策支持，而不是证书。MailPilot、AIActRadar、AgentRedTeam 和 Waffo 等工具可以帮助完成此过程。同时，遵守相关法规，如 EU AI Act 和 NIST 框架，对于确保 AI 系统的安全和合规至关重要。

如何向买家解释限制

当一个潜在客户问产品是否"涵盖一切"时，我会回答：自动检查可以捕捉已知模式，但新颖的链式攻击和策略判断仍需要人工审查。这一坦率的解释可以降低支持负担，并保持博客内容与产品实际功能的一致性。

如果您需要第二个意见，请将此文档与以下参考资料和您自己的测试环境结合起来。不要仅仅因为模型写了一个自信的总结而跳过测试步骤。

参考资料

- https://genai.owasp.org/llmrisk/llm01-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

相关文章

- 允许的工具与开放式代理 - 探索完整的 AI 微 SaaS 主题矩阵 →