无秘密的强制性：为什么传统的安全模型在 AI 代理接触代码时会失效

2023 年 4 月， 三星公司发现其工程师将敏感信息泄露给 ChatGPT。但那是意外的。现在想象一下，如果这些代码仓库中包含故意植入的指令，对人类来说是不可见的，但由 AI 处理，旨在提取不仅仅是代码，还包括 AI 可以访问的每个 API 密钥、数据库凭证和服务令牌。这不是假设的。 安全研究人员已经证明 这些“不可见指令”攻击是有效的。问题不是是否会发生，而是何时会发生。

不再存在的边界

几十年来，我们一直在一个基本假设的基础上构建安全：代码就是代码，数据就是数据。SQL 注入教会我们参数化查询。跨站点脚本教会我们转义输出。我们学会了在程序执行和用户输入之间建立墙壁。

有了 AI 代理，这个边界已经消失了。

与确定性软件不同，确定性软件遵循可预测的路径，大型语言模型是概率黑盒，无法区分合法的开发者指令和恶意输入。当攻击者向 AI 编码助手提供提示时，他们不仅仅是提供数据。他们实际上是在飞速地重新编程应用程序。输入已经成为程序本身。

这代表了我们对应用程序安全的所有认识的根本性突破。传统的基于语法的防火墙，它们寻找恶意模式，如 DROP TABLE 或 标签，对自然语言攻击完全失败。研究人员已经证明了“语义替换”技术，通过在提示中用“苹果”替换“API 密钥”，攻击者可以完全绕过过滤器。如何防火墙意图，当它被伪装成无害的对话时?

没有人讨论的零点击现实

以下是大多数安全团队不了解的内容：提示注入不需要用户输入任何内容。这些通常是零点击漏洞。AI 代理仅仅通过扫描代码仓库执行常规任务、审查拉取请求或阅读 API 文档，就可以在没有任何人机交互的情况下触发攻击。

考虑以下场景，基于 研究人员已经证明 的技术：恶意行为者在流行的开源库的文档中嵌入不可见的指令，位于 HTML 注释中。每个分析此代码的 AI 助手，无论是 GitHub Copilot、Amazon CodeWhisperer 还是任何企业编码助手，都有可能成为潜在的凭证收集器。一个受损的库可能意味着成千上万的暴露开发环境。

危险不在于 LLM 本身，而在于我们赋予它的权力。我们一旦将这些模型与工具和 API 集成，允许它们获取数据、执行代码和访问机密，我们就将有用的助手转化为完美的攻击向量。风险不随模型的智能而扩大，而是随着其连接性而扩大。

为什么当前的方法注定失败

行业目前痴迷于“对齐”模型和构建更好的提示防火墙。OpenAI 添加更多防护措施。Anthropic 专注于宪法 AI。每个人都试图构建无法被欺骗的模型。

这是一个注定失败的战斗。

如果 AI 足够聪明以至于有用，它就足够聪明以至于被欺骗。我们正在陷入我所谓的“清理陷阱”：假设更好的输入过滤将拯救我们。但攻击可以被隐藏为 HTML 注释中的不可见文本，深埋在文档中，或以我们尚未想象的方式编码。你不能清理你不能理解的上下文，而上下文正是使 LLM 强大的原因。

行业需要接受一个硬性事实：提示注入将会成功。问题是，当它发生时会发生什么。

我们需要的架构转变

我们目前处于“修补阶段”，拼命地添加输入过滤器和验证规则。但是，就像我们最终学会防止 SQL 注入需要参数化查询，而不是更好的字符串转义一样，我们需要一个针对 AI 安全的架构解决方案。

答案在于一个听起来简单但需要重新思考我们如何构建系统的原则：AI 代理永远不应该拥有它们使用的秘密。

这不仅仅是关于更好的凭证管理或改进的金库解决方案。这是关于将 AI 代理识别为唯一的可验证身份，而不是需要密码的用户。当 AI 代理需要访问受保护的资源时，它应该：

1. 使用其可验证身份（而不是存储的密钥）进行身份验证

2. 仅为该特定任务接收即时凭证

3. 凭证在几秒或几分钟内自动过期

4. 永远不会存储或“看到”长期密钥

已经出现了几种方法。 AWS IAM 角色适用于服务账户，谷歌的工作负载身份，HashiCorp Vault 的动态秘密，以及专门为此设计的解决方案，如 Akeyless 的零信任配置，都指向这个无秘密的未来。实现细节各不相同，但原则仍然相同：如果 AI 没有秘密可窃取，提示注入将成为一个较小的威胁。

2027 年的开发环境

在三年内，.env 文件将在 AI 增强开发中死亡。长期 API 密钥存储在环境变量中，将被视为我们现在对明文密码的看法：一个更为天真的时代的尴尬遗物。

相反，每个 AI 代理都将在严格的权限分离下运行。默认为只读访问。操作白名单作为标准。沙盒执行环境作为合规要求。我们将停止尝试控制 AI 的思考，而是专注于控制它可以做什么。

这不仅是一种技术演进，也是信任模型的根本转变。我们正在从“信任但验证”转变为“永不信任，始终验证，假设已被泄露”。最小特权原则，长期以来一直被宣扬但很少被实践，当你的初级开发人员是一个每天处理数千个潜在恶意输入的 AI 时，就变得不可商量了。

我们面临的选择

将 AI 集成到软件开发中的过程是不可避免的，并且在很大程度上是有益的。GitHub 报告称，使用 Copilot 的开发人员完成任务的速度快了 55%。生产力收益是真实的，任何希望保持竞争力的组织都无法忽视它们。

但我们站在一个十字路口。我们可以继续沿着当前的道路前进，添加更多的防护措施，构建更好的过滤器，希望我们可以制造出无法被欺骗的 AI 代理。或者我们可以承认威胁的根本性质，并相应地重建我们的安全架构。

三星事件是一个警告信号。下一次泄露不会是意外的，也不会被限制在一家公司内。随着 AI 代理获得更多功能并访问更多系统，潜在的影响会呈指数级增长。

每个 CISO、每个工程领导者和每个开发人员的问题很简单：当提示注入在您的环境中成功时（并且它会），攻击者会发现什么？他们会发现一个长期凭证的宝藏，还是会发现一个 AI 代理，即使被损害，也没有秘密可窃取?

我们现在做出的选择将决定 AI 是否会成为软件开发的最大加速器，还是我们创造的最大漏洞。构建安全的无秘密 AI 系统的技术今天已经存在。问题是，我们是否会在攻击者迫使我们这样做之前实施它。

OWASP 已经将提示注入识别为 LLM 应用程序的 #1 风险。NIST 正在制定关于零信任架构的指导方针。框架已经存在。唯一的问题是实施速度与攻击演化。