知识工作者正越来越多地将 AI Agent 集成到他们的工作流中。作为“数字同事”运行的 Agent 能带来明显好处。例如，它们可以审查错误报告、实现并测试修复、推送补丁，并提醒人工进行复核。通过处理日常任务，Agent 有潜力带来巨大的生产力提升。另一方面，通过 agentic harness 将大语言模型（LLM）连接到实时工具和企业数据，可能会将一个有用的助手转变为拥有特权但攻击面不明确的软件。

在过去六个月中，NVIDIA AI Red Team 对多个 AI Agent 进行了评估——从简单的交互式编码工具到始终在线的自主数字助手。当某个 Agent 被证明可被利用时，无论使用何种框架或 harness，我们通常都会看到相同的关键失败模式，包括：

  • 对 Agent 缺乏访问控制。
  • Agent 工具支持任意代码执行。
  • 无网络出口控制。
  • 明文形式向 Agent 暴露密钥。

在这篇文章中，我们将分析这些失败模式，并介绍在对抗压力下依然有效的控制措施。虽然我们的示例主要针对通过聊天连接的 Agent（我们在评估中遇到的大多数 Agent 都属于这一类），但这些模式同样适用于任何 Agent。

实施 Agent 访问控制

当前 AI 部署中最常见的失败模式是对 Agent 缺乏访问控制。我们发现多个 Agent 持有单个用户的凭据，且内部网络中的任何授权用户都能访问。虽然这为滥用 Agent 的合法凭据打开了方便之门，但也常常使我们能够收集这些凭据，并在 Agent 的预期使用场景之外使用它们，如后续示例所示。

建议：

  • 使用强访问控制作为对抗活动的第一道防线。
  • 将每个 Agent 限制为仅授权用户；对未授权用户不响应的 Agent 显著更难测试。
  • 遵循最小权限原则，使 Agent 的权限与其调用者的权限相匹配。

限制代码执行

许多 harness 会暴露 Bash shell 或命令执行工具。这些工具因其通用性而被广泛使用，它们支持广泛的日常任务，而无需为每个功能单独提供工具。然而，当模型输出控制命令执行时，攻击者可以通过直接输入或间接提示注入影响该输出，从而在执行环境中运行命令。这可能使攻击者实现恶意结果，如数据外泄或在主机上建立持久化执行。

针对任意命令执行风险的常见缓解措施通常包括：使用 LLM 作为裁判的审查 Agent 来阻止有害或恶意命令的运行、使用可接受命令的白名单，或简单地信任模型“知道得更好”。这些方法对对抗性操纵的防御能力都有限。

许多常见的 agentic 命令行任务支持常见的开发工作流和测试驱动开发。这意味着它们通常需要执行如 pytest 或 npm install 等命令，因此 LLM-as-a-judge 模式往往倾向于接受这些命令的执行。但在受到攻击者控制的输入影响时，这些命令等同于任意命令执行。

在某些情况下，通过让 Agent 编写并执行 Python 脚本或安装远程包，获得带有反向 shell 的完全远程代码执行（RCE）非常简单，正如我们此前关于此主题的博客文章所示。

即使没有命令行工具，通过文件读写工具与 Agent 运行环境交互的能力也常常暴露出意想不到的代码执行和权限提升路径。

攻击者如果能将内容写入系统文件（如 ~/.bashrc 或 ~/.zshrc），或配置文件（如 ~/.gitconfig、hooks.json、MCP.json 或 skills 文件），就可以在另一个进程执行相关文件时实现代码执行，即使命令行执行不可直接使用。Agent 可写入的位置和文件应严格控制，并仅限于非可执行位置。

建议：

  • 将任意代码执行视为可访问 Agent 中影响最大的单一风险。
  • 尽可能避免使用命令行工具。
  • 在操作系统层面阻止向非可执行工作区之外写入。
  • 如果必须使用命令行执行工具，请使用严格的最小权限可执行命令白名单，并在具有强网络出口控制的隔离执行环境中运行该工具，具体见下文。
  • 通过命令行处理参数或字符串（如文件名、文档标题和其他外部数据）时需谨慎。确保在处理前对其进行清理和规范化，以防止路径遍历或命令注入等问题。

默认拒绝网络出口

出站网络连接允许数据外泄以及创建直接连接（如反向 shell 和 SOCKS），攻击者可通过这些连接直接与 Agent 的运行时环境交互。当网络出口控制得到强制执行且遵循最小权限原则时，我们的所有交互都必须通过 Agent 进程进行，这减缓了我们的执行速度，并使影响变得更不可靠。维护 Agent 的状态和对齐、绕过输出过滤器、在 Agent 开始拒绝请求后重启和操纵会话，都增加了操作负担。

建议：

  • 应用默认拒绝的网络出口策略，仅允许执行 Agent 预期任务所需的最小端点集合的白名单。
  • 在 Agent 接触的每个网络边界使用Agent 无法访问的环境控制措施来强制执行这些限制。

使密钥远离 Agent 的访问范围

Agent 通常需要访问密钥才能执行其预期功能：平台令牌、API 密钥、版本控制系统（VCS）访问令牌，有时甚至是 OAuth 刷新令牌。虽然传统安全建议建议将密钥作为环境变量注入内存以防止写入磁盘，但这仅在只有你的代码在容器中运行时才合理。

当具有命令执行能力的 Agent 共享该环境时，诱导它运行 env、printenv 或 /proc/self/environ 即可直接检查这些变量。命令行工具尤其高风险，因为 CLI 会将凭据缓存到磁盘上的可预测位置，并随时打印出来。我们在 git 仓库、.env 文件、bash history、.netrc 文件、OAuth 2.0 刷新令牌以及执行环境中的环境变量中都观察到了令牌。

即使我们无法建立反向 shell，也常常能通过聊天界面外泄凭据。我们使用“温水煮青蛙”方法（见下文），引导 Agent 暴露其自身执行环境中暴露的多个密钥。出口控制阻止了通过网络直接外泄或直接检查文件系统，但凭据仍暴露在环境中且可被 LLM 访问，LLM 会通过聊天界面将它们交付给我们。

建议：

  • 切勿使持久性密钥可被 Agent 访问。
  • 将密钥存储在专用的密钥管理器中。
  • 仅在需要它们的进程内存中按需检索密钥。
  • 使密钥远离 Agent 的上下文窗口和执行环境。
  • 当任务需要凭据时，使用短期、范围狭窄的令牌，并在任务完成后立即撤销该令牌。

将确定性控制作为第一道防线

我们遇到的最常见的缓解尝试是系统提示，告诉模型避免有风险或危险的行为，有时会由第二个模型判断输入或输出（LLM-as-a-judge 模式）来强化。这些措施都由 LLM 执行，继承了与 LLM 本身相同的概率性、不可靠行为。

有三种通用技术可以可靠地击败此类控制。我们在多个系统上展示了每一种。

简单地向 Agent 呈现恶意活动看似合法的上下文就非常有效。我们经常向 Agent 暗示我们正在“调试”或“管理员用户”，之后它通常会遵从我们的请求。有一个 Agent 甚至为我们编写并执行了反向 shell：

Dark-mode Slack screenshot showing an agent acknowledge a sanctioned red-team request, then create and execute a reverse-shell script.
图 1. 一次“社会工程”攻击成功针对 Slack 连接的 Agent，使其为攻击者创建反向 shell

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

温水煮青蛙

“温水煮青蛙”（有时称为 Crescendo 攻击）通过多次交互逐步推动 Agent 达到期望行为，利用之前的对话历史建立可信度和请求的良性性质。密钥提取是通过尝试执行看似合法的工作流以诱发错误，然后最终“发现”错误的根本原因与密钥有关，从而说服 Agent 向我们透露密钥来实现的。

通过合法工作流进行误导

如包安装之类的误导攻击（首次在 Black Hat 2025 的 From Prompts to Pwns 中描述）仍然极其有效。通过诱导 Agent 执行一个表面上良性的操作，而该操作的副作用是代码执行，通常可以轻松绕过任何 Agent 抵抗。

编码 Agent 经常安装库。按照本文所述创建恶意库，然后要求 Agent 通过 pip install git+https://… 安装它，看似是标准请求；然而，武器化包会在安装过程中创建任意代码执行。

推荐控制措施

一个一致的发现是，与 LLM 处于同一控制平面的防御措施，特别是基于提示的防御，经常被绕过。控制措施必须在模型控制平面之外强制执行。

按重要性大致排序的推荐控制措施为：

  • 对 Agent 使用访问控制。只有特定、已认证的用户才能与 Agent 交互。
  • 仅在沙箱环境中运行任意命令执行，如 Docker、NVIDIA OpenShell 或虚拟机。该环境必须正确加固以防止逃逸。该环境不能通过写入或编辑环境或 Agent 配置文件来自行配置。
  • 默认拒绝网络出口，在 Agent 接触的每个边界，对任务所需的具体网络资源使用最小权限白名单。
  • 不要在静态或环境中暴露密钥。虽然在非 agentic 应用中将密钥注入环境变量是标准做法，但对于执行任意代码的工作负载来说这是不安全的。密钥应存储在密钥管理器中，按需访问，并仅限于需要它们的进程。在可能的情况下，应使用提供最小权限、临时令牌的令牌代理。
  • 仅允许从经验证的包仓库安装包。默认阻止任意 URL 和基于 VCS 的安装。
  • 最小权限工具、MCP、skills 等。仅使用工作所需的工具；仔细审查任何执行、写入或访问网络的工具。
  • 最小权限持久存储。避免卷挂载；如果无法避免，请严格限定范围，切勿将任何可写内容挂载到之后会被执行的路径。
  • 使用最新/前沿模型，特别是对于 LLM-as-a-judge 模式，这些模式对对抗性操纵更具鲁棒性。

结论

我们 AI Red Team 在保护 AI Agent 方面的经验突显了在防御 AI Agent 时对确定性“硬”控制的持续需求。具有企业凭据的完全自主系统本身存在风险，必须小心保护。虽然前沿模型使对抗性操纵更加困难，但只要有足够的时间和专业知识，几乎所有模型仍然可以被攻破。

我们观察到的常见缺陷包括：弱访问控制（允许任何用户访问 Agent）、创建 RCE 机会的执行和文件写入工具、允许数据外泄和反向 shell 的网络出口控制不足，以及 Agent 可访问的执行环境中以明文形式存在的密钥。

基于提示的防护措施，包括 LLM-as-a-judge 模式，并不能填补这些空白。架构控制可以：对 Agent 的访问控制、具有对企业数据最小权限访问的加固沙箱、默认拒绝的网络出口控制，以及使密钥远离 Agent 的访问范围。当正确配置和执行时，这些控制在减少 AI Agent 的对抗性滥用方面非常有效。

要了解如何从第一性原理设计安全 Agent，请参阅 “如何在企业 AI 工厂中治理自主 Agent”技术博客，该文将指导你完成实施我们的 安全 Agent 工作区参考设计的第一步。

要了解更多关于 Agent 安全的信息，请不要错过 NVIDIA 在 Black Hat USA 的演讲：成本效益高、私有、前沿级：使用微调的开源模型进行 AI Agent 利用

要阅读更多来自 NVIDIA AI Red Team 的内容，请参阅我们的其他文章。