Vordenker
7. Januar 2026
无秘密的必要性:当AI智能体触及代码时,传统安全模型为何失效
4. April 2023,三星公司发现其工程师向ChatGPT泄露了敏感信息.但那是意外.现在想象一下, 如果那些代码仓库中包含的是蓄意植入的指令,这些指令对人类不可见, 但会被AI处理, 其设计目的不仅是提取代码, 还包括提取AI能够访问的每一个API密钥、数据库凭证和服务令牌.这并非假设。 安全研究人员已经证明这些“隐形指令”攻击是有效的.问题不在于这是否会发生，而在于何时发生.不复存在的边界几十年来, SQL-Datenbank.SQL-Datenbank 。我们学会了在程序行为和用户输入之间筑起高墙。对于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智能体需要访问受保护资源时，它应该： 使用其可验证身份进行认证（而非使用存储的密钥） 接收仅对该特定任务有效的即时凭证 让这些凭证在数秒或数分钟内自动过期 永不存储甚至“看到”长期有效的密钥 目前正在涌现几种方法。 AWS IAM roles for service accounts、 Google’s Workload Identity、 HashiCorp Vault’s dynamic secrets，以及像Akeyless的Zero...
