提示词注入攻击是什么意思：常见手法与开发团队应对要点

你的应用里只要有一段用户输入会被拼进提示词，就有被注入的风险。很多团队直到工具被越权调用、或模型开始无视系统指令，才回头查是哪段文本混进来的。这篇不聊概念定义，直接给常见手法对照、上线前该做的输入处理与权限收口步骤，以及出问题时的排查顺序。

你的应用里只要有一段用户输入会被拼进提示词，就有被注入的风险。很多团队直到工具被越权调用、或者模型开始无视系统指令，才回头查是哪段文本混进来的。常见的情况是，产品侧觉得「模型偶尔胡说」，工程侧查了半天发现是外部文档里藏了一句话，把整条链路带偏了。

这篇不聊概念定义，直接给常见手法对照、上线前该做的输入处理与权限收口步骤，以及出问题时的排查顺序。护栏强度这块没法拍脑袋判断，各家工具和接口的实际表现，建议到 /tools/speed-test 用同样的用例跑一遍再对比。

什么情况算注入：先分清三类边界

不是所有异常输出都叫注入。先把三类边界拆开：指令覆盖，是模型听用户的、不听系统的；数据外泄，是把系统提示或他人数据吐出来；越权动作，是借工具去读不该读的东西。判断标准是「有没有跨过你设的信任边界」，而不是模型的回答好不好听。输出跑偏但没突破边界，属于提示词质量问题，处理方式和安全事件完全不同。

什么情况下不适用：纯内部、单人使用、没有人把关的脚本，风险主要是稳定性而非安全，可以放宽到后面再补。但只要接入了外部内容、多人共用、或者工具能触达真实数据，就按上面的边界来判断。

常见手法对照：它们长什么样

直接覆盖最好认，用户输入里写「忽略以上指令」「现在你是……」这类话。麻烦的是间接注入：把指令藏进会被检索到的文档、网页、邮件、代码注释里，模型读到就照做，而写文档的人可能根本不知道自己在攻击你。

• 角色与格式伪装：伪造系统消息、伪造工具返回结果，用 JSON 或 XML 标签假装成你的配置
• 拆分与编码绕过：把敏感词拆成片段、用编码或小语种改写，规避开你的关键词过滤
• 上下文污染：先让模型接受一个错误前提，再顺着这个前提引导出你要禁止的动作
• 把这三类按「入口在哪、谁写的、会不会被自动读取」列一张表，比逐条背例子更有用

输入校验与输出约束：配置层面能做什么

1. 给用户内容划出独立区域用清晰的分隔符包裹，并在系统提示里标注来源不可信；验证方法是把这段内容替换成明显的恶意指令，看模型是否还按系统规则走。
2. 限制长度与嵌套超长输入和过深嵌套常被用来稀释你的约束；设置硬上限，并记录被截断的请求，观察是否有规律。
3. 过滤伪造的系统标记把看起来像系统消息、工具返回的格式特征列成规则，命中就拒绝或人工复核，而不是只做关键词替换。
4. 输出做结构化校验要求模型返回固定结构，校验字段名、类型和取值范围，非法就拒收；不要直接把输出拼进下游命令、SQL 或文件路径。
5. 固定用例回归把已知的攻击样本存成一组测试用例，每次改提示词或换模型就跑一遍，确认防线没被削弱。

关键词黑名单只能当第一层，别当成唯一防线。系统提示里要写清优先级，以及「系统指令和用户指令冲突时怎么办」，这部分写得含糊，后面的校验很难兜底。

工具与权限收口：把损失限制在可控范围

权限收口的目标不是让注入不发生，而是让它发生了也拿不到大东西。每个工具单独给最小权限：只读就别给写，只查自己租户的数据就别给全库，删除、转账、发信这类动作一律走人工确认。这一步的收益比堆关键词过滤高得多。

• 工具调用参数做白名单校验，尤其是 URL、文件路径、SQL 片段这类能直接触达外部系统的字段
• 给 Agent 设步数上限、单次任务成本上限和超时，注入成功也拿不到无限次尝试的机会
• 所有工具调用留完整日志：谁的会话、什么参数、返回了什么，复盘时靠它
• 上线前照 /guides 里的上线前安全自查清单再过一遍，别只靠代码评审

出问题时的排查顺序

1. 先冻结临时下线相关工具或收紧权限，别急着改提示词，先把损失面固定住。确认没有正在跑的异常任务。
2. 再定位按调用链路看是哪一段输入进来的、被哪一层读到了、触发了哪个工具。日志字段是否够用，决定你能不能复盘。
3. 查影响面看这次越权读到了什么、有没有写操作、影响哪些租户；需要对外沟通的，按你们内部流程走。
4. 后修补针对那一类入口加规则，并把这次的输入存成回归用例。只改提示词不改权限，同类问题会换个入口再来。

注入是输入问题，但真正决定损失大小的，是那一步工具调用有多大权限。