部署更安全的 AI 智能体的四种方法

知识工作者正越来越多地将 AI 智能体集成到其工作流中。作为“数字同事”的智能体具有明显的优势。例如，他们可以查看错误报告、实施和测试修复程序、推送补丁程序，以及与人工沟通以供审查。通过处理日常任务，智能体有望大幅提高工作效率。另一方面，通过智能体将大语言模型 (LLM) 连接到实时工具和企业数据，则有可能将实用助手转变为具有特权的软件，使其面临难以理解的攻击面。

在过去六个月中，NVIDIA AI Red Team 评估了多个 AI 智能体，从简单的交互式编码工具到始终开启的自主数字助理，不一而足。当一个智能体被证明是可利用的时，无论使用何种框架或工具，我们通常都会看到相同的关键故障模式，包括：

缺乏对智能体的访问控制。
支持任意代码执行的代理工具。
没有网络出口控制。
以明文形式向智能体公开的秘密。

在本文中，我们将研究这些故障模式，并描述在对抗压力下取得成功的控制。虽然我们的示例侧重于聊天连接的智能体 (我们在评估中遇到的大多数智能体) ，但这些模式适用于任何智能体。

实施代理访问控制

当前 AI 部署中最常见的故障模式是缺乏对智能体的访问控制。我们发现了多个代理，它们持有个人用户的凭据，并且可供内部网络中的任何授权用户访问。虽然这为滥用智能体的合法凭据打开了大门，但它也常常使我们能够收集这些凭据，并在智能体的预期上下文之外使用它们，如后面的示例所示。

推荐：

使用强大的权限控制作为对抗活动的第一道防线。
将每个智能体限制为明确授权的用户；不响应未经授权用户的智能体更难以测试。
根据最小权限原则，将智能体的权限与调用智能体的用户的权限相匹配。

限制代码执行

许多工具都使用 Bash shell 或命令执行工具。由于它们具有通用性，因此经常使用。它们支持各种常规任务，而无需为每个功能配备单独的工具。但是，当模型输出控制命令执行时，可以通过直接输入或间接提示注入影响该输出的攻击者可能能够在执行环境中运行命令。这可能会使它们实现恶意结果，例如数据外泄或主机上的执行持久性。

常见的缓解任意命令执行风险的方法通常包括使用 LLM-as-a -judge 审查代理来阻止有害或恶意命令的运行，使用允许列表来处理可接受的命令，或者只是相信模型“知道得更好”。所有这些都为对抗操纵提供了有限的防御。

许多常见的代理式命令行任务都支持常见的开发工作流程和测试驱动的开发。这意味着 LLM-as-a-judge 模式通常需要能够执行 pytest 或 npm install 等命令，这意味着 LLM-as-a-judge 模式通常倾向于接受这些命令的执行。然而，当受攻击者控制的输入影响时，这些命令相当于任意命令的执行。

在某些情况下，使用反向 shell 获取完整的远程代码执行 (RCE) 与要求智能体编写并执行 Python 脚本或安装远程包一样简单，如我们之前关于此主题的博文所示。

即使没有命令行工具，通过文件读写工具与智能体运行环境进行交互的能力也经常会暴露意外的代码执行和权限升级路径。

如果攻击者可以将内容写入系统文件 (例如 ~/.bashrc 或 ~/.zshrc) 或配置文件 (例如 ~/.gitconfig、hooks.json、MCP.json 或技能文件) ，则可以在其他进程执行相关文件时执行代码，即使命令行执行不可直接使用即使命令行执行不可直接使用。智能体可以写入的位置和文件应受到严格控制，并仅限于不可执行的位置。

推荐：

将任意代码执行视为可访问智能体中影响最大的单一风险。
尽可能避免使用命令行工具。
在操作系统级别的不可执行工作空间之外阻止写入。
如果需要命令行执行工具，请使用严格的可执行命令最低权限允许列表，并在具有强大网络出口控制的隔离执行环境中运行该工具，我们将在下文中详细介绍。
在通过命令行处理参数或字符串 (例如文件名、文档标题和其他外部数据) 时，请格外小心。确保在使用前对其进行清理和标准化处理，以防止出现路径遍历或命令注入等问题。

默认情况下，拒绝网络出口

出站网络连接允许数据外泄并创建直接连接，例如反向 shell 和 SOCKS，攻击者可以通过这些连接直接与智能体的运行时环境进行交互。当执行网络出口控制并适当地设置最低权限时，我们会通过智能体流程运行所有交互，从而减慢执行速度并降低影响的可靠性。保持智能体的状态和对齐、浏览输出过滤器，以及在智能体开始拒绝请求后重启并操作会话，所有这些都增加了操作负担。

将机密置于智能体触手可及的范围之外

智能体通常需要访问 Secret 来执行预期功能：平台令牌、API 密钥、版本控制系统 (VCS) 访问令牌，在某些情况下甚至需要 OAuth 刷新令牌。虽然传统安全建议建议将机密作为环境变量注入内存，以防止其写入磁盘，但当只有你的代码在容器中运行时，这种做法是合理的。

当具有命令执行功能的智能体共享该环境时，引导其运行 env、printenv 或 /proc/self/environ 可以直接检查这些环境。命令行工具的高风险特别值得强调。CLI 将凭据缓存在可预测位置的磁盘上，并随时将其打印回来。我们在 git 存储库、.env 文件、bash 历史记录、.netrc 文件、OAuth 2.0 刷新令牌和执行环境中的环境变量中观察到令牌。

即使我们无法建立反向 shell，我们也经常会通过聊天界面泄露凭据。通过使用“烧焦”方法 (见下文) ，我们引导智能体在自己的执行环境中暴露了几个秘密。出口控制防止了通过网络直接外泄或在文件系统中直接检查，但凭据仍然在环境中公开，可由 LLM 访问，LLM 通过聊天界面将其交付给我们。

使用确定性控制作为您的第一道防线

我们遇到的最常见的缓解尝试是系统提示词，用于告知模型避免危险行为，有时通过第二个模型判断输入或输出 ( LLM 即判断模式) 来强化这种尝试。这些都由 LLM 强制执行，并继承了与 LLM 本身相同的概率性、不可靠的行为。

三种常用技术都能可靠地阻止此类控制。我们分别在多个系统上进行展示。

社会工程学是智能体

简单地向智能体展示恶意活动似乎合法的上下文会非常有效。我们经常向智能体建议，我们正在“调试”或“管理员用户”，之后它会定期遵守我们的请求。一个代理甚至为我们编写并执行反向 shell：

在其他情况下，可以通过指示代理使用文件编辑工具来直接操作代理内存和 AGENT.md 文件，这也允许构建“调试”和“授权用户”帧。

烧开青蛙

“Frog-boiling” (有时也称为“Crescendo 攻击”) 逐渐将智能体推向多个交互中的预期行为，并利用之前的对话历史记录来建立请求的可信度和良性本质。秘密提取的过程是，尝试以诱导错误的方式执行看起来合理的工作流程，然后最终“发现”错误的根本原因与秘密有关，从而说服智能体向我们揭示这些错误。

通过合法工作流程进行误导

软件包安装等误导性攻击 (在“从提示词到 Pwns at Black Hat 2025”中进行了首次描述) 仍然非常有效。通过诱导智能体采取具有执行代码副作用的看似良性的行动，通常可以直接绕过任何智能体的抵抗。

编程代理通常会安装库。创建本文中所述的恶意库，然后通过 pip install git+https://… 要求智能体进行安装，这似乎是一种标准请求；但是，武器化软件包会在安装过程中创建任意代码执行。

总结

我们的 AI 红色团队在保护 AI 智能体方面拥有丰富的经验，这凸显了在保护 AI 智能体方面对确定性“硬性”控制的持续需求。具有企业凭据的完全自主系统本身存在风险，必须小心保护。虽然前沿模型让对抗操纵变得更加困难，但只要有足够的时间和专业知识，几乎所有模型都可能被颠覆。

我们观察到的常见缺陷包括：访问控制薄弱 (允许任何用户访问智能体) ，执行和文件写入工具为 RCE 创造了机会，网络出口控制不足，允许数据外泄和反向 shell，以及智能体可访问的执行环境中的明文机密。

基于提示的护栏 (包括 LLM-as-a-judge 模式) 无法填补这些空白。架构控制的作用：对智能体的访问控制、对企业数据具有最低权限访问的强化沙盒、默认拒绝的网络出口控制，以及使智能体无法获取的机密。如果配置和执行得当，这些控制在减少对抗性滥用 AI 智能体方面非常有效。

如需详细了解如何根据首要原则设计安全智能体，请参阅“如何治理企业 AI 工厂中的自主智能体”技术博客，该博客将指导您完成实现安全智能体工作空间参考设计的第一步。

要了解有关智能体安全的更多信息，请不要错过 NVIDIA 在 Black Hat 美国展会上的演示：经济高效、私密、前沿：使用微调 OSS 模型开发 AI 智能体

如需了解 NVIDIA AI Red Team 的更多信息，请参阅我们的其他博文。