提示词过滤为何失效以及替代方案

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

我见过的每一种提示词注入防御措施都犯了同样的错误。它们问错了问题。
错误的问题：“这个提示词是否包含危险词汇？”
正确的问题：“不受信任的内容是否试图成为指令来源？”
这些是根本不同的问题。

过滤的局限性
关键词过滤之所以失败，是因为攻击者会适应。对你的攻击内容进行 Base64 编码。使用 ROT13 加密。进行 URL 编码。将字符用空格隔开。将其包裹在代码块中。过滤器看不到任何危险内容。模型则会遵循这些指令。
上周，有人在我们的公开红队环境中发现了这些编码变体后，我们修补了所有这类漏洞。攻击者不得不付出更多努力。但他们在第一次尝试时就成功了。
过滤是一场你最终总会输掉的军备竞赛。

真正的威胁模型
提示词注入关乎的不是危险词汇，而是未经授权的指令权限转移。
你的智能体有着清晰的层级结构：系统提示词位于顶层，开发者指令次之，用户请求再次之。攻击发生时，来自该层级结构之外的内容——如网页、电子邮件、工具返回结果或检索到的文档——试图将自己插入为更高权限的指令来源。
一个网页告诉你的智能体“忽略之前的指令”，其危险性并非源于这些词汇本身。危险在于，一个零权限的来源正试图覆盖高权限的来源。

解决方案：基于来源的权限强制执行
每个内容片段都应携带一个信任等级：
• 系统提示词：100
• 开发者指令：90
• 用户输入：50
• 工具输出：10
• 网页：10
• 电子邮件：10
• 检索到的文档：10
规则：低权限来源可以提供数据，但不能发出指令。
当网页页脚显示“忽略之前的指令”时——这不仅仅是一个危险的短语，更是一种来源边界违规。这是一个零权限来源试图获取行为权限。

实际应用场景

from langchain_arcgate import ArcGateCallback
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(callbacks=[ArcGateCallback(api_key="demo")])

只需一行代码。每个提示词在到达模型之前都会被打上来源标签。试图进行指令权限转移的不受信任内容，会在模型看到之前被拦截或沙箱化。
对于模糊情况——即内容可疑但并非明显恶意的情况——系统会降低其能力而非硬性拦截。智能体将在剥离工具调用和外部操作的情况下安全继续运行。这是一种优雅降级，而非非黑即白的拦截或允许。

尝试破解它
我们运行着一个公开的对抗性评估环境。提交攻击，获取完整的安全追踪记录，下载 JSON 报告。
https://web-production-6e47f.up.railway.app/break-arc-gate
上周有人发现了一种嵌套编码绕过方法。该方法已在公开故障档案中修补并记录在案。
GitHub：https://github.com/9hannahnine-jpg/arc-gate
由 Bendex Geometry 构建。