知识型工作者正在将AI智能体融入日常工作流程。这类充当"数字同事"的智能体具有显著优势，例如能够自动审查错误报告、实施并测试修复方案、推送补丁，并通知人工进行审核。通过处理常规任务，智能体有望带来显著的生产力提升。然而，将大语言模型通过智能体框架与实时工具和企业数据相连接，可能会将一个有用的助手变成拥有特权访问权限却存在安全隐患的软件。
过去六个月，英伟达AI红队对多个AI智能体进行了安全评估，涵盖从简单的交互式编程工具到持续运行的自主数字助手。当发现智能体存在可利用漏洞时，无论使用何种框架，我们通常会看到以下几种关键失效模式：
缺乏对智能体的访问控制；智能体工具支持任意代码执行；缺少网络出口管控；密钥以明文形式暴露给智能体。
本文将分析这些失效模式，并介绍在对抗性压力下行之有效的安全控制措施。虽然示例主要围绕聊天连接型智能体展开，但相关规律同样适用于所有类型的智能体。
失效模式一：缺乏访问控制
当前AI部署中最常见的失效模式是对智能体缺乏访问控制。我们发现多个智能体持有个人用户凭证，却允许内部网络中任何已授权用户访问。这不仅为滥用智能体合法凭证打开了方便之门，还往往使我们能够直接获取这些凭证并在预定场景之外加以利用。
建议措施：
将强访问控制作为抵御对抗性行为的第一道防线；将每个智能体严格限定于经过明确授权的用户访问，不响应未授权用户的智能体在测试中明显更难攻破；遵循最小权限原则，将智能体的权限与调用该智能体的用户权限相匹配。
失效模式二：任意代码执行
许多智能体框架提供了Bash shell或命令执行工具，因其通用性而被广泛采用——无需为每项功能单独配置工具即可支持各种常规任务。然而，当模型输出控制命令执行时，能够影响该输出的攻击者（通过直接输入或间接提示注入方式）就可能在执行环境中运行任意命令，进而实现数据外泄或在宿主机上建立持久化执行。
常见的缓解措施包括：使用大语言模型充当评判者来拦截恶意命令、采用可接受命令的白名单，或直接相信模型"足够聪明"。但这些方法对对抗性操控的防御效果均十分有限。
许多常见的智能体命令行任务面向开发工作流和测试驱动开发，通常需要执行pytest或npm install等命令，这意味着"大语言模型评判"模式往往倾向于接受这类命令的执行。然而一旦受到攻击者控制输入的影响，这些命令实际上等同于任意代码执行。
某些情况下，获取完整的远程代码执行（RCE）和反向Shell甚至只需让智能体编写并执行一个Python脚本，或安装一个远程包（详见我们之前发布的相关博文）。
即便没有命令行工具，通过文件读写工具与智能体运行环境交互，往往也会暴露出意想不到的代码执行和权限提升路径。
攻击者若能向~/.bashrc、~/.zshrc等系统文件，或~/.gitconfig、hooks.json、MCP.json、技能文件等配置文件写入内容，即便无法直接进行命令行执行，也可以在其他进程执行相关文件时触发代码执行。因此，应严格控制智能体的文件写入位置，并将其限定在不可执行的目录中。
建议措施：
将任意代码执行视为可访问智能体中影响最高的单一风险；尽可能避免使用命令行工具；在操作系统层面阻止向不可执行工作区以外的位置写入；如确有需要使用命令行执行工具，则采用严格的最小权限可执行命令白名单，并在具备强网络出口管控的隔离执行环境中运行该工具；对通过命令行处理的参数或字符串（如文件名、文档标题及其他外部数据）保持警惕，在使用前进行清洗和规范化处理，以防止路径遍历或命令注入等问题。
失效模式三：缺乏网络出口管控
出站网络连接不仅允许数据外泄，还可能建立反向Shell和SOCKS等直连通道，供攻击者直接与智能体运行环境交互。当网络出口管控得到强制执行且遵循最小权限原则时，我们只能通过智能体进程进行操作，这大幅降低了攻击执行效率，也使危害更难以落地。维持智能体状态与行为对齐、绕过输出过滤器、在智能体开始拒绝请求后重启并操控会话，这些都带来了额外的操作负担。
建议措施：
采用默认拒绝的网络出口策略，并配以最小权限白名单，将允许访问的端点限定在智能体预期任务所需的最小集合；在智能体涉及的每个网络边界处，使用智能体无法访问的环境控制手段强制落实上述限制。
失效模式四：密钥以明文暴露
智能体通常需要访问各类密钥才能完成预期功能，包括平台Token、API密钥、版本控制系统访问Token，有时甚至包括OAuth刷新Token。传统安全建议是将密钥以环境变量形式注入内存，避免写入磁盘，这在容器中仅运行自有代码时是合理的。
然而，当具备命令执行能力的智能体共享该环境时，攻击者只需诱使其执行env、printenv或读取/proc/self/environ，即可直接获取这些密钥。命令行工具尤其值得关注，因为CLI会将凭证缓存在磁盘上的可预测位置，并能轻易将其输出。我们在Git仓库、.env文件、bash历史记录、.netrc文件、OAuth 2.0刷新Token以及执行环境中的环境变量里均发现了Token。
即使无法建立反向Shell，我们也往往可以通过聊天界面泄露凭证。通过"温水煮青蛙"策略（见下文），我们引导智能体逐步暴露其自身执行环境中的多个密钥。出口管控虽然阻止了通过网络或直接在文件系统中进行的外泄，但凭证仍暴露在环境中，可被大语言模型访问，并由其通过聊天界面传递给我们。
建议措施：
永远不要让智能体访问持久性密钥；将密钥存储在专用密钥管理器中；仅在需要时于需要密钥的进程内存中按需获取；确保密钥不出现在智能体的上下文窗口和执行环境中；当某项任务需要凭证时，使用短期且权限受限的Token，并在任务完成后立即撤销。
绕过提示层防护的三种技术
目前最常见的缓解尝试是在系统提示中指示模型避免危险行为，有时辅以另一个模型对输入或输出进行判断（即大语言模型评判模式）。这些措施全部由大语言模型强制执行，因此继承了大语言模型本身概率性、不可靠的特性。以下三种通用技术能够可靠地突破这类控制，我们已在多个系统上加以验证。
伪造合法场景
向智能体构造一个使恶意活动显得合法的上下文，效果出奇地好。我们经常向智能体声称自己是"调试人员"或"管理员用户"，之后它便会定期配合我们的请求。一个智能体甚至主动为我们编写并执行了反向Shell。在其他情况下，还可以通过指示智能体使用文件编辑工具，直接操控智能体内存和AGENT.md文件，进而构建"调试"和"授权用户"的身份框架。
渐进诱导攻击
"温水煮青蛙"（有时也称为Crescendo攻击）在多轮交互中逐步引导智能体走向目标行为，利用历史对话建立可信度并营造请求的无害性。密钥提取过程是这样进行的：先尝试执行看似合法的工作流并故意触发错误，最终"发现"错误的根本原因与密钥有关，从而说服智能体将其泄露出来。
误导性操作攻击
包安装等误导性攻击手法（最早在Black Hat 2025的《From Prompts to Pwns》中被描述）至今依然极为有效。通过诱使智能体执行表面无害、实则附带代码执行副作用的操作，通常可以轻松绕过智能体的任何抵抗机制。
编程智能体会定期安装代码库。创建一个恶意代码库，然后要求智能体通过pip install git+https://…进行安装，这看起来是一个标准请求，但经过武器化处理的包会在安装过程中触发任意代码执行。
总结与建议
一个持续发现的规律是：与大语言模型处于同一控制平面的防护措施，尤其是基于提示的防护，会被系统性地绕过。控制措施必须在模型控制平面之外强制执行。
按重要性排序，推荐的控制措施如下：
对智能体实施访问控制，只允许特定的已认证用户与智能体交互；仅在沙箱环境（如Docker、英伟达OpenShell或虚拟机）中执行任意命令，该环境必须经过充分加固以防逃逸，且不能通过写入或编辑环境或智能体配置文件进行自我配置；在智能体涉及的每个边界处实施默认拒绝的网络出口策略，并配以任务所需特定网络资源的最小权限白名单；不向环境暴露静态密钥。虽然将密钥注入环境变量是非智能体应用的标准做法，但对于执行任意代码的工作负载来说并不安全，密钥应存储在密钥管理器中、按需访问，并限制在需要的进程范围内，条件允许时应使用提供最小权限临时Token的Token代理；仅允许从经过验证的包仓库安装包，默认阻止基于任意URL和版本控制系统的安装；对工具、MCP、技能等实施最小权限原则，仅保留任务所需的工具，对任何涉及执行、写入或网络访问的工具进行严格审查；对持久化存储实施最小权限，避免使用卷挂载，确有需要时严格限定范围，绝不将可写路径挂载到后续会被执行的路径下；使用最新的前沿模型，尤其在采用大语言模型评判模式时，这类模型对对抗性操控具有更强的鲁棒性。
英伟达AI红队在AI智能体安全工作中的经验表明，确定性的"硬性"控制措施对于防御AI智能体仍然不可或缺。持有企业凭证的完全自主系统本身就具有高风险，必须采取严密的安全措施。尽管前沿模型增加了对抗性操控的难度，但在充足的时间和专业能力面前，几乎所有模型仍然可以被突破。
我们观察到的常见缺陷包括：访问控制薄弱（允许任意用户访问智能体）、执行和文件写入工具创造了RCE机会、网络出口管控不足导致数据外泄和反向Shell，以及执行环境中可被智能体访问的明文密钥。
基于提示的防护栏（包括大语言模型评判模式）无法填补以上任何漏洞。架构层面的控制措施才是关键：对智能体的访问控制、对企业数据实施最小权限访问的加固沙箱、默认拒绝的网络出口管控，以及将密钥置于智能体无法触及之处。经过正确配置和执行，这些控制措施能够有效降低AI智能体遭受恶意利用的风险。
Q&A
Q1：英伟达AI红队发现了哪些AI智能体最常见的安全漏洞？
A：英伟达AI红队在评估多个AI智能体后发现了四大核心失效模式：缺乏访问控制（任何内部用户都能访问智能体）、支持任意代码执行的工具（如Bash shell）、缺少网络出口管控（允许数据外泄和建立反向Shell），以及密钥以明文形式暴露在执行环境中。这些问题与所使用的框架无关，在几乎所有被评估的智能体中都有出现。
Q2：攻击者用哪些方法绕过AI智能体的提示层防护？
A：主要有三种有效手法：一是伪造合法场景，比如声称自己是"管理员"或"调试人员"来骗取智能体配合；二是渐进诱导攻击（即"温水煮青蛙"或Crescendo攻击），通过多轮对话逐步引导智能体暴露密钥或执行危险操作；三是误导性操作攻击，例如让智能体安装一个看似正常、实则恶意的Python包，在安装过程中触发任意代码执行。
Q3：如何有效保护AI智能体中的密钥安全？
A：核心原则是永远不要让智能体直接接触持久性密钥。具体做法包括：将密钥存储在专用密钥管理器中而非环境变量中；仅在需要时于对应进程的内存中按需获取密钥；确保密钥不出现在智能体的上下文窗口和执行环境中；每次任务使用短期且权限受限的临时Token，任务完成后立即撤销，尽量使用Token代理来动态签发最小权限凭证。
热门跟贴