Myšlenkové vůdce
无秘密的必要性：当AI智能体触及代码时，传统安全模型为何失效
V květnu 2023 三星公司发现其工程师向ChatGPT泄露了敏感信息。但那是意外。现在想象一下，如果那些代码仓库中包含的是蓄意植入的指令，这些指令对人类不可见，但会被AI处理，其设计目的不仅是提取代码，还包括提取AI能够访问的每一个API密钥、数据库凭证和服务令牌。这并非假设。 安全研究人员已经证明这些“隐形指令”攻击是有效的。问题不在于这是否会发生，而在于何时发生。
不复存在的边界
几十年来，我们建立安全体系的基础假设是：代码是代码，数据是数据。SQL注入教会我们对查询进行参数化。跨站脚本教会我们对输出进行转义。我们学会了在程序行为和用户输入之间筑起高墙。
对于AI智能体而言，这条边界已经蒸发。
与遵循可预测路径的确定性软件不同，大型语言模型是概率性的黑盒，无法区分合法的开发者指令和恶意输入。当攻击者向AI编码助手提供提示时，他们不仅仅是在提供数据。他们实质上是在动态地重新编程应用程序。输入本身已经变成了程序。
这代表着与我们已知的应用安全知识发生了根本性的断裂。传统的基于语法的防火墙，它们寻找诸如 DROP TABLE 或 <script> 标签之类的恶意模式，在面对自然语言攻击时完全失效。研究人员已经展示了“语义替换”技术，即在提示中将“API密钥”替换为“苹果”，可以让攻击者完全绕过过滤器。当意图被伪装成无害的对话时，你如何为意图设置防火墙？
无人讨论的零点击现实
这是大多数安全团队不了解的：提示注入并不需要用户输入任何内容。这些通常是零点击漏洞利用。一个AI智能体仅仅是为了执行例行任务而扫描代码仓库、审查拉取请求或阅读API文档，都可能在没有任何人工交互的情况下触发攻击。
考虑以下基于研究人员已经证明的技术的场景：恶意行为者在一个流行的开源库的文档中的HTML注释里嵌入了隐形指令。每一个分析此代码的AI助手，无论是GitHub Copilot、Amazon CodeWhisperer，还是任何企业级编码助手，都变成了潜在的凭证收集器。一个被攻陷的库可能意味着成千上万个开发环境暴露无遗。
危险不在于LLM本身；而在于我们赋予它的代理权。从我们将这些模型与工具和API集成，让它们获取数据、执行代码和访问秘密的那一刻起，我们就将有用的助手转变成了完美的攻击向量。风险并不随模型的智能程度而线性增长；它随其连接性而增长。
为何当前方法注定失败
业界目前痴迷于“对齐”模型和构建更好的提示防火墙。OpenAI增加了更多的护栏。Anthropic专注于宪法AI。每个人都在试图制造不会被欺骗的模型。
这是一场必败之战。
如果一个AI足够聪明到有用，那么它也足够聪明到被欺骗。我们正陷入我称之为“净化陷阱”的境地：假设更好的输入过滤能拯救我们。但攻击可以被隐藏在HTML注释中的隐形文本里，深埋在文档中，或以我们尚未想象的方式编码。你无法净化你无法在语境中理解的东西，而语境正是LLM强大的原因。
业界需要接受一个残酷的事实：提示注入将会成功。问题是当它成功时会发生什么。
我们需要的架构转变
我们目前正处于“打补丁阶段”，拼命地添加输入过滤器和验证规则。但正如我们最终认识到防止SQL注入需要参数化查询，而不是更好的字符串转义一样，我们需要一个针对AI安全的架构解决方案。
答案在于一个听起来简单但需要我们重新思考如何构建系统的原则：AI智能体永远不应该拥有它们所使用的秘密。
这不是一个
这并非关于更好的凭证管理或改进的保险库解决方案。而是关于将AI智能体识别为独特、可验证的身份，而非需要密码的用户。当AI智能体需要访问受保护资源时，它应该：
-
使用其可验证身份进行认证（而非使用存储的密钥）
-
接收仅对该特定任务有效的即时凭证
-
让这些凭证在数秒或数分钟内自动过期
-
永不存储甚至“看到”长期有效的密钥
目前正在涌现几种方法。 Role AWS IAM pro servisní účty, Identita pracovní zátěže od Googlu, Dynamická tajemství trezoru HashiCorp，以及像Akeyless的Zero Trust Provisioning这样的专用解决方案，都指向这个无密钥的未来。具体实现细节各不相同，但原则不变：如果AI没有可窃取的密钥，提示词注入的威胁就会大大降低。
2027年的开发环境
三年之内，在AI增强的开发中，.env文件将不复存在。存放在环境变量中的长期API密钥将被视为我们今天看待明文密码一样：一个更天真时代的尴尬遗物。
取而代之的是，每个AI智能体都将在严格的权限分离下运行。默认情况下只有只读访问权限。操作白名单成为标准。沙箱执行环境成为合规要求。我们将不再试图控制AI的思考，而是完全专注于控制它能做什么。
这不仅仅是一次技术演进；更是一次信任模型的根本性转变。我们正从“信任但要验证”转向“永不信任，始终验证，并假设已被入侵”。最小权限原则，这个被长期宣扬但很少实践的原则，当你的初级开发员是一个每天处理数千个潜在恶意输入的AI时，将变得不容妥协。
我们面临的选择
AI融入软件开发是不可避免的，并且大体上是有益的。 GitHub报告称，使用Copilot的开发人员完成任务的速度提高了55%。生产力的提升是真实的，任何希望保持竞争力的组织都不能忽视这一点。
但我们正站在一个十字路口。我们可以沿着当前的道路继续前进，增加更多的护栏，构建更好的过滤器，希望我们能制造出不会被欺骗的AI智能体。或者，我们可以承认威胁的根本性质，并据此重建我们的安全架构。
三星事件是一个警告。下一次泄露将不会是偶然的，也不会仅限于一家公司。随着AI智能体获得更多能力并访问更多系统，潜在影响将呈指数级增长。
对于每一位首席信息安全官、每一位工程负责人和每一位开发人员来说，问题很简单：当提示词注入在你的环境中成功时（这将会发生），攻击者会发现什么？他们会发现一个长期有效凭证的宝库，还是会发现一个尽管已被入侵却无密钥可窃取的AI智能体？
我们现在做出的选择将决定AI是成为软件开发的伟大加速器，还是我们创造过的最大漏洞。构建安全、无密钥AI系统的技术今天已经存在。问题在于我们是否会在攻击者迫使我们之前实施它。
OWASP已将提示词注入列为LLM应用十大风险之首. NIST正在制定零信任架构指南。框架已经存在。唯一的问题是实施速度与攻击演变的赛跑。
