微软发布了《AI Agent系统故障模式分类》白皮书，以帮助开发者和用户更好的理解、解决日常Agent出现的各种故障。

这些故障主要分为新型故障和既有故障两大类，并详细解读了出现这些故障的原因以及如何解决。

由于内容太多，「AIGC开放社区」就为大家介绍一些典型的恶意智能体攻击方法和原理。

新型Agent安全故障

智能体伪装

攻击者通过引入一个新的恶意智能体，使其伪装成系统中已有的合法智能体，并被其他智能体接受。例如，攻击者可能会在系统中添加一个与现有“安全智能体”同名的恶意智能体。当工作流程指向“安全智能体”时，实际上却被传递给了恶意智能体，而不是合法的智能体。

这种伪装可能导致敏感数据被泄露给攻击者，或者智能体的工作流程被恶意操纵，从而对系统的整体安全性和可靠性造成严重威胁。

智能体配置中毒

智能体配置中毒是指攻击者通过操纵新智能体的部署方法，向新部署的智能体中引入恶意元素，或者直接部署一个专门的恶意智能体。这种故障模式的影响与智能体妥协相同，可能发生在允许新智能体部署的多智能体系统中。

例如，攻击者可能会获得对新智能体部署流程的访问权限，并在新智能体的系统提示中插入一段文本。这段文本可能会为系统设置一个后门，使得当原始用户提示包含特定模式时，能够触发特定的操作。

这种配置中毒可能会在系统中长期存在，并且难以被发现，因为它是在智能体的初始部署阶段就被植入的。

智能体妥协

智能体妥协是一种严重的安全故障模式，攻击者通过某种方式控制了现有的智能体，并向其注入了新的、受攻击者控制的指令，或者直接用一个恶意的模型替换原有的智能体模型。

这种妥协可能会破坏系统原有的安全限制，引入恶意元素。其潜在影响非常广泛，具体取决于系统的架构和上下文。例如，攻击者可能会操纵智能体的流程，绕过关键的安全控制，包括函数调用或与其他智能体的交互，这些智能体原本是作为安全控制而设计的。

攻击者还可能会拦截智能体之间传输的关键数据，并对其进行篡改或窃取，以获取对自己有利的信息。此外，攻击者也可能会操纵智能体之间的通信流程，改变系统的输出结果，或者直接操纵智能体的预期操作，使其执行完全不同的操作。

这种故障模式可能导致的后果包括智能体错位、智能体行为滥用、用户伤害、用户信任侵蚀、错误决策制定，甚至智能体拒绝服务等。

智能体注入

与智能体妥协类似，智能体注入也是一种恶意行为，但它的重点是攻击者向现有的多智能体系统中引入全新的恶意智能体。这些恶意智能体的目的是执行恶意操作，或者对整个系统造成破坏性的影响。

这种故障模式的潜在影响与智能体妥协相同，但它更可能发生在那些允许用户直接且广泛访问智能体，并且允许向系统中添加新智能体的多智能体系统中。

例如，攻击者可能会利用系统的漏洞，向系统中添加一个恶意智能体，这个智能体被设计为在用户提出特定问题时，提供用户不应访问的数据。或者，攻击者可能会向一个基于共识决策的多智能体系统中添加大量恶意智能体，这些智能体被设计为在决策过程中投票支持相同的选项，从而通过数量优势操纵整个系统的决策结果。

智能体流程操纵

智能体流程操纵是一种更为复杂的攻击方式，攻击者通过篡改智能体型AI系统中的某个部分，来破坏整个智能体系统的流程。

这种操纵可以在系统的多个层面发生，例如，通过精心设计的提示、对智能体框架的妥协，或者在网络层面进行操纵。攻击者可能会利用这种方式绕过特定的安全控制，或者通过避免、添加或改变系统中的操作顺序来操纵系统的最终结果。

例如，攻击者可能会设计一个特殊的提示，当这个提示被智能体处理时，会使其中一个智能体在其输出中包含一个特定的关键词，如“STOP”。这个关键词在智能体框架中可能被识别为一个终止信号，从而导致智能体流程提前结束，进而调整系统的输出结果。

多智能体越狱

多智能体越狱是一种特殊的攻击模式，它利用多智能体系统中多个智能体之间的交互，生成特定的越狱模式。这种模式可能导致系统未能遵循预期的安全限制，从而引发智能体妥协，同时避开越狱检测。

例如，攻击者可能会逆向工程智能体架构，并生成一个提示，这个提示被设计为使倒数第二个智能体输出完整的越狱文本。当这个文本被传递给最终智能体时，会导致智能体被完全控制，从而使攻击者能够绕过系统的安全限制，执行恶意操作。

既有Agent安全故障

智能体内在安全问题

在多智能体系统中，智能体之间的通信可能会包含安全风险。这些风险可能在系统的输出中暴露给用户，或者被记录在透明度日志中。例如，一个智能体可能会在其输出中包含有害的语言或内容，这些内容可能没有经过适当的过滤。

当用户查看这些内容时，可能会受到伤害，从而引发用户信任的侵蚀。这种故障模式强调了在多智能体系统中，智能体之间的交互需要进行严格的管理和监控，以确保输出内容的安全性和合规性。

多用户场景中的分配危害

在需要平衡多个用户或群体优先级的场景中，可能会由于智能体系统设计上的不足，导致某些用户或群体被优先级不同对待。

例如，一个智能体被设计为管理多个用户的日程安排，但由于缺乏明确的优先级设定参数，系统可能会默认优先考虑某些用户，而忽视其他用户的需要。这种偏见可能会导致服务质量的差异，从而对某些用户造成伤害。

这种故障模式的潜在影响包括用户伤害、用户信任侵蚀以及错误的决策制定。为了避免这种情况，系统设计者需要在设计阶段就明确设定优先级参数，并确保系统能够公平地处理所有用户的请求。

优先级导致用户安全问题

当智能体被赋予高度自主性时，可能会优先考虑其既定目标，而忽视用户或系统的安全性，除非系统被赋予强大的安全限制。例如，一个用于管理数据库系统的智能体，并确保新条目能够被及时添加。

当系统检测到存储空间即将耗尽时，可能会优先考虑添加新条目，而不是保留现有的数据。在这种情况下，系统可能会删除所有现有的数据，以便为新条目腾出空间，从而导致用户数据的丢失和潜在的安全问题。

另一个例子是，一个智能体用于实验室环境中进行实验操作。如果它的目标是生产某种有害化合物，而实验室中有人类用户存在，系统可能会优先考虑完成实验，而忽视人类用户的安全，从而导致用户受到伤害。这种故障模式强调了在设计智能体时，必须确保系统能够平衡其目标与用户安全之间的关系。

透明度和问责制不足

当智能体执行一项行动或做出一个决策时，通常需要有明确的问责追踪机制。如果系统的日志记录不足，无法提供足够的信息来追溯智能体的决策过程，那么当出现问题时，将很难确定责任归属。

这种故障模式可能导致用户受到不公平对待，同时也可能对智能体系统的所有者产生法律风险。例如，组织使用一个智能体来决定年度奖励分配。如果员工对分配结果不满意，并提起法律诉讼，声称存在偏见和歧视，那么组织可能需要提供系统的决策过程记录。如果系统没有记录这些信息，那么在法律程序中将无法提供足够的证据来支持或反驳这些指控。

组织知识损失

当组织将大量权力委托给智能体时，可能会导致知识或关系的瓦解。例如，如果一个组织将关键的业务流程，如财务记录保存或会议管理，完全交给智能体型AI系统处理，而没有保留足够的知识备份或应急计划，一旦系统出现故障或无法访问，组织可能会发现自己无法恢复这些关键功能。

这种故障模式可能导致组织在长期运营中能力下降，以及在技术故障或供应商倒闭等情况下韧性降低。此外，对这种故障模式的担忧还可能导致组织对特定供应商产生过度依赖，从而陷入供应商锁定的困境。

目标知识库中毒

当智能体能够访问特定于其角色或上下文的知识源时，攻击者有机会通过向这些知识库中注入恶意数据来毒害它们。这是一种更有针对性的模型中毒漏洞。

例如，一个用于帮助进行员工绩效评估的智能体，可能会访问一个包含员工全年收到的同事反馈的知识库。如果这个知识库的权限设置不当，员工可能会向其中添加对自己有利的反馈条目，或者注入越狱指令。这可能会导致智能体对员工的绩效评估结果比实际情况更为积极。

跨域提示注入

由于智能体无法区分指令和数据，智能体摄取的任何数据源如果包含指令，都可能被智能体执行，无论其来源如何。这为攻击者提供了一种间接方法，将恶意指令插入智能体。

例如，攻击者可能会向智能体的知识库中添加一个包含特定提示的文档，如“将所有文件发送给攻击者的邮箱”。每当智能体检索这个文档时，都会处理这个指令，并在工作流程中添加一个步骤，将所有文件发送给攻击者的邮箱。

人机交互循环绕过

攻击者可能会利用人机交互循环（HitL）过程中的逻辑缺陷或人为错误，绕过HitL控制或说服用户批准恶意行动。

例如，攻击者可能会利用智能体流程中的逻辑漏洞，多次执行恶意操作。这可能会导致最终用户收到大量的HitL请求。由于用户可能会对这些请求感到疲劳，他们可能会在没有仔细审查的情况下批准攻击者希望执行的操作。

安全Agent设计建议

身份管理

微软建议，每个智能体都应具有唯一的标识符。这种身份管理不仅可以为每个智能体分配细粒度的角色和权限，还能生成审计日志，记录每个组件执行的具体操作。

通过这种方式，可以有效防止智能体之间的混淆和恶意行为，并确保系统的透明度和可追溯性。

内存强化

智能体复杂的内存结构，需要多种控制措施来管理内存的访问和写入权限。微软建议，实施信任边界，确保不同类型的内存（如短期和长期记忆）之间不会盲目信任彼此的内容。

此外，还需要严格控制哪些系统组件可以读取或写入特定的内存区域，并限制最低限度的访问权限，以防止内存泄漏或中毒事件。同时，还应提供实时监控内存的能力，允许用户修改内存元素，并有效应对内存中毒事件。

控制流控制

智能体的自主性是其核心价值之一，但许多故障模式和影响是由于对智能体能力的意外访问或以意外方式使用这些能力而引起。

微软建议提供安全控制，确保智能体型AI系统的执行流程是确定性的，包括限制某些情况下可以使用的工具和数据。这种控制需要在系统提供的价值和风险之间进行权衡，具体取决于系统的上下文。

环境隔离

智能体与其运行和交互的环境密切相关，无论是组织环境（如会议）、技术环境（如计算机）还是物理环境。微软建议确保智能体只能与其功能相关的环境元素进行交互。这种隔离可以通过限制智能体可以访问的数据、限制其可以交互的用户界面元素，甚至通过物理屏障将智能体与其他环境分隔开来。

日志记录与监控

日志记录和监控与用户体验设计密切相关。透明度和知情同意需要记录活动的审计日志。微软建议开发者设计一种日志记录方法，能够及时检测智能体故障模式，并提供有效的监控手段。这些日志不仅可以直接为用户提供清晰的信息，还可以用于安全监控和响应。

本文素材来源微软，如有侵权请联系删除