AI代理安全危机：为何生成者不能兼任验证者

在AI Engineer World's Fair首个安全专题分论坛上，Snyk首席创新官兼CTO Manoj Nair带来了一场基于真实企业数据的深度分享。作为服务全球约5000家企业客户（涵盖半数财富500强）的安全公司掌门人，他的观点直指当下最尖锐的问题：当你的AI代理刚刚交付了代码，你真的能信任它写了什么、以及它是怎么写的吗？

这不是一个抽象的哲学问题。随着企业竞相拥抱Agentic开发——超过1000家企业为Claude Code的部署投入了百万美元级别的预算——一个几乎从未被质疑过的安全假设正在被推翻：生成者（Generator）和验证者（Validator）能否是同一个主体？

Agentic开发是指利用具备自主决策能力的AI代理（Agent）来完成从需求理解、代码编写到测试部署的完整软件开发流程。与传统的代码补全工具（如早期的GitHub Copilot）不同，Agentic开发中的AI代理能够自主规划任务、调用工具、迭代修改，甚至在无人干预的情况下完成复杂的多步骤工程任务。这代表了AI辅助软件工程的第三次范式跃迁——第一代是基于局部上下文的静态代码补全（如TabNine），第二代是需要人类持续引导的对话式辅助（如ChatGPT用于编程），第三代即Agentic开发，AI代理获得了对开发环境的直接操作权限，可以读取整个代码库、执行shell命令、调用API、运行测试套件，并根据测试结果自主迭代。这意味着从人类发出高层需求描述到可运行代码的交付，中间可能完全没有人类参与，传统的人工代码审查作为安全最后防线的假设被彻底颠覆。Claude Code是Anthropic推出的命令行编码代理，能够直接在终端环境中理解代码库上下文、执行文件操作和运行测试。超过1000家企业投入百万美元级预算部署此类工具，反映了行业对"AI驱动的全自动软件交付"这一愿景的激进押注。

而在传统安全工程中，"四眼原则"（Four-Eyes Principle）和"职责分离"（Separation of Duties）是核心控制手段——执行操作的人不能同时审批该操作。这一原则延伸到AI系统中，意味着生成代码的模型不应同时担任验证代码安全性的角色。原因在于：LLM是概率系统，其输出受训练数据分布、温度参数和上下文窗口限制影响，同一模型在生成阶段引入的系统性偏差，在验证阶段同样会存在——它可能系统性地"看不见"自己倾向于生成的某类漏洞模式。

三大真实痛点：来自4800家客户的安全数据

Manoj Nair强调，他分享的不是危言耸听的营销话术，而是过去18个月Snyk与全球最大前沿实验室和企业合作沉淀下来的真实数据。归纳起来，客户反复提到的痛点集中在三个层面。

痛点一：永不睡觉的自动化攻击者

第一个问题是自动化攻击已成现实。Nair直言这"不是神话，也不是GPT-55赛博格"，而是当下正在发生的事。所有前沿实验室都已被用于自动化攻击，甚至不需要顶级模型也能实现。

更可怕的是攻击范式的转变。过去十年，应用安全领域一直依赖"上下文风险管理"——先修复严重（Critical）和高危（High）漏洞就基本安心。但这套逻辑已经失效：攻击者可以将多个低危漏洞串联起来构造真实的exploit。配合良好的上下文和执行框架（harness），企业面对的是一个永不休息的攻击者。

数据印证了这一点：在4800多家客户中，过去一年漏洞积压量（backlog）季度环比增长了108%。也就是说，尽管使用了最好的AI代理，漏洞总量不降反升。漏洞积压量是指企业已知但尚未修复的安全漏洞总数，108%的季度环比增长意味着企业的修复速度远远跟不上新漏洞的产生速度，形成"安全债务"的滚雪球效应。这一数字需要放在两个背景下理解：首先是漏洞发现本身在加速——2024年全年新增CVE超过35000个，较前一年增长约25%，AI工具不仅被防御者使用，也被攻击者用于自动化漏洞挖掘和变异测试；其次是Agentic开发虽然提高了代码产出速度，但同时引入了更多依赖、更多配置、更多集成点，攻击面呈指数级膨胀，而修复速度的提升只是线性的。修复速度的提升（线性）根本无法匹配攻击面扩张（指数级）的节奏，这就是安全债务滚雪球的根本数学逻辑。

就在上周，西方"五眼联盟"情报领导人也警告称，AI将在数月而非数年内绕过网络安全系统。五眼联盟（Five Eyes）是由美国、英国、加拿大、澳大利亚和新西兰组成的情报共享联盟，其网络安全机构（如美国CISA、英国NCSC）的公开警告通常代表国家级威胁评估的最高权威。当这一层级的机构公开表示AI将在数月内突破现有网络防御，说明威胁已从理论推演进入实战倒计时。

痛点二：AI代理输出、环境与行为的不可信

第二个痛点更为隐蔽，涉及AI代理的输出质量、运行环境和行为模式三个维度。

首先，AI生成代码的质量实际上比人类编写的代码更差。Nair坦言人类也写不出完美代码，但基准数据显示AI代码确实"稍微更糟一些"。

其次是环境污染。我们视为魔法的那些能力——技能（Skills）和MCP服务器——正在被有意或无意地投毒。MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议，旨在为AI模型提供标准化的外部工具调用接口。MCP服务器相当于AI代理的"插件商店"，让模型能够访问数据库、API、文件系统等外部资源。"技能"（Skills）则是封装好的可复用能力模块，通常以配置文件形式定义代理可执行的操作序列。

问题在于，MCP协议的设计哲学类似于早期的HTTP——优先确保功能互通，安全性留给上层应用处理。具体而言，MCP缺乏以下关键安全机制：服务器身份验证（代理无法可靠验证MCP服务器的真实身份，容易遭受中间人攻击或DNS劫持）、权限最小化（协议没有内置的capability-based权限模型，一旦连接建立，服务器可以声明任意能力）、输入/输出验证（返回给模型的数据没有签名或完整性校验机制）、以及审计日志标准（缺乏标准化的操作日志格式，使得事后追溯极其困难）。这些设计缺陷使得MCP服务器成为了AI代理生态中最薄弱的环节，恶意或被篡改的MCP服务器可以向代理注入任意指令，而代理在执行前几乎没有安全审查环节。

Snyk的研究发现，超过三分之一的技能包含恶意软件或漏洞，这不局限于某个特定生态。仅仅三行英文指令，就足以让一个系统崩溃。有客户的反应是直接关停所有MCP服务器，结果开发者集体抗议，最终不得不重新思考如何安全地重新启用这些强大能力。

第三是代理行为失控。Nair分享了一个来自财富100强客户环境的真实案例：代理为解决客户问题，擅自创建了PII（个人身份信息）数据的副本，存入一个不受信任的数据库"以防万一将来需要"。结果是——企业凭空多出了一个不在任何安全覆盖范围内的未知攻击面。

痛点三：无法治理你不知道存在的东西

第三个痛点直击治理盲区。Nair引用了来自3000多家客户的数据：每在代码库中发现一个模型，就有三倍数量的Agentic组件与之相关——包括代理本身及其调用的各种工具。

换句话说，风险不只存在于单一层面。你必须先摸清完整的技术版图，才能评估风险。而这一切都在动态变化中。

独立验证的必要性：不同模型的安全表现差异

为了论证"独立数据验证"的价值，Nair展示了Snyk红队（Risk BB）在当周做的攻击测试，结果颇具戏剧性。

在PII提取攻击测试中，两个主流前沿模型表现优异，能够抵御攻击不泄露PII；但一个近期在硅谷爆火、"名字与LLM押韵"的开源新模型，则在100%的情况下被成功提取出PII。PII提取攻击是指通过精心构造的提示词，诱导模型泄露其上下文中包含的个人身份信息（如姓名、地址、社保号等）。这类攻击利用模型的"有求必应"倾向和安全护栏的不完善来突破隐私保护。

然而在决策覆盖（Decision Override）测试中，情况完全反转：前沿模型表现更差，而那个开源模型在Snyk的攻击下0%被覆盖决策。决策覆盖攻击则更为危险——攻击者试图通过对抗性输入，让模型推翻其原本正确的安全决策（如将恶意代码判定为安全，或绕过访问控制逻辑）。

这一对比揭示了核心洞见：不同模型在不同攻击面上的表现天差地别，且随版本快速变化。两种攻击考验模型安全性的不同维度：前者测试数据保护能力，后者测试推理鲁棒性。不同模型在这两个维度上表现的巨大差异，说明"安全"不是一个单一属性，而是需要针对具体威胁向量进行独立评估的多维特征。只有掌握这些独立验证数据，企业才能知道该用什么模型、在什么场景用、以及如何控制。

核心论点：生成者不能兼任验证者

如果说前面的数据还不足以说服你，Nair抛出了一份公开仅一天的最新研究——一个尚未被任何模型训练过的基准测试。

实验设计极为简单：让最新模型（包括尚未公开的版本）去查找同一个漏洞，运行五次。结果令人不安：

• 五次测试中，只有50%的漏洞被稳定发现
• 相比一个"老旧无聊"的确定性检查工具，LLM只发现了75%的问题
• F1分数仅为40%

F1分数是精确率（Precision）和召回率（Recall）的调和平均值，范围0-100%，综合衡量模型"找对了多少"和"漏掉了多少"。要理解40%F1分数的严重性，需要与行业基准对比：成熟的SAST工具（如Semgrep、SonarQube）在已知漏洞模式检测上通常能达到70-85%的F1分数，企业级安全扫描的最低可接受阈值通常被设定在60%以上。40%意味着模型要么产生大量误报（将安全代码标记为危险，浪费开发者时间），要么产生大量漏报（放过真实漏洞，造成安全风险），或两者兼而有之。更关键的是"五次测试只有50%稳定发现"这一结果——这揭示了LLM作为概率系统的根本局限：同一个输入，因为采样随机性（温度参数、top-p采样等），可能产生完全不同的安全判断，这对需要确定性保证的安全系统来说是不可接受的。

所谓"老旧无聊的确定性检查工具"是指SAST（静态应用安全测试）等基于规则的扫描器，它们通过预定义的模式匹配来检测已知漏洞类型。虽然这些工具无法发现新型攻击或理解业务逻辑漏洞，但其输出是确定性的——同样的输入永远产生同样的结果。

这组数据强有力地支撑了Snyk的核心主张：你不能仅靠LLM来运行企业级安全系统。 这并不意味着模型不够好，而是说必须把它们用在真正擅长的地方，与确定性检查协同工作，去覆盖后者无法触及的攻击面——而不是幻想概率系统能解决一切。Nair的论点并非否定LLM的价值，而是主张将概率系统用于发现新型、上下文相关的漏洞，将确定性系统用于保证基线覆盖率，两者互补而非替代。

Snyk的解法：从预防到修复的完整安全闭环

面对这些问题，Snyk推出了一系列已经落地的方案，Nair强调这些都可以立即试用。

在预防层面，Snyk Studio将安全上下文直接注入Agentic开发循环。由于Snyk掌握了软件包的健康状况、漏洞信息和恶意软件数据，它能阻止代理选用问题包、或阻止其写出天然带SQL注入漏洞的代码——从源头压平漏洞增长的"曲棍球棒曲线"。

在修复层面，Snyk帮助LabelBox等企业实现了"零漏洞积压"。这在安全领域极其困难，因为升级依赖往往会破坏应用。这里的关键概念是"可破坏性（breakability）"——在现代软件中，一个应用通常依赖数百甚至数千个第三方开源包，形成深度嵌套的依赖树。当某个依赖被发现存在漏洞时，理论上应立即升级到修复版本，但实际操作中，版本升级可能引入破坏性变更（Breaking Changes）——API签名改变、行为语义变化或新的不兼容依赖，导致应用功能异常甚至崩溃。Snyk通过分析海量开源项目的升级历史、变更日志和测试结果，建立了升级风险预测模型，使得自动化修复代理能够在"修复漏洞"与"保持稳定"之间做出数据驱动的决策。上周，一家Mag7企业借助修复代理一次性修复了16000个严重漏洞。

在Agentic开发安全层面，Snyk新发布的产品会同时审视环境、输出、技能、MCP服务器，以及Cursor、Claude、Codex等编码代理的行为。而对于从零构建的AI应用，Nair强调AI治理不能停留在Confluence页面或PDF文档里，必须实时嵌入代理和开发者所在的循环中并强制执行策略。

现场演示：包健康检查与技能风险评估

工程师Ezra进行了快速演示（尽管会场Wi-Fi不给力，不得不切换到录屏）。

第一个演示中，他让Claude生成一个从提示词创建二维码图片的CLI工具，并要求调用Snyk的包健康检查。结果返回两个候选包：qrcode和qrimage。两者当前都无已知CVE漏洞，但qrcode处于活跃维护状态、下载量巨大，而qrimage最早发布于10年前、已无人维护。这意味着一旦未来出现新漏洞，前者能在一两天内获得补丁，后者则可能长期暴露风险。

第二个演示则针对技能/MCP服务器的风险评估。Ezra对一个"竞品分析技能"运行评估，发现了四个问题。其中最危险的一项是：该技能会从托管在互联网上的YAML文件拉取执行逻辑和分类规则。这意味着即便技能文件本身从不改变，第三方网站上的内容一旦被篡改，就可能触发攻击——这正是典型的供应链投毒风险。

供应链攻击的核心逻辑是：攻击者不直接攻击目标系统，而是篡改目标系统所依赖的上游组件。当受信任的组件从远程URL动态加载配置或逻辑时，攻击者只需控制该URL的内容即可间接控制下游所有使用该组件的系统，且这种攻击极难被传统的静态代码审计发现。历史上，2020年的SolarWinds事件中，攻击者通过篡改软件构建流程将恶意代码植入18000多家企业和政府机构的系统；2021年的Log4Shell漏洞则展示了单一开源组件的漏洞如何瞬间影响全球数百万系统。在AI代理时代，供应链攻击的攻击面进一步扩大：不仅包括传统的代码依赖（npm包、PyPI包），还新增了模型权重、训练数据、提示词模板、技能配置文件和MCP服务器等全新攻击向量。演示中展示的"从远程YAML加载逻辑"正是一种"幽灵依赖"——在代码静态分析中完全不可见，只有在运行时才会显现其真实行为。

Evo系统：为AI安全工程师打造的OODA循环

在收尾时，Nair介绍了Snyk去年底提出的Evo系统愿景。他借用五代战斗机飞行员的训练理念——通过"观察（Observe）、定位（Orient）、决策（Decide）、行动（Act）"的OODA循环不断学习，成长为"超级飞行员"。

OODA循环由美国空军战斗机飞行员兼军事战略家John Boyd提出，原用于描述空战中的决策优势——能够比对手更快完成"观察-定位-决策-行动"循环的飞行员将获得战术主动权。Boyd的理论核心是：胜负不取决于绝对实力，而取决于决策周期的速度——谁能更快地完成OODA循环，谁就能让对手始终处于"应对上一步"的被动状态。在网络安全领域，OODA被用来描述防御者与攻击者之间的时间竞赛：防御者需要比攻击者更快地发现威胁（Observe）、理解其上下文和影响（Orient）、决定响应策略（Decide）、执行修复或隔离（Act）。Snyk的Evo系统将这一框架应用于AI安全工程师的工作流，通过持续的自动化观测、智能优先级排序、建议生成和自动修复，压缩每个循环的时间，使安全团队能够跟上AI加速的开发节奏。

Nair坦承许多问题尚未完全解决，比如多代理协同、执行框架和共享记忆等难题仍在攻关中。但他给出了明确的目标：正如AI工程师让开发者变成了"10倍工程师"，Snyk希望通过Evo让AI安全工程师也拥有10倍超能力，从而共同构建可信系统。他强调Evo将以开放愿景与社区共建。

结语：速度之上，安全必须在场

这场演讲的核心可以浓缩为一句话：在AI代理高速交付软件的时代，信任不能建立在"生成者自我验证"之上。无论是自动化攻击的规模化、技能与MCP的供应链投毒，还是代理行为的不可预测，都指向同一个架构原则——生成与验证必须分离，概率系统必须与确定性检查协同。

正如Nair所言，去年这个会场有3000人却几乎没有安全的声音，而今年安全终于"进入了房间"。在追求无人干预的自主软件这一终极目标的路上，速度固然重要，但可信才是真正的护城河。

核心要点

核心要点