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 代理开发过程中大概利用的沙箱不同，由于它们在运行时用于防止代理天生或执行的代码产生不可预见的后果。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。