章
目
录
随着大语言模型（LLM）的发展，相关应用不断拓展，RAG（检索增强生成）技术在实现上下文感知回答方面表现出色，但当人们期望LLM应用能自主执行任务时，RAG就显得力不从心了。这时，AI Agent应运而生。本文将基于“Understanding AI Agent Security”的相关内容，深入探讨AI Agent的功能、架构、安全风险以及应对这些风险的最佳实践。
一、AI Agent究竟是什么？
LLM Agent本质上是一种能够根据具体情况动态规划执行流程，以完成特定任务的系统。与那些执行步骤在代码中预先设定好的工作流不同，Agent具备自主性，还拥有一定的知识储备，这使得它能够依据输入信息做出细致且合理的决策。
当前，市场上涌现出了一批新型Agent系统，不少初创公司借助它们来解决复杂的行业问题。尽管这些系统可能有着诸如“AI助手”“AI协作伙伴”等不同的称呼，但其核心原理是一致的：都是由模型驱动，具备自主执行任务的能力。
从根本上来说，Agent系统要正常运作，需要具备四项基本能力：具有推理和规划能力的模型、检索机制、工具和API、记忆系统。
二、AI Agent的核心组件
（一）推理和规划
Agent在接到任务后，需要对问题进行评估，进而确定达成目标所需的行动步骤。这个过程涉及到对上下文的理解、将复杂任务拆解以及规划出最优的行动顺序。并非所有的模型都具备这样的推理和规划能力，所以在构建AI Agent时，选择能够匹配任务复杂程度的模型至关重要。
（二）工具
为了完成任务，AI Agent需要调用各种工具。这些工具的复杂程度不一，简单的可能只是一个Python函数，复杂的则可能是第三方API或者数据库查询操作。在创建AI Agent时，要将这些工具注册到Agent中。
值得注意的是，为Agent提供工具并不意味着它每次响应都会调用这些工具。可以通过设计，让AI Agent具备“推理”能力，自主判断是否需要调用工具。对于部分模型，甚至还能强制其调用特定函数。
以Anthropic的客服Agent为例，用户发送消息后，会触发LLM进行思考。该LLM可以使用三个客户端工具：get_customer_info（用于获取客户信息）、get_order_details（获取订单详情）和cancel_order（取消订单）。它会根据用户消息的内容，判断应该使用哪个工具来执行任务。
# 以下是测试客服聊天机器人的代码示例
def chatbot_interaction(query):
# 此处省略具体实现逻辑，仅为示意
pass
chatbot_interaction("Can you tell me the email address for customer C1?")
chatbot_interaction("What is the status of order 02?")
chatbot_interaction("Please cancel order 01 for me.")
当用户询问“Can you tell me the email address for customer C1?”时，LLM经过分析，确定调用get_customer_info函数，并返回相应的结构化响应。
User Message: Can you tell me the email address for customer C1?
Stop Reason: tool_use
Initial Response:
Content: [ContentBlock(text='<thinking>The get_customer_info function retrieves a customerl's name, email, and pho ne number given their customer ID. To call this function, I need the customer_id parameter. The user provided the customer ID "C1" in their request, so I have the necessary information to make the API call.</thinking>', type='te xt'), ContentBlockToolUse(id='toolu_θ19F9JHokMkJ1dHw5BEh28sA', input={'customer_id':'c1'),name='get_customer_inf
0', type='tool_use')]
Tool Used: get_customer_info
Tool Input: {
} "customer_id":"C1"
Tool Result: { "name":"John Doe",
} "email":"john@example. com", "phone":"123-456-7890"
Response: Stop Reason: end_turn
Content: [ContentBlock(text='The email address for customer C1 (John Doe) is johnexample.com.', type='text')]
Final Response: The email address for customer C1 (John Doe) is john@example. com.
（三）记忆
由于LLM架构本身是无状态的，为了弥补这一缺陷，AI Agent需要借助记忆功能。通常，AI Agent会使用两种记忆类型：
- 短期记忆：用于记录当前对话的相关信息，包括对话历史以及任务上下文，方便Agent在当前交互过程中更好地理解和响应。
- 长期记忆：主要存储AI Agent的知识，涵盖世界知识和任务知识等，为其执行任务提供更广泛的知识支撑。
（四）检索和知识
检索是AI Agent从知识源获取信息的过程，常见的知识源如向量数据库。在执行任务时，AI Agent可能需要从向量数据库中检索相关信息，这些信息既可以是完成任务所必需的，也可能是有助于提升任务完成质量的。此外，AI Agent还可能被赋予访问SQL数据库等其他数据库的权限，以便获取用户或其他Agent请求的数据。
三、AI Agent的架构类型
（一）单Agent架构
这种架构适用于任务流程明确、使用工具范围较窄的场景。在与单Agent交互时，它会按照顺序依次规划和执行任务，即前一步操作完成后，才会进行下一步。
（二）多Agent架构
多Agent系统更适合处理需要多视角分析或并行处理的任务，主要有以下两种组织方式：
- 水平层级：该层级下，Agent之间没有明确的领导关系，它们通过协作完成任务。这种方式在需要大量反馈的任务中表现出色，但可能会出现Agent之间沟通无重点、产生“闲聊”的情况。
- 垂直层级：在这种层级结构中，存在一个领导Agent，其他Agent作为辅助。分工明确，能有效减少干扰，但可能会面临沟通瓶颈的问题。
四、AI Agent面临的安全风险
AI Agent在为人们带来便利的同时，也存在诸多安全风险。除了RAG架构常见的如访问控制缺陷、数据投毒和提示注入等风险外，还面临一些特有的安全威胁。
（一）Agent劫持
“Agent劫持”是针对Agent系统的一种新型且危害较大的风险。它实际上是一种链式攻击，需要多个漏洞同时存在才会构成严重威胁。一方面，AI Agent存在基本配置错误，使得其拥有过度的权限或自主权；另一方面，存在来自不可信用户输入的直接或间接提示注入。当这两个条件同时满足时，AI Agent就可能被“劫持”，进而执行用户的恶意命令。
直接提示注入通常发生在用户直接与AI Agent交互（如通过聊天机器人）时，用户在输入内容中包含恶意指令，绕过LLM系统原本的设计意图。而间接提示注入则是通过污染LLM Agent的检索系统实现的，比如在RAG知识库中混入被污染的文档，当LLM检索时就会受到影响。一旦过度Agent权限和提示注入攻击相结合，AI Agent就可能会做出非预期或恶意的行为，比如代表攻击者发送精心设计的钓鱼邮件、越权获取并向用户提供未经授权的数据，或者给用户传递恶意、非法的信息。
（二）Agent权限过高
如果AI Agent拥有过度的访问权限，比如对工具、API和数据库的访问不受限制，那么就可能会导致严重的数据泄露问题，使敏感信息被披露。此外，如果没有设置速率限制和对输入进行净化处理，还可能引发对数据库和API的无限消耗攻击。这种情况的出现，主要是因为授权机制不完善、工具调用限制过于宽松以及缺乏有效的输入净化措施。例如，在AI Agent中，若提示没有经过净化，且Agent对数据库有不受限的访问权，它就有可能执行SQL命令，将数据库内容全部导出。
（三）拒绝付费（DoW）攻击
从设计原理来看，AI Agent执行任务需要更复杂的推理和规划过程，这使得其计算成本比用于简单聊天的模型更高。以OpenAI的某些推理模型为例，其推理成本几乎比gpt – 4o高出150%。如果一些用户恶意利用公司的Agent系统，比如诱导Agent推理出现循环，或者让其执行不必要的任务，就会导致公司收到来自推理提供商的高额账单。
（四）多轮对话攻击
并非所有攻击都能通过一次提示完成。LLM Agent可能会受到多步攻击，攻击者通过一系列的对话，逐步引导Agent完成攻击。这种多轮、对话式的攻击策略在诱导Agent生成有害输出，或者在有状态应用中执行恶意任务方面非常有效，攻击者可以通过逐步影响，让AI Agent在不知不觉中违背其原本的设计目的。常见的如GOAT和Crescendo策略。
（五）无意（但有害）的行为
即使AI Agent没有恶意意图，也可能会因为配置错误或其他原因，无意中做出有害的行为。比如，一个编码Agent如果配置不当，可能会将不安全的代码提交到生产环境，这可能会破坏平台的正常运行，导致敏感数据（如API令牌）泄露，甚至引入被攻击者利用的安全隐患。
在客户服务领域，AI Agent也可能会出现失误，例如承诺错误的价格，而公司可能不得不为此承担后果；或者提供错误的公司政策信息，依据给定事实得出错误结论等。此外，AI Agent还容易受到欺诈行为的影响，比如攻击者谎称未收到包裹，诱导Agent调用工具取消递送或进行退款操作。
（六）传统越狱
AI Agent并不能免疫传统的越狱攻击。除了上述提到的各种漏洞外，它仍然容易受到针对基础模型的越狱尝试的影响。这种攻击可能会迫使Agent披露有害信息，或者绕过原本设置的安全防护机制。需要明确的是，部署Agent系统不仅无法消除简单LLM系统存在的漏洞，反而会因为其多层架构增加安全风险。因此，AI Agent同样需要具备针对对话AI或基础模型的深度防御措施，如红队测试和设置安全护栏等。
五、AI Agent安全最佳实践
在保障AI Agent安全方面，可以借鉴安全团队管理组织内员工访问控制的思路。AI Agent如同人类员工一样，依据自身的工作记忆、可用工具以及可获取的知识源来做出决策和执行任务。和员工类似，AI Agent通常也期望能够顺利完成任务，但也存在犯错、泄露信息或者遭受社会工程攻击的风险。
（一）工具清单管理
要详细记录AI Agent能够访问的工具、函数、API和数据库，明确列出AI Agent预期执行的任务，以及借助这些工具需要达成的目标。同时，根据授权任务的类型（如读取、写入、删除等）、数据的敏感程度（机密、高敏感、PHI、PCI、PII等）和暴露范围（公开、内部），对AI Agent的风险等级进行评估和记录。
（二）最小权限授权
严格限制AI Agent使用工具的权限。例如，如果AI Agent仅需在数据库上执行查询操作，就不应赋予其删除、新建或删表的权限，最好将其操作限制在预设查询或准备好的语句范围内。同时，也要严格管控能够访问AI Agent工具的用户权限，对AI Agent的访问进行限制，一旦发现异常，及时终止访问。
（三）输入输出净化
对AI Agent接收的提示和输出的内容都要进行严格的验证和净化处理。可以部署数据泄漏防护技术，降低敏感信息泄露的风险。在API请求方面，实施签名验证，防止请求被篡改。
（四）系统提示配置
要将系统提示中的所有信息视为公开内容，严格将私有数据与提示上下文隔离开来。禁止AI Agent透露提示或上下文信息，并设置相应的防护机制。
（五）Agent沙箱化
将AI Agent放置在安全隔离的环境中，限制其对资源和功能的访问。使其与生产环境和网络分开，这样可以有效降低遭受SSRF（服务器端请求伪造）攻击的风险。
（六）制定AI行为准则
联合法律、营销、合规和安全等多个团队，共同建立并执行AI行为准则。通过开展红队测试，确保AI Agent不会违反行为准则或其他相关治理政策。
（七）监控和预警
为AI Agent搭建完善的监控预警系统，实时检测其异常行为。同时，引入适用于其他系统或员工的辅助控制措施，比如欺诈预警机制和针对敏感交易的多因素认证等。
AI Agent作为一种新兴的技术应用，在带来便利的同时，也伴随着诸多安全风险。通过深入了解其功能、架构，以及采取相应的安全最佳实践，能够在一定程度上降低风险，保障系统的安全稳定运行。
