确定自治代理 AI 系统的风险

支柱名称:监视和检测威胁
模式名称:降低自治代理 AI 系统风险

上下文和问题

自治代理 AI 系统可以计划、执行和调整目标操作,而不是响应单个提示。 由于它们可能会调用工具、调用 API、访问数据以及跨服务协调,因此它们可以在有限的人工干预下产生真实效果。 这种自主性放大了错误的影响,并使系统对对手更具吸引力。 每个代理到工具、代理到服务和代理到代理交互都会扩展攻击面,并可能会带来 间接提示注入攻击、意外操作或数据外泄等风险。

在自治代理 AI 系统中通常会出现以下风险(虽然并不详尽)。

设计风险

  • 任务符合性: 代理执行的操作与用户的预期任务、计划或目标不一致。
  • 人工监督和控制: 系统缺少用户评审、审批、更正或自主行为的中断有意义的要点。
  • 系统可理解性: 用户无法了解代理正在执行的操作、计划执行或已执行的操作。
  • 透明度和披露: 用户或下游收件人不知道他们正在与 AI 系统交互或遇到 AI 生成的操作/输出。

安全风险

  • 代理劫持: 由于数据和指令之间的边界模糊,恶意或不受信任的输入劫持工具调用。
  • 敏感数据泄露: 机密、专有或个人数据通过输出、日志、内存或下游操作公开。
  • 供应链泄露: 漏洞是通过模型、工具、插件、地面数据或其他代理依赖项引入的。
  • 代理蔓延: 非托管或过度许可的代理激增,增加安全风险,减少 IT 监督。

解决这些风险需要 基本设计原则特定于风险的缓解措施,这些缓解措施在代理生命周期中一致地应用。

解决方案

通过将基础设计支柱(代理的行为方式和用户如何保持控制)与有针对性的安全和治理缓解(系统如何抵御攻击和安全缩放)相结合,降低自主代理 AI 系统的风险。 以下支柱构成了应对这些威胁的负责任的代理系统设计的基础。 它们适用于所有代理用例,并帮助同时缓解多个风险。

基础设计支柱

任务符合性

当代理执行的操作与用户的任务、计划或目标不完全符合时,就会出现任务遵循不足的情况。 代理可能误解意图、跳过所需的步骤,或追求用户未授权的推断目标。

若要管理此风险,

  • 定义明确的系统用途和边界,以便代理可靠地解释意向并仅执行预期操作。
  • 无论模型输出如何,使用确定性控件来阻止禁止的操作。
  • 应用最小特权和最小操作。 仅允许所需的最低工具、数据和操作。 默认情况下,拒绝其他所有内容。
  • 传达涉及高风险的任务以及系统如何处理这些风险,以防止过度依赖。

人工监督和控制

人工监督意味着为用户提供有意义的控制来指导、正确和中断自治行为,尤其是在输入不明确、操作影响很大或可能进行对抗操作时。

若要管理此风险,

  • 让用户为代理可以访问、执行和记住的内容设置边界。
  • 需要批准高风险或不可逆的操作。
  • 提供可靠的系统级机制,以安全、立即地暂停或停止代理。
  • 在整个执行中一致地强制实施组织策略和用户首选项。

AI 系统可理解性

可理解性指的是系统展示其计划的执行操作,并在执行期间提供反馈,并总结实际发生的情况,包括所用的工具和数据。 如果没有可见性,用户将无法撤消错误、响应事件或改进结果。

为系统可理解性进行设计:

  • 在执行前显示计划的操作,尤其是对于高风险或不可逆的步骤。
  • 提供实时状态和进度,以便用户可以跟踪其展开时的行为。
  • 总结结果:发生了什么、关键决策以及代理人为实现目标所使用的手段。
  • 维护可访问的执行后日志,用于记录审核和事件响应的操作、工具和结果。

透明度和披露

自治代理系统可能会在幕后采取行动,并影响未启动交互的人。 明确披露设置预期,减少混淆,并支持更安全的使用。

若要使交互透明且易于理解:

  • 清楚地指示用户何时与 AI 系统交互,尤其是在高风险域或下游上下文中。
  • 解释系统的目的、边界以及它可以和不能执行的操作。
  • 表面限制和不确定性,以便用户可以适当校准信任。
  • 确保下游收件人可以识别 AI 生成的输出或操作并了解其来源。

系统安全性和治理风险

代理劫持

当恶意或不受信任的输入操作代理推理或工具执行时,会发生代理劫持。 在代理系统中,数据与指令之间的不明确分离可以允许跨提示注入攻击重定向工具调用或工作流。

若要管理代理劫持的风险,请执行以下操作:

  • 默认情况下,将所有外部输入(包括检索的内容和工具输出)视为不受信任。
  • 强制严格分离指令、数据、内存和工具参数。
  • 过滤输入以检测和阻止恶意模式,防止其到达代理的推理或工具的执行路径。
  • 在执行之前,实现 allowlist 工具并确定性地验证参数。
  • 通过将代理的行为建立在显式、系统定义的规则上,而不是推断的意图中,最大程度地减少隐式指令遵循。

敏感数据泄露

当机密、专有或个人信息通过输出、日志、内存或下游操作公开时,将发生敏感数据泄漏。 当代理跨多个源聚合或保留长期上下文时,风险会增加。

管理敏感数据泄露的风险:

  • 将最低特权应用于代理标识和数据源,仅授予当前任务的访问权限。
  • 对敏感数据进行分类和管理,并强制实施使用、保留和输出的确定性规则。
  • 限制长期存在的内存,并仅保留必要且明确管理的部分。
  • 监视和筛选输出和日志,以检测和防止未经授权的泄露。

供应链泄露

通过模型、工具、插件、地面数据或其他依赖项引入漏洞时,会发生供应链泄露。 任何组件的弱点都可以传播到自主决策和执行中。

若要缓解供应链风险,请执行以下操作:

  • 清点代理使用的所有模型、工具、插件和数据源,并将其作为安全边界的一部分进行查看。
  • 应用版本控制和更改控制,以便更新是有意和可审查的。
  • 隔离组件以减少爆炸半径并防止级联故障。
  • 监视可能指示依赖项泄露或数据中毒的异常情况。
  • 假设各个组件可能会失败并相应地设计补偿控件。

代理扩散

代理泛滥是指未管理或权限过多的代理不受控制地激增。 蔓延扩大攻击面,削弱最低特权,减少问责和 IT 监督。

若要减少代理扩散,请执行下列步骤:

  • 清点代理使用的所有模型、工具、插件和数据源,并将其作为安全边界的一部分进行查看。
  • 为每个代理(包括负责任的团队或个人)建立明确的所有权和责任。
  • 强制实施代理生命周期治理,包括注册、审批、过期和停用。
  • 默认情况下,应用最低权限,仅向每个代理授予其角色所需的最低权限、工具和数据访问权限。
  • 将唯一的可审核标识分配给代理,以启用授权、策略强制和可跟踪性。

Guidance

寻求采用此模式的组织可以应用以下可操作的做法。

练习类别 建议的操作 资源
共同责任 人为监督使组织能够对代理人的行为保持问责 人工智能(AI)共同责任模型
模型选项 模型选择是代理系统中的基线控制和关键供应链决策。 有意的模型选择解锁更安全、更智能的代理 Microsoft Foundry 模型目录
内容安全与任务遵循 检测和阻止恶意或操控性输入,包括间接的提示注入攻击 Microsoft Foundry 风险和安全评估器
滥用监视 监视滥用模式、重复绕过尝试或异常代理行为 Microsoft Foundry Azure OpenAI 滥用监控
代理标识 强制实施最低特权、隔离、生命周期管理和可审核性以防止代理蔓延 Microsoft Entra 代理ID
依赖治理 清单、验证、版本和监视代理使用的模型、工具、插件和数据源 Microsoft Foundry 模型目录
以人为中心的设计 让用户了解代理的功能和限制、人工监督以及减少滥用和过度滥用 安全设计 UX 工具包

结果

优点

  • 代理仅在定义的意向、权限和边界内执行。
  • 用户可以查看、批准和中断高风险操作。
  • 系统行为可通过明确的计划、反馈和日志进行观察和审核。
  • 通过最小权限、治理和监控来减少敏感数据的暴露。
  • 随着代理的使用在团队和工具之间扩大,组织可以保持可见性和控制力。
  • 用户生成和维护对系统行为的信任。

权衡

  • 构建确定性安全措施、监督和日志记录需要额外的设计和工程工作。
  • 多代理系统增加了复杂性,并增加了意外交互和结果的机会。
  • 明确披露和可理解性需要有意的 UX 计划,并可能会给工作流增加摩擦。

关键成功因素

  • 任务符合性: 代理按预期执行操作。
  • 人类参与: 人类仍然对高影响或模棱两可的代理操作负责。
  • 确定性安全措施: 无论模型行为如何,禁止的操作都会可靠地被阻止。
  • 透明度和披露: 用户和下游收件人了解代理何时采取行动以及他们使用的内容。
  • 代理劫持: 代理具有分层防御,以减轻间接指令注入风险,专门监视相关事件,并配置安全关闭机制。
  • 最低特权和治理: 代理标识、权限和生命周期是为了防止蔓延而管理的。
  • 供应链意识: 模型、工具和数据源被视为安全依赖项。

总结

自治代理 AI 系统扩展了支持 AI 的软件可以执行的操作,但它们的自主性扩大了风险。 基础设计原则 - 任务遵循、人工监督、系统可理解性和披露 - 有助于使代理与设计意图保持一致,用户保持控制。 系统性风险(如代理劫持、敏感数据泄露、供应链泄露和代理蔓延)需要以最低特权、确定性防护措施、治理和监视为基础的有针对性的缓解措施。 通过分层防御和明确责任,组织可以设计和扩展自主、可观察和具有弹性的主体性系统。