Gartner发布AI代理安全保护指南：保护 AI 代理的六个关键步骤和举措

随着企业投资自主开发的生成式 AI 应用程序以实现企业自动化，AI 代理正在兴起。网络安全领导者应采用安全开发和运行时安全实践来处理定制 AI 代理带来的新攻击面和风险。

主要发现

• 虽然人工智能代理的数量不断增加，但提供商和组织倾向于将每个新的自动化功能或工具都称为“人工智能代理”。尽管有些代理确实使用生成式人工智能来规划和采取自主行动，但许多代理给网络安全领导者带来的困惑比增加真正的代理风险还要多。

• AI 代理倾向于继承用户的权限。尽管某些操作受到技术控制的抑制，而其他操作则受到安全策略中概述的逻辑控制的抑制，但与人类不同，代理缺乏遵循逻辑安全策略的动机。

• AI 代理通常通过API 和 UI 抓取访问资源，类似于现代应用程序和 RPA 机器人。虽然 RPA 和 AI 代理都模仿、重复或取代人类行为，但代理行为是概率性的，难以锁定，并且通常不限于结构化数据。

建议

• 执行AI 代理发现，结合流量检查、API 调用监控和代码存储库分析，根据“代理”级别、定制和自动化程度识别和盘点需要关注的 AI 代理。与软件工程和产品团队合作，构建自定义 AI 代理应用程序，重用集中式 AI 治理平台的可见性，并包括发现令牌和凭证。

• 通过为 AI 代理分配唯一凭证并在适用的情况下应用更成熟的 RPA 安全原则来实施访问控制、监控和问责制。探索可以适应动态概率行为的高级访问控制模型（例如 ABAC 或 PBAC）。

• 调整安全开发生命周期，强调代理框架的版本控制、机密扫描和供应链安全。定制威胁建模以解决编排和代理内存操纵威胁，并通过手动和自动方法进行 AI 代理安全测试，以有效管理 AI 代理的不确定性。

• 实施 AI 运行时防御，结合现有的应用程序安全措施，以检测和应对针对 AI 的威胁，例如即时注入和行为异常。使用托管服务解决行为异常检测中的固有噪音。

战略规划假设

到 2029 年，超过 50% 针对人工智能代理的成功网络安全攻击将利用访问控制问题，使用直接或间接的提示注入作为攻击媒介。

介绍

在 Gartner 于 2025 年 1 月进行的网络研讨调查中，64% 的受访者表示，他们计划在未来一年内推行代理 AI 计划；其中 40% 的受访者计划在未来六个月内启动该计划。

Gartner 将 AI 代理定义为“自主或半自主的软件实体，它们使用 AI 技术在数字或物理环境中感知、做出决策、采取行动并实现目标”。这些实体中行动的处理和规划由基础模型执行，这些模型本质上是概率性的（而非确定性的），并且可能带来重大的网络安全风险。网络安全领导者需要采取措施来防范这些风险。

目前许多以“代理”形式呈现的实现不符合Gartner 对 AI 代理的定义，不在本研究范围内。所谓的 AI 代理通常都是基于 GenAI 的助手，它们会提供有用的建议，但不会做出决策，也不会采取行动。对于这些实现，一般的LLM 安全最佳实践与应用程序安全最佳实践相结合就足够了。

确保明确定义人工智能代理安全的范围和边界，以与应用程序安全功能的范围保持一致。

此外，许多当前可能被视为 AI 代理的软件实体都是商用现货 (COTS) 代理，例如Microsoft 365 Copilot 。无法定制的 COTS AI 代理被排除在本研究之外，因为网络安全领导者无法实施本研究中概述的应用程序安全原则和软件开发生命周期最佳实践。对于这些代理，网络安全领导者应遵循“快速解答：减轻 AI 代理带来的新风险和安全威胁”以及“如何大规模保护和管理 Microsoft 365 Copilot 中的治理指导。”

在本研究中，我们专注于定制的 AI 代理，即由企业自主开发或定制的（半）自主软件实体。如图1 所示，AI 代理引入了新的威胁和攻击，需要采取发现、威胁建模、安全测试和运行时控制等安全措施（有关攻击的详细信息，请参阅本研究中的“使威胁建模适应代理威胁”部分）。

图 1：AI 代理威胁、攻击和安全措施

这项研究为网络安全领导者提供了指导，告诉他们如何在允许组织部署人工智能代理的同时保护企业和资产。

分析

执行AI 代理发现

发现是 AI 代理安全的重要组成部分。如果不知道代理正在运行，就不可能保护它们。发现解决的一个特别令人担忧的领域是识别活跃但未使用的 AI 代理，或未经许可构建并与企业安全策略相冲突的 AI代理。

组织可能已经将发现作为其治理的一部分，并同时传播了 AI 安全策略。此外，大规模构建 AI 应用程序的组织可能正在考虑或已经在使用可以清点和管理 AI 项目或模型的集中式 AI 治理平台。网络安全领导者应该获得这些平台的访问权限，因为它们将提供组织中已确定的 AI 计划的可见性。

对于定制的 AI 代理发现，网络安全领导者应与利益相关者（例如软件工程和产品团队）合作，以便了解自主开发的代理开发计划。理想情况下，这应该在实际开发开始之前完成。专注于 AI 代理的发现涉及各种技术，例如：

• 交通检查以识别使用各种平台和代理框架构建的人工智能代理的使用情况

• 监控数据中心工作负载向 AI 模型发出的出站 API 调用，以捕捉新 AI 应用程序的早期试点

• 代码库检查和工作负载检测，用于识别正在开发或已运行的 AI 代理

• 创建现有生成式人工智能助手的清单，以确定它们可能演变为人工智能代理计划

发现不仅限于识别代理：令牌和其他凭证可以提供 AI 代理（或 LLM）使用情况的指示，这些指示可能很有用。此外，发现的最佳方法是结合多种技术并关联结果。

强制访问控制

AI 代理使用与现代应用程序和 RPA 机器人相同的途径获取资源访问权限，即分别是 API 和 UI 抓取。与 API 和 RPA 类似，访问控制问题可能是大多数代理安全故障的原因。

对于 AI 代理，有两种类型的访问需要关注：

• 用户或企业访问代理

• 代理访问企业和第三方系统和资源

这里我们重点关注后者。网络安全领导者可以通过采用某些成熟的 RPA 安全原则来管理 AI 代理对资源的访问。凭证管理就是其中之一。

AI 代理应拥有自己的凭证来访问系统和资源，而不是重复使用人类用户访问这些系统时使用的凭证。这样可以更好地记录和问责。一种特殊情况涉及类似于“有人值守”的 RPA 机器人（有时称为机器人桌面自动化 [RDA] ）的 AI 代理。在这种情况下，人类用户可以从他们的计算机访问 AI 代理，以自动执行更大的手动流程中的特定操作。在这些情况下，可能很难避免重复使用用户凭证。

当必须让 AI 代理代表人类访问资源时，请考虑使用 OAuth 2.0 授权流程。此流程专为用户授予客户端应用程序代表其访问资源的权限的情况而设计。

为代理提供独立凭证的一个优点是，AI 代理凭证可以频繁轮换，而不会损害人类用户体验。在 RPA 中，我们看到一些组织每天轮换这些凭证，例如有时使用特权访问管理 (PAM) 工具或机密管理工具。

使用多因素身份验证对人类来说非常有效，但对于 AI 代理等工作负载来说并不合适。相反，请考虑使用工作负载绑定证书或动态凭证。使用 JSON Web 令牌 (JWT) 等令牌和标准化 OAuth 流程，并通过密钥代码交换证明 (PKCE) 进行保护，以避免令牌被盗。尽可能避免使用静态凭证，因为这些凭证存在被盗风险。避免使用 API 密钥，但如果无法做到这一点，请在传出 API 网关上使用令牌交换，在边缘将动态令牌交换为 API 密钥，以便 API 密钥不会暴露给代理。

机密管理工具也可以帮助保护凭证，但根据上述指导，应尽可能使用动态机密。如果不可行，则应经常轮换凭证。在 Kubernetes 等云基础设施中运行时，请使用托管服务标识，利用 SPIFFE 等标准和 PAM 工具的应用程序到应用程序密码管理 (AAPM) 等功能。

基于角色的访问控制 ( RBAC) 将是 AI 代理访问控制的默认选项，但对于高度动态或多代理场景，基于属性的访问控制 (ABAC) 或基于策略的访问控制 (PBAC) 可能会有所帮助。请记住，ABAC 和 PBAC 需要准备资源，例如彻底的数据分类。

不要在 AI 代理中硬编码凭证。某些企业系统直接与目录服务集成，AI 代理可以通过对目录进行身份验证来检索令牌，并将这些令牌用于企业系统。当无法与目录服务集成时，凭证可以存储在机密管理工具或有时是硬件安全模块的加密保险库中。凭证需要经常轮换，并且必须在静止和传输过程中进行加密保护。

一个特别的安全问题是多个代理协作的情况。这可能会导致职责分工中断。许可成本可能会促使组织使用更少的代理做更多的事情，这可能会导致代理特权过高。即使没有这样做，多代理场景也会导致代理特权过高，这些代理应被视为特权帐户（见图 2），因此应通过 PAM 工具进行注册、管理和监控。

在这种情况下，代理协作可能会演变为合谋：考虑到 AI 代理会创建子目标来执行任务，代理可以创建提升其权限的子目标，以获得更多控制权并更快地执行任务。为此，他们可以说服管理访问控制权限的代理。

图 2：多代理场景中的职责分离 (SoD) 问题

调整开发生命周期

不需要重新设计 AI 代理的开发生命周期，但需要特别关注一些需要特别注意的既定最佳实践：

• AI 代理代码的版本控制：这包括代码的代码审查和同行评审，或者在低代码或无代码 AI 代理平台的情况下的伪代码和自然语言。虽然这应该是成熟开发流程中的标准做法，但对于 AI 代理来说尤其重要，因为更改可能会导致重大后果。在 RPA 机器人开发中，我们观察到组织努力实施“双盲”测试。但是，这在持续集成/持续交付（CI/CD ）流程中可能不切实际。通过明确 AI代理代码的所有者来确保问责制。这将能够快速找到谁负责修复 AI 代理代码中的漏洞，或者代理修改源自何处。调查模拟可能在这里很有用，以确保记录和报告所有必要的数据。

• 机密扫描：AI 代理本质上需要访问多个系统才能执行操作。机密绝不能存储在代码或源代码存储库中。不要直接使用机密，而应尽可能针对托管工作负载身份颁发令牌或证书（云基础设施、Kubernetes）。当确实需要直接使用凭证时，应尽量让凭证自动轮换或动态颁发仅供短期使用，并从机密管理工具中检索机密。虽然这可以通过存根手动实现，但在 RPA 中，我们经常看到与 PAM 工具的集成以执行此检索以获得更好的一致性（有关更多详细信息，请参阅本研究中的“强制访问控制”部分）。

• 代理开发的供应链安全：这超出了 AI 安全应有的范围（例如，针对数据和 AI 生命周期中适用依赖关系的软件组成分析、序列化问题、ASL 政策）。除了跟踪 AI 代理框架中的漏洞外，该演习还应评估框架是否为代理编排提供了安全性，以及是否提供了其他安全措施，使开发人员更容易在应用程序中构建安全逻辑。与我们在 RPA 安全故障中看到的情况类似，某些团队可能会错误地使用不提供安全功能的免费版或演示版。网络安全领导者应该识别并防止这种情况发生。

• 特定的、熟知的安全编码最佳实践：这些可以包括输入和消息验证、传输层安全性（尤其是当代理连接到远程 LLM 时）、速率限制和错误处理。

威胁建模和测试也需要适应，包括以下章节中介绍的某些新元素。

使威胁建模适应代理威胁定义范围

范围是威胁建模首先要解决的问题。理想情况下，这项工作在建立整体 AI 治理时完成。

人们对人工智能的主要担忧是，模型可能会产生带有偏见、煽动仇恨、不道德或导致伤害的输出。一个典型的例子是通过提供教育借口来诱骗人工智能聊天机器人生成制造炸弹的指令。

这类问题与确保数据机密性、完整性和可用性的传统信息安全目标不一致。没有数据泄露，数据没有损坏，AI 代理正常运行。DLP可以通过阻止此类数据泄露来减轻 AI 代理对特定数据的恶意行为的风险，而无需解决实际的恶意行为本身。但是，组织可能发现这种缓解措施不够充分，因为事实上代理的表现并不如预期。

向组织澄清哪些威胁属于（应用程序）安全能力的一部分。如果范围扩大到涵盖偏见、仇恨、道德和伤害，请确保明确说明这一点。

因此，第一个目标是区分不同类型威胁的所有权，并定义何时威胁是应用程序安全威胁。

确定代理机构

下一步是确定具有高代理水平的代理。目前实施的许多所谓代理并不自主做出决策，也不自主采取行动。网络安全领导者不应争论术语，而应将精力转向引入重要代理并因此带来风险的代理。

衡量风险的一个很好的参考是欧盟人工智能法案中的四个风险等级——低、中、高和不可接受。在早期实施中，我们看到代理被自动限制，这可能是网络安全领导者可以对其人工智能代理应用或要求的一项措施。例如，OpenAI 的运营商不会自主支付，而是明确请求许可才能这样做。

识别内在代理应用程序安全风险

人工智能代理的实际威胁建模应关注这些软件实体的新情况。虽然 OWASP 仍在开发针对代理人工智能威胁的计划，但结合OWASP Web App Top 10、OWASP LLM Top 10 和 MITRE ATLAS 可以为网络安全领导者提供有关主要威胁的良好初步指南。

这些列表尚未包含与新元素相关的风险，即代理、其 LLM、其内存和工具之间的协调。Anthropic 的模型上下文协议提供了有关代理 AI 如何安全地将 LLM 与资源和工具互连的良好参考。

一些针对人工智能代理的新兴攻击媒介有各种名称，例如跨服务混淆代理 、代理劫持和promptware 。通过查看单个攻击并用单次攻击来命名一种技术，很容易使事情变得过于复杂。

从更宏观的角度来看，攻击几乎总是通过代理的外部接口进行攻击。这种攻击试图传递恶意负载，或通过提示利用暴露，或通过提示说服代理及其 LLM 执行未经授权的操作。在威胁建模练习期间需要考虑的一些具体问题是：

• 内存泄漏和操纵

• 恶意输入的处理

• 逻辑策略差距

• 数据防泄露差距

内存泄漏和操纵

在记忆操纵中，代理可以在与用户交互时记住一些机密信息，并将其传达给其他用户。在这种情况下，代理的授权控制可确保其不会泄露组织数据库中的机密数据，但不会对短期和长期记忆数据做同样的事情。

此类问题可以通过会话管理或DLP 控制来解决，或者通过在用户交互后不保留情景记忆来解决。事实上，更广泛地说，大多数代理风险都可以通过遵循传统的应用程序安全最佳实践来缓解。然而，由于这些威胁的频率和影响，在构建代理时应该强调对这些威胁及其导致的错误配置的关注。

恶意输入的处理

当 AI 代理能够与外部环境（无论是物理环境还是数字环境）交互，从而做出决策并采取行动时，它们就非常有用。然而，当它们向外部环境开放时，它们可能会暴露于恶意内容。

例如，我们在早期的人工智能代理实现中观察到一种特别成功的攻击技术——间接提示注入——即向人工智能代理的人类用户发送恶意电子邮件。为了随时了解用户的任务，代理会获取恶意电子邮件的内容并执行其中的恶意指令。

输入清理和阻止特定类型的内容（包含“忽略所有先前的指令”等指令的文件和电子邮件）是缓解此威胁的一种方法。

逻辑策略差距

代理倾向于继承其执行任务的用户的权限。某些操作通过技术强制执行安全控制来抑制，而其他操作则通过安全策略传达的逻辑控制来阻止。但是，代理并不像人类用户一样有遵守安全策略的动机和激励。因此，可能需要从技术上为代理强制执行逻辑策略，例如通过在沙箱中部署代理。

例如，一些组织对客户端或其他敏感的内部数据库有免责声明，声明数据库受到监控，搜索应仅限于业务目的。大多数人类用户都不会滥用数据库。然而，人工智能代理可能不会受到逻辑控制的阻碍。这可能是因为越狱、即时注入，或者因为代理试图提供帮助或提高效率。

一个有趣的想法是尝试让 AI 代理具备安全意识，通过使用数据衍生的安全策略对其进行训练，并使用安全意识训练。在撰写本文时，虽然取得了进展，但AI代理的记忆往往是偶发性的，这意味着不可能广泛地塑造代理的行为以使其始终具备安全意识。

数据防泄漏差距

在“实施访问控制”部分中，我们提到 AI 代理和 RPA 机器人具有共同的属性。但是，它们也存在一些关键差异，如果忽略这些差异，可能会导致安全故障。

RPA 确实会模仿、重复或取代人类行为。但与 AI 代理不同，RPA 完全可预测、可锁定，并且通常仅限于结构化数据。

尤其是对于非结构化数据，实施 DLP 控制变得更加困难。AI 代理的多模态性还可能为泄露敏感数据以及注入恶意提示和指令提供途径，而当前的 DLP 措施可能无法解决这些问题。

最佳实践（例如最小化不需要的数据和验证数据分类）对于处理非结构化数据的 AI 代理尤为重要（有关更多详细信息，请参阅2025 年顶级网络安全项目中的“促进非结构化数据准备以采用 GenAI”部分）。但是，从长远来看，ABAC 和 PBAC 等最小特权方法将更加有效。

进行AI代理安全测试

人工智能代理安全测试对于确保人工智能代理的安全至关重要。在行业中，目前有各种与识别人工智能系统中的漏洞的实践相关的术语——从红队到渗透测试，再到漏洞评估，再到安全测试。为简单起见，我们称之为安全测试。

除了通过发起针对 LLM 的即时注入等攻击来解决 AI 漏洞之外，AI 代理安全测试还应涵盖代理与LLM 的集成、长期/短期代理记忆以及代理用于执行任务的补充工具。

与应用程序安全测试相比，AI 代理安全测试的目标相似——它们都专注于识别软件中的漏洞并提出补救措施。但是，代理的不确定性行为对实现完整代码覆盖或抓取 AI 代理应用程序进行自动测试提出了挑战。它还需要识别 AST 扫描器传统上未涵盖的漏洞，例如提示注入。此外，AI 代理安全测试不仅需要测试 LLM 暴露，还需要测试代理编排和自动化产生的暴露。

出于这些原因，组织倾向于将手动渗透测试活动与该领域的自动化创新结合起来。AI代理安全测试的示例供应商包括：Aim Security、Akto 、AppSOC、CalypsoAI、Lasso Security、Noma Security 、Pillar Security 和Protect AI 。

此外，我们观察到许多 AI 安全供应商使用 AI 代理技术来创建 AI 代理，这些代理可以自主对目标 AI 代理进行安全测试。这与 RPA 安全中观察到的情况一致，企业在其中实施“制造者-检查者”原则。例如，创建一个 RPA 机器人来仔细检查另一个 RPA 机器人在金融服务（例如应付账款）中执行的操作。 

在对 AI 代理进行安全测试时，以毒攻毒是解决 AI 代理不确定性本质的可行方法：使用 AI 代理对 AI 代理进行安全测试。

此外，某些众包测试服务（如 Bugcrowd 和HackerOne）也可能会被证明是有用的，特别是在涉及网络物理安全而非人工智能安全影响的代理场景（例如汽车）中。

执行运行时控制

AI 代理运行时安全需要结合应用安全和 AI 控制。预先部署的应用安全控制（例如 WAAP）不会因 AI 代理运行时保护而消失。这些控制仍应存在，因为攻击者会尝试 SQLi 等传统攻击，即使针对 AI 代理也是如此。除了这些控制之外，组织还需要实施特定于 AI 代理的运行时安全控制。  

AI 运行时防御与我们见过的为终端、网络和其他资源提供的各种检测和响应技术非常相似。这些工具提供近乎实时的安全控制，以抵御针对 AI 应用程序的新形式攻击，例如提示注入和越狱。这些工具通常会识别已知的攻击模式（例如，越狱尝试中常见的“忽略所有先前的指令”提示）以及基于已知（良好和/或不良）行为的行为异常。有些工具超越了网络安全要求，还可以检测有害和有毒的输入、幻觉和亵渎（这些通常被称为“AI 护栏”）。

我们还看到，可以提供一些安全功能的 AI 网关正在涌现。AI网关倾向于提供允许执行安全策略的功能，而不是检查以确保遵循此类策略。网络安全领导者可以将 AI 网关视为类似于 API 网关，而 AI 运行时防御可以被视为更接近 WAAP 或独立 API 安全供应商提供的 API 威胁防护功能。这两种功能都是必需的。AI 运行时安全工具以多种方式集成，包括作为编排中的库、作为内联组件或作为工作负载组件。

有各种类型的供应商提供与 AI 代理相关的 AI 运行时安全工具。其中许多是新的、独立的和专门的。示例供应商包括AppSOC、CalypsoAI、Dynamo AI 、HiddenLayer、Lakera、Lasso Security、Noma Security、Operant 、Pillar Security、Prompt Security、Protect AI、TrojA I 和 Zenity 。

基础设施安全供应商开始提供专用解决方案，例如思科AI Defense和 Palo Alto Networks AI Runtime Security。人工智能提供商也开始为内置于代理框架中的代理提供人工智能护栏，例如来自亚马逊和谷歌的人工智能护栏。我们还看到了来自人工智能芯片提供商的产品。

行为异常检测的一个缺点是它容易产生误报。为了缓解这种情况，请考虑使用托管服务（来自同一供应商或来自 MDR），除非组织受益于能够吸收这种额外工作量的 SOC。

另一个挑战是，目前基于比较多个 LLM 响应的幻觉护栏往往会出现滞后。此外，一般的护栏工具通常会通过更通用的 AI 治理工具来部署，这可能需要安全团队部署独立的以 AI 为中心的工具来验证安全策略是否正确配置和遵循。

Gartner 观察到，组织可能会创建专门的团队、工作流程和剧本来处理与 AI 应用程序相关的事件和告警。此措施可能是暂时的，但反映了处理这些事件的复杂性时的特殊要求。

保护 AI 代理的生成 AI 组件并不是运行时控制的唯一目标。组织应考虑对数据类型和操作以及允许的参数实施策略。通过设计限制代理更为可靠，但在运行时实施规则可能是一种有效的解决方法，尤其是当操作组件通过 API 或函数调用触发时。

对于生成代码的 AI 代理来说，用于执行代理生成代码的沙箱是一种有用的附加安全措施。这些沙箱与 AI 代理开发过程中可能使用的沙箱不同，因为它们在运行时用于防止代理生成或执行的代码产生不可预见的后果。