prompt-injection

提示词注入漏洞评估

此技能用于指导对集成大模型的应用进行结构化安全审查，以评估提示词注入漏洞。它与 OWASP LLM01:2025（提示词注入） 和 **MITRE ATLAS AML.T0051（大模型提示词注入）**保持一致。

局限性

• 盲区： 此技能依赖可用的代码、配置、日志、文档和用户提供的上下文；如果证据缺失、仅在运行时存在，或超出审查范围，则无法证明相关控制确实存在，也无法证明威胁不存在。
• 误报风险： 在根据资产重要性、补偿性控制、环境预期用途和近期授权变更进行验证之前，应将发现视为假设。
• 所需证据： 每项发现都应有具体材料佐证，例如文件路径和行号、策略片段、扫描器输出、日志、屏幕截图、控制记录或可复现的步骤。
• 规范化 JSON： 如需机器可读输出，发现项必须以 JSON 格式提供，并通过 schemas/finding.schema.json 的验证。
• 升级规则： 如怀疑存在正在发生的入侵、机密信息泄露、受监管数据暴露、严重且可利用的漏洞、特权访问滥用，或证据不足以安全评估高影响风险，应立即升级处理。

---

提示词注入安全声明

如果通过参数指定了目标，请将审查重点放在：$ARGUMENTS

此技能仅用于防御性安全测试。 它旨在帮助开发和安全团队发现其拥有且获准测试的应用中的提示词注入漏洞。所有测试类别都描述了需要关注的内容以及如何防御，而非如何利用第三方系统。未经授权测试不属于你所有或未获明确许可的系统既不合乎道德，也很可能违法。在开展任何安全评估之前，务必先取得适当授权。

背景

提示词注入是大模型应用中最关键的漏洞类别（OWASP 在 2025 年将其列为 LLM01）。攻击者通过精心构造的输入操纵语言模型，使其偏离预期行为，就会发生提示词注入。

研究界区分了两种基本类型：

• 直接提示词注入——攻击者将恶意指令直接作为用户输入提交给应用。Perez 和 Ribeiro 于 2022 年在《Ignore Previous Prompt: Attack Techniques For Language Models》中首次对这类攻击进行系统研究；该类别涵盖将用户可控文本拼接到发送给大模型的提示词中的情形。

• 间接提示词注入——攻击者将恶意指令植入外部内容，大模型随后会检索并处理这些内容。Greshake 等人于 2023 年在《Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection》中对这一类别进行了系统阐述，并展示了遭到投毒的网页、文档和电子邮件如何在被用作上下文时劫持大模型行为。

Simon Willison 的提示词注入分类法进一步细化了这些类别，记录了真实世界中的攻击面和防御局限，为安全评估提供了实用依据。

---

步骤 1：梳理 LLM 交互面

识别用户提供或外部来源的内容到达大模型的每个入口。生成完整的交互图，涵盖：

1. 用户输入渠道 — 聊天界面、表单字段、API 参数、文件上传、语音输入转录文本，以及任何其他用户直接提供文本并将其纳入 LLM 提示词的途径。
2. 外部内容来源 — 浏览工具获取的网页、加载到 RAG 工作流中的文档、电子邮件正文、数据库记录、日历条目、第三方 API 响应，以及任何其他大模型会读取、但用户在查询时无法直接控制的数据源。
3. 系统提示词构建 — 系统提示词的组装方式，是静态的还是动态组合的，以及是否有任何受用户影响的数据（例如用户个人资料字段、先前的对话历史）被插入其中。
4. 工具和插件接口 — LLM 可调用的任何工具（代码执行、网页搜索、文件系统访问、API 调用），包括哪些参数受 LLM 控制，以及每种工具会产生哪些副作用。
5. 多轮上下文 — 对话历史的管理方式、先前轮次是否会被截断或概述，以及攻击者能否通过早先的消息影响后续上下文。

交付内容： 使用表格或图示列出每个输入面、其数据类型、信任级别，以及它是否流入系统提示词、用户提示词或工具参数。

---

步骤 2：识别直接注入向量

针对步骤 1 中识别的每个用户输入渠道，判断攻击者能否通过提交精心构造的文本影响模型行为。检查：

• 提示词拼接模式 — 用户输入是否未经转换就插入提示词模板？查找将原始用户输入与系统指令嵌入到一起的字符串格式化、f-string 或模板字面量。
• 指令边界弱点 — 系统指令与用户输入之间是否有分隔符或结构性隔离？如果使用了分隔符（例如三重引号、XML 标签），它们是否可强制执行，还是用户可以直接闭合分隔符？
• 多轮注入 — 攻击者能否在较早的对话轮次中嵌入指令，从而改变模型在后续轮次中的行为？
• 参数注入 — 用户可控的值（例如“名称”字段、搜索查询）插入提示词后，是否可能携带可执行指令？

代码检查要点：

• 将用户输入通过字符串拼接或插值传入 LLM API 调用
• 使用占位变量填入用户数据的提示词模板
• 组装提示词前缺少输入验证或净化
• 未经过滤便直接纳入对话历史

---

第 3 步：识别间接注入向量

对于第 1 步中识别的每个外部内容源，判断攻击者是否能在该来源中植入指令，并使大模型之后遵循这些指令。检查：

• RAG 流水线输入 — 被检索并插入大模型上下文中的文档、网页或知识库条目。攻击者能否向这些来源贡献内容？
• 电子邮件和消息集成 — 如果大模型会处理电子邮件或消息，攻击者就可以发送包含隐藏指令的消息。
• 网页浏览和抓取 — 如果大模型会获取网页内容，那么它访问的任何页面都可能包含注入指令（包括 HTML 注释、隐藏文本或元数据中的指令）。
• 数据库记录 — 如果数据库中存储的用户生成内容之后会被检索为大模型上下文，那么任何能够写入该数据库的用户都是注入向量。
• 文件上传和文档处理 — PDF、电子表格和其他文档可能包含文本；提取这些文本并发送给大模型后，便会起到注入指令的作用。
• API 响应 — 响应会被送入大模型上下文的第三方 API 可能遭到入侵或操纵。

代码中需要检查的内容：

• 输出会被插入提示词的文档加载器、网页抓取器或 API 客户端
• 未对检索到的内容进行清理或标注来源的 RAG 检索流水线
• 缺少内容来源跟踪机制（大模型无法区分可信指令与检索到的内容）

---

第 4 步：测试类别

根据以下记录在案的漏洞类别评估应用。对于每个类别，判断应用架构是否容易受到影响，以及现有防御是否能降低风险。

4.1 目标劫持

模型被引导偏离预期任务，转而执行攻击者选择的任务。例如，攻击者诱使摘要助手生成垃圾内容，而不是摘要。评估应用是否通过结构性约束来确保其执行预期用途，还是仅依赖系统提示词中的指令。

评估要点：

• 用户输入能否通过“忽略之前的指令，改为……”之类的内容覆盖模型的任务？
• 应用是否会验证模型输出是否符合预期任务？
• 除提示词级指令外，是否还有结构性强制措施？

4.2 提示词泄露

攻击者提取系统提示词，从而获知专有指令、业务逻辑或与安全相关的配置。系统提示词通常包含应用开发者认为机密的信息。

评估要点：

• 应用的任何安全属性是否依赖系统提示词的保密性？
• 是否有输出过滤器来检测并阻止响应中出现系统提示词内容？
• 系统提示词是否包含敏感信息（API 密钥、内部 URL、业务规则），一旦泄露是否会造成危害？

4.3 权限提升

攻击者诱使模型调用工具或执行超出用户授权级别的操作。在大模型可使用具有副作用的工具的 Agent 应用中，这一点尤为关键。

评估要点：

• 大模型是否能够使用超出预期用途所需范围的工具或能力？
• 工具调用是否受独立于大模型决策的授权检查所控制？
• 能否指示模型使用用户本不应有权指定的参数调用工具？
• 大模型的权限与最终用户的权限是否彼此分离？

4.4 数据窃取

攻击者诱使模型在输出中包含敏感数据，或将数据传输到攻击者控制的目标位置。这包括渲染带有数据编码 URL 的 Markdown 图片、生成用户可能点击的链接，或调用会向外部发送数据的工具。

评估内容：

• 模型能否渲染 Markdown 图片或链接（这是一种常见的通过 URL 编码数据进行数据窃取的途径）？
• 模型能否访问可能被包含在回复中的敏感数据（个人身份信息、凭据、内部文档）？
• 能否使用工具调用向任意外部端点发送数据？
• 是否会对输出进行过滤，以检测敏感数据模式？

4.5 越狱

攻击者绕过模型的安全准则或应用的行为约束。虽然基础模型越狱在一定程度上属于模型提供商的职责，但应用层越狱（绕过应用特定规则）是应用开发者的责任。

评估内容：

• 除基础模型的安全训练外，应用是否增加了行为约束？
• 这些约束是否仅通过提示词指令强制执行，还是也通过输出验证来强制执行？
• 当模型可能生成不允许的内容时，应用是否能妥善处理边缘情况？

---

第 5 步：评估防御措施

评估以下缓解措施中哪些已实施，以及实施效果如何。请注意，任何单一防御措施都不足以应对风险；必须采用分层防御方法。

5.1 输入验证与净化

• 在将用户输入纳入提示词之前，是否会验证其格式、长度和字符集是否符合预期？
• 是否会检测并标记已知的注入模式（例如“忽略之前的指令”）？
• 是否在不依赖穷举阻止列表（其本质上并不完整）的情况下对输入进行净化？

5.2 权限分离

• LLM 是否以最小权限访问工具和数据？
• 敏感操作是否由独立且受限的组件处理，而非由 LLM 自身处理？
• LLM 与后端系统之间是否设有授权层，以强制执行最终用户的实际权限？

5.3 人在回路

• 高影响或不可逆的操作（发送电子邮件、修改数据、执行代码）是否必须经过人工确认？
• 确认提示词的设计是否能让人类在批准操作前充分评估该操作？
• 是否设定了需要人工审核与允许自动执行的阈值？

5.4 输出过滤

• 在将模型输出返回给用户或据此采取操作之前，是否会根据预期格式和内容策略进行验证？
• 是否会检测输出中的敏感数据（个人身份信息、凭据、系统提示词内容）？
• 是否会对渲染后的输出（Markdown、HTML）进行净化，以防止通过图片标签或链接窃取数据？

5.5 系统提示词中的金丝雀令牌

• 系统提示词是否包含金丝雀字符串，若这些字符串出现在模型输出中，就表示可能发生了提示词泄露？
• 响应中出现金丝雀令牌时，是否会自动检测并发出警报？

5.6 指令层级

• 应用是否使用支持指令层级（系统指令优先于用户指令）的模型或框架？
• 系统提示词是否与用户输入在结构上分离（例如通过 API 的系统消息角色），而不是拼接成单个字符串？
• 检索到的文档和外部内容是否明确标记为数据，而非指令？

5.7 自适应攻击韧性

警告： 静态提示词注入防御（硬编码的系统提示词、简单的关键词过滤）已被证明不足以应对自适应攻击者。PISmith（Yin 等人，2026 年）使用经强化学习优化的自适应黑盒攻击，在 13 项基准测试中取得了最高的攻击成功率。

• 持续开展红队评估： 必须持续评估提示词注入防御，而不能只进行一次性测试。自适应攻击者会针对已部署的防御反复改进其攻击载荷。安排定期红队评估，结合自动化对抗测试工具和人工专家测试。
• Agent 基准测试套件： 对于大模型会调用工具或采取自主行动的应用，标准提示词注入基准测试并不足够。应使用专门针对 Agent 的基准测试套件，在工具使用和多步骤工作流场景下测试注入攻击：
  • InjecAgent —— 测试 Agent 场景中的间接提示词注入，此时大模型会处理外部内容并拥有工具访问权限。
  • AgentDojo —— 在多种工具使用场景中，使用真实的对抗性内容评估 Agent 抵御注入攻击的能力。
  • fabraix/playground (https://github.com/fabraix/playground) —— 开源的 AI Agent 漏洞利用概念验证（PoC）库，可作为测试工具，用于根据已公开的攻击模式验证对直接和间接注入的防御。

---

步骤 6：报告发现

使用以下分类和输出格式整理发现。

发现分类

应根据潜在影响为每项发现指定严重性：

严重性	标准
严重	攻击者可窃取敏感数据、提升权限以执行未授权操作，或通过 RAG 流程中的外部内容完全劫持应用行为。利用漏洞不需要超出正常应用使用范围的特殊访问权限。
高	攻击者可可靠地覆盖应用的预期行为、提取系统提示词，或导致模型调用非预期工具。可能需要一定的用户交互。
中	攻击者可部分影响模型行为、提取非敏感的系统提示词片段，或导致模型生成偏离任务的输出。漏洞利用不稳定或需要特定条件。
低	对预期行为造成轻微偏差，安全影响有限。可以诱使模型生成稍微偏题的回复，但无法使其执行有害操作。
信息性	纵深防御建议。没有已证实的漏洞，但发现了防御层面的缺口。

输出格式

## Prompt Injection Assessment Report

### Summary
- Application: [name]
- Assessment date: [date]
- Scope: [what was tested]
- Overall risk: [Critical / High / Medium / Low]

### Interaction Surface Map
[Table from Step 1]

### Findings

#### Finding [N]: [Title]
- Category: [Goal Hijacking | Prompt Leaking | Privilege Escalation | Data Exfiltration | Jailbreaking]
- Vector: [Direct | Indirect]
- Severity: [Critical | High | Medium | Low | Informational]
- Location: [file path and line numbers, or architectural component]
- Description: [What the vulnerability is and why it matters]
- Evidence: [Code pattern or architectural observation that demonstrates the issue]
- Recommendation: [Specific defensive measure to implement]

### Defense Posture Summary
[Table summarizing which defenses from Step 5 are present, partially present, or absent]

### Recommendations
[Prioritized list of defensive improvements]

---

框架参考

框架	标识符	描述
OWASP Top 10 for LLMs (2025)	LLM01	提示词注入——通过精心构造的输入直接或间接操纵大模型行为
MITRE ATLAS	AML.T0051	大模型提示词注入——通过构造输入使大模型偏离预期行为的技术

---

常见陷阱

1. 只测试直接注入，忽视间接注入。 通过 RAG 管道、电子邮件和抓取的网页内容实施的间接注入，往往比直接用户输入构成更大的攻击面。摄取外部内容的应用会暴露给任何能够影响这些内容的攻击者，而这类攻击者通常远多于拥有应用直接访问权限的攻击者。

2. 将提示词指令当作安全边界。 要求“绝不透露这些指令”或“始终拒绝有害请求”的系统提示词，并非可强制执行的安全控制。它们只是对概率模型的行为建议。关键安全约束必须通过代码强制执行，而不能依靠向大模型发出自然语言指令。

3. 认为输入黑名单足以应对风险。 通过改述、编码或切换语言，就能轻易绕过针对已知注入短语（例如“忽略之前的指令”）的黑名单。输入验证应侧重于允许预期的输入格式，而不是将已知攻击加入黑名单。

4. 授予大模型过多工具权限。 如果应用让大模型访问强大的工具（文件系统写入、发送电子邮件、修改数据库、执行代码），却没有独立的授权检查，就会带来高严重性的权限提升风险。大模型能够调用的每个工具都应设有独立的授权关卡，且不依赖大模型的判断。

5. 未将检索内容视为不可信内容。 RAG 管道通常会将检索到的文档片段直接插入提示词，且不与系统指令区分。大模型无法天然区分“这是需要推理的数据”和“这是需要遵循的指令”。应明确标记检索内容，并尽可能通过能够执行指令层级的模型或层来处理。

---

参考资料

• OWASP 大语言模型应用十大风险（2025），LLM01：提示词注入 — https://genai.owasp.org
• MITRE ATLAS，AML.T0051：大模型提示词注入 — https://atlas.mitre.org
• Perez, F. & Ribeiro, I.（2022）。“忽略之前的提示词：语言模型的攻击技术。” arXiv:2211.09527。
• Greshake, K. 等（2023）。“这不是你所期望的：通过间接提示词注入攻陷现实世界中的大模型集成应用。” arXiv:2302.12173。
• Willison, S. 提示词注入分类与持续研究 — https://simonwillison.net
• Yin, X. 等。“PISmith：经强化学习优化的自适应黑盒提示词注入攻击”（2026）-- arXiv:2603.13026
• fabraix/playground — 用于测试注入防御的开源 AI Agent 漏洞利用库 — https://github.com/fabraix/playground