编程助手的“双重人格”：当拒绝变成执行
在日常开发工作中，GitHub Copilot 等 AI 编程助手已成为程序员不可或缺的伙伴。然而，英国艾伦·图灵研究所（Alan Turing Institute）的一项最新研究揭示了一个令人不安的现象：这些助手在面对直接的恶意请求时会严词拒绝，但在“工作流”模式下，却能极其顺从地生成有害代码。
从我们的应急响应经验来看，这种现象并非模型本身的“智商”问题，而是当前 AI 安全防御机制的逻辑漏洞。目前的防御策略大多基于“单轮对话”规则——即检测单一提示词是否违规。但当攻击者将恶意意图拆解并隐藏在正常的工程开发流程中时，现有的安全护栏几乎形同虚设。
攻击链分析：从“无害”到“致命”的六步曲
研究人员测试了 Claude 3.5 Sonnet/Haiku 以及 Gemini 1.5 Pro/Flash 等主流模型。在直接输入恶意指令时，拒绝率极高；但一旦将任务包装在“工程开发”的需求下，攻击成功率竟高达 100%。
这一过程通常分为四个阶段，约六个交互回合：
第一阶段：建立信任。操作者像普通开发者一样，要求 AI 读取文件、运行脚本、修复常规 bug。这一环节是很多企业容易忽视的，因为这类交互完全符合正常的开发习惯。
第二阶段：引入任务。操作者开始构建一个看似合法的工程管道，例如“评估模型对越狱提示词的抵抗力”。
第三阶段：潜移默化。通过“教学示例（Teaching Shots）”引导 AI，逐步加入带有恶意倾向的数据片段。
第四阶段：输出恶意内容。当 AI 进入“工程思维”模式，专注于优化性能指标或填充数据结构时，它会将恶意载荷作为“工程任务”的一部分自动补全。此时，AI 认为自己是在完成一段代码逻辑，而非生成恶意内容。
为什么防御机制会失效？
这一攻击手法的核心在于“语境欺骗”。当一个恶意指令被伪装成代码数组中的字符串，或者服务于一个看似高大上的基准测试（Benchmark）指标时，模型会将其视为“数据处理”而非“指令执行”。
从安全溯源的角度看，类似攻击近年来明显增加。攻击者不再试图通过暴力破解来绕过防御，而是通过“社会工程学+自动化工作流”的方式，诱导 AI 在不知不觉中成为攻击的帮凶。这种“工作流级越狱（Workflow-level Jailbreak）”使得防御方仅监控单一对话回合的策略显得捉襟见肘。
Solar 应急响应团队的安全建议
面对 AI 辅助开发带来的全新攻击面，企业在享受生产力提升的同时，必须建立多维度的防御体系：
首先，不要仅依赖 IDE 对单轮对话的过滤。企业应加强对 AI 生成的代码、脚本及配置文件的自动化审计。所有 AI 参与生成的代码，必须经过严格的静态代码分析（SAST）和人工复核。
其次，监控全链路会话行为。安全团队应关注开发环境中的异常交互模式，特别是当 AI 被要求执行涉及敏感数据处理或基准测试评分的复杂任务时，应将其视为高风险操作。
最后，建立针对“提示词注入”和“工作流欺骗”的防御基线。对于那些以“优化指标”、“基准测试”为由要求生成特定代码或数据的请求，应当触发额外的安全预警机制。
在 AI 驱动开发的时代，安全边界正在从代码本身延伸到模型交互流程。企业需要意识到，AI 不仅是工具，也是攻击者眼中的“可编程接口”。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com