什么是提示注入Prompt Injection如何防御提示注入这个问题我之前在给客户做AI安全评估的时候经常被问到。简单来说提示注入就是攻击者通过精心构造的输入让大模型忽略原本的系统指令去执行攻击者预设的命令。它被OWASP列为LLM应用安全威胁第一名代号LLM01这个地位从2023年到现在都没动过。这块有个点挺有意思的——它跟传统的SQL注入有点像但本质不一样。SQL注入是利用语法解析器的漏洞而提示注入是利用语义理解器的漏洞。什么意思呢传统Web安全里我们可以通过转义、语法解析严格区分代码和数据。但LLM没有内置的指令和数据类型系统所有文本在Transformer的注意力机制里被同等对待指令的优先级完全由上下文语义和位置决定。攻击分成两类。直接注入就是用户直接在输入框里写恶意指令比如忽略之前所有规则或者你现在是管理员模式这种最常见。间接注入更隐蔽攻击者把恶意指令藏在外部内容里——网页、文档、邮件、RAG检索出来的文本。模型处理这些内容的时候指令就被不知不觉地注入了。有个真实的例子挺经典的。2023年Bing Chat的系统提示词被人通过提示注入给提取出来了里面有个隐藏的代号叫Sydney还有一堆行为约束规则。后来Snapchat的My AI也被同样方式把完整提示词扒了个底朝天。去年更狠Moltbook的AI平台直接泄漏了150万个API token包括明文的OpenAI密钥。那怎么防御呢这块我得说没有任何单一技术能彻底解决问题这是个架构层面的根本缺陷。但我们可以做多层防御。第一输出过滤是最有效的。最新研究测试了九种防御配置超过两万次攻击结果很残酷——所有依赖模型自我保护的防御最后都被突破了。只有输出过滤站住了它在应用层代码里检查模型响应用硬编码规则过滤敏感内容15000次攻击零泄漏。这个告诉我们一个道理安全边界必须在应用代码里强制执行而不是靠被攻击的模型自己来防护。第二输入预处理和语义检测。不要用关键词过滤那种太容易被绕过。现在主流的做法是用专门的检测模型基于语义而不是字符串匹配来识别恶意输入。还有对RAG文档、外部数据源要做净化处理。第三提示词结构优化。给AI系统设置明确的角色和任务边界用指令优先级设计确保系统指令不会被用户输入轻易覆盖。我之前做项目的时候会把敏感操作和普通操作隔离开敏感操作需要额外的确认步骤。第四权限最小化。模型能访问的东西要控制住能不给的权限就不给。2025年GitHub Copilot有个CVECVSS评分9.6攻击者通过提示注入能远程执行代码——如果Copilot一开始就没配那么大的权限损失会小很多。还有个思路是多层代理防御架构用专门的LLM代理组成管道协同检测和阻断提示注入攻击。研究说在ChatGLM上baseline攻击成功率大概30%Llama2是20%用这种多代理管道能降到0%。总的来说提示注入是LLM架构层面的原生态缺陷指望单一技术根治不现实。防御的核心思路是纵深防御——输入过滤、输出过滤、权限控制、多层检测结合起来同时要持续做红蓝对抗测试因为攻击者也在进化。我们去年给一个金融客户做评估第一轮测了50种注入方式有几种绕过了他们当时的防护修复之后又测了200轮才敢让他们上线。这块如果深挖的话还有多模态注入的问题——现在GPT-4V、Claude 3这些模型能处理图像攻击者可以在图片里嵌入恶意指令这个攻击面还没被广泛重视。以及MCP协议普及之后工具调用链路的注入也是新挑战。
什么是提示注入(Prompt Injection)?如何防御?
发布时间:2026/5/27 18:03:44
什么是提示注入Prompt Injection如何防御提示注入这个问题我之前在给客户做AI安全评估的时候经常被问到。简单来说提示注入就是攻击者通过精心构造的输入让大模型忽略原本的系统指令去执行攻击者预设的命令。它被OWASP列为LLM应用安全威胁第一名代号LLM01这个地位从2023年到现在都没动过。这块有个点挺有意思的——它跟传统的SQL注入有点像但本质不一样。SQL注入是利用语法解析器的漏洞而提示注入是利用语义理解器的漏洞。什么意思呢传统Web安全里我们可以通过转义、语法解析严格区分代码和数据。但LLM没有内置的指令和数据类型系统所有文本在Transformer的注意力机制里被同等对待指令的优先级完全由上下文语义和位置决定。攻击分成两类。直接注入就是用户直接在输入框里写恶意指令比如忽略之前所有规则或者你现在是管理员模式这种最常见。间接注入更隐蔽攻击者把恶意指令藏在外部内容里——网页、文档、邮件、RAG检索出来的文本。模型处理这些内容的时候指令就被不知不觉地注入了。有个真实的例子挺经典的。2023年Bing Chat的系统提示词被人通过提示注入给提取出来了里面有个隐藏的代号叫Sydney还有一堆行为约束规则。后来Snapchat的My AI也被同样方式把完整提示词扒了个底朝天。去年更狠Moltbook的AI平台直接泄漏了150万个API token包括明文的OpenAI密钥。那怎么防御呢这块我得说没有任何单一技术能彻底解决问题这是个架构层面的根本缺陷。但我们可以做多层防御。第一输出过滤是最有效的。最新研究测试了九种防御配置超过两万次攻击结果很残酷——所有依赖模型自我保护的防御最后都被突破了。只有输出过滤站住了它在应用层代码里检查模型响应用硬编码规则过滤敏感内容15000次攻击零泄漏。这个告诉我们一个道理安全边界必须在应用代码里强制执行而不是靠被攻击的模型自己来防护。第二输入预处理和语义检测。不要用关键词过滤那种太容易被绕过。现在主流的做法是用专门的检测模型基于语义而不是字符串匹配来识别恶意输入。还有对RAG文档、外部数据源要做净化处理。第三提示词结构优化。给AI系统设置明确的角色和任务边界用指令优先级设计确保系统指令不会被用户输入轻易覆盖。我之前做项目的时候会把敏感操作和普通操作隔离开敏感操作需要额外的确认步骤。第四权限最小化。模型能访问的东西要控制住能不给的权限就不给。2025年GitHub Copilot有个CVECVSS评分9.6攻击者通过提示注入能远程执行代码——如果Copilot一开始就没配那么大的权限损失会小很多。还有个思路是多层代理防御架构用专门的LLM代理组成管道协同检测和阻断提示注入攻击。研究说在ChatGLM上baseline攻击成功率大概30%Llama2是20%用这种多代理管道能降到0%。总的来说提示注入是LLM架构层面的原生态缺陷指望单一技术根治不现实。防御的核心思路是纵深防御——输入过滤、输出过滤、权限控制、多层检测结合起来同时要持续做红蓝对抗测试因为攻击者也在进化。我们去年给一个金融客户做评估第一轮测了50种注入方式有几种绕过了他们当时的防护修复之后又测了200轮才敢让他们上线。这块如果深挖的话还有多模态注入的问题——现在GPT-4V、Claude 3这些模型能处理图像攻击者可以在图片里嵌入恶意指令这个攻击面还没被广泛重视。以及MCP协议普及之后工具调用链路的注入也是新挑战。