提示注入不是“有人写了句 ignore previous instructions”这么窄的问题。网页、邮件、检索文档、代码注释、图片文字或工具返回值都可能携带指令；模型为了完成任务必须阅读它们，却无法像编译器那样可靠地区分“要处理的数据”和“拥有更高权限的命令”。当同一个模型还能查私库、发消息或执行代码时，一段内容就可能变成越权路径。

本文面向设计 RAG、Agent、MCP 或任何带工具 AI 流程的工程与安全人员。你需要理解鉴权、Schema 和日志。目标不是承诺彻底消灭注入，而是让任意模型输出都无法独自获得权限：不可信内容被标记和隔离，动作由确定性策略代理裁决，敏感数据最小化，异常有审计证据，风险升高时系统降低能力而不是放宽边界。

视觉资产记录：封面（1600 × 900）与文中纵深防御图（1400 × 800）均为 WEB/SUN 于 2026-07-16 创作的程序化 SVG；来源/许可为本项目原创自有资产，未使用第三方图片。

来源标记、隔离阅读、策略代理、参数校验、审批和审计组成六层防线，并分流到安全回答、只读与人工复核

图 1（1400 × 800）：未知或冲突输入只能降低权限。模型可以提出动作，不能给自己授权；所有分支保留同一用户意图与审计关联。原创程序化 SVG，WEB/SUN，2026-07-16。

不可信输入在多层边界前被隔离并转交人工复核

图 2（1600 × 900）：提示注入防线的编辑式视觉隐喻，不替代威胁建模。OpenAI Image Gen × WEB/SUN，2026-07-16；项目内原创生成资产。

先接受一个不舒服的事实

OWASP LLM01:2025把直接和间接提示注入都列为风险：攻击内容可能来自用户，也可能藏在外部网页、文件或多模态输入中，后果包括敏感信息披露、未授权功能调用与关键决策操纵。RAG 与微调能改善相关性或行为，却不能自动消除这种架构问题。

所以 system/developer prompt 是行为指导，不是安全边界；“永远不要泄密”也不是访问控制。关键词黑名单可以拦住明显样本，却会被编码、拼写变化、多语言、图片和分步载荷绕过。另一个模型做 guardrail 也仍是概率组件，只能增加一层检测，不能替代权限系统。

威胁建模从资产和动作开始：系统能读什么私密数据，能向哪些外部域发送内容，能创建/修改/删除什么，哪些动作不可逆，攻击者能控制哪些输入与知识源。然后画出每次跨界：浏览器到检索器、检索结果到模型、模型到工具代理、工具到 SaaS、结果到渲染器。没有跨界清单，就无法知道一次注入能走多远。

给所有内容标明来源和用途

进入上下文的每个片段携带 provenance：来源类型、URL/文档 ID、租户、访问控制快照、获取时间、内容 hash、可信等级与允许用途。用户问题、内部政策、网页正文和工具结果不能拼成一段失去边界的长文本。不可信内容放在 user/data 通道，不插入高优先级 developer 指令。

“把数据包在 XML 标签里”有助于模型理解，但标签本身不是隔离。更强的做法是分离 reader 与 actor：reader 只能读取不可信材料，不能访问秘密或外部写工具；它只返回固定 Schema 的事实候选、来源 ID 与风险标记。actor 只接收验证后的结构字段和原始用户意图，不直接看到任意网页正文。

这种隔离仍不是数学证明。摘要可能携带被操纵的错误事实，结构字段也可能被滥用。因此 actor 后面还必须有确定性工具代理，业务规则不能只写在提示词里。需要原文引用时，展示引用给用户或只把必要片段交给无权限验证器，不要为了“上下文完整”把整个私库与网页同时交给高权限模型。

知识入库同样要过供应链门禁。采集器保存来源与许可，解析器检查隐藏层、不可见字符、脚本、重定向和异常编码，新文档先进入 quarantine；只有通过租户 ACL、恶意内容扫描与人工/规则抽查后才进入可检索索引。删除或降权来源时同步清理向量、摘要和缓存，避免原文件消失后污染片段仍被召回。连接器或解析库升级也要重跑一组已知恶意文档，因为边界变化可能让以前不可见的载荷突然进入模型。

工具代理才是授权边界

模型输出只是 proposal。工具代理使用已认证用户、租户、会话原始意图、政策版本和服务端资源重新鉴权；不能相信模型传来的 userId、role=admin 或 approved=true。工具按 read/write/destructive 分开，使用最小 scope 与短期凭据，默认没有跨租户查询和任意 URL 访问。

每个动作经过固定顺序：工具 allowlist、参数 Schema、长度/枚举/格式、对象归属、业务前置条件、速率与额度、网络 egress、幂等键、风险等级、审批状态。URL 抓取还要做协议与域名 allowlist、DNS/IP 检查、重定向上限和响应大小限制，避免提示注入借工具变成 SSRF 或数据外传。

type Proposal = {
  tool: 'searchDocs' | 'sendMessage' | 'deleteRecord';
  args: unknown;
  intentId: string;
};

type Context = {
  authenticatedUser: string;
  allowedTools: ReadonlySet<Proposal['tool']>;
  approvedIntentIds: ReadonlySet<string>;
};

function authorize(proposal: Proposal, context: Context) {
  if (!context.allowedTools.has(proposal.tool)) return { allow: false, reason: 'tool_not_allowed' };
  if (proposal.tool !== 'searchDocs' && !context.approvedIntentIds.has(proposal.intentId)) {
    return { allow: false, reason: 'explicit_approval_required' };
  }
  return { allow: true, reason: 'policy_passed', actor: context.authenticatedUser };
}

示例只展示第一层纯策略，生产系统还要用每个工具的严格 Schema 与资源级鉴权。它故意没有“内容看起来安全就执行”的分支，也没有让模型生成用户身份。这段策略代码已映射到 examples/ai-web/src/ai-authorization.ts，通过 TypeScript 类型检查与 Vitest；本文没有连接真实工具或发送数据，所以生产鉴权、审批和外发数据的端到端结论仍是 source-reviewed。

OpenAI 的 MCP 风险说明给出典型链路：模型在外部内容中遇到恶意指令，随后被诱导从另一个连接读取敏感信息并发送出去；信任 MCP 开发者并不等于信任该 MCP 能访问的全部内容。因而每次工具调用都要检查参数和数据去向，读操作也可能泄露隐私，不能默认免审批。

审批要绑定具体动作

“允许这个 Agent”范围太大。审批界面应展示工具、目标对象、关键参数、将发送的数据类别、外部接收方、可逆性和有效期；用户批准的是规范化后的本次 proposal。模型在审批后改参数、换收件人或扩大数据范围，就生成新的 intent ID 并再次审批。

高风险动作采用 prepare/commit：第一阶段验证并生成不可变预览，第二阶段凭短期确认 token 执行。支付、删除、公开发布、权限变更和外发敏感数据不应由一次自然语言“好的”触发。批量动作显示数量和抽样，超过阈值强制二次确认；无法提供清晰预览时直接转人工。

OpenAI 的 Safety best practices建议对抗测试，并在高风险领域与代码生成等场景保留 human-in-the-loop。人工不是橡皮图章：审核者要能看到原始请求、可信来源、提议动作与差异，而不是只看模型总结。

数据安全从最少进入模型开始

先按 public、internal、confidential、restricted 分类，再为每类定义可用模型/区域、可进哪些工具、是否允许持久化、日志如何脱敏、谁能审批。只检索完成当前任务所需字段；能在工具端完成聚合，就不要把原始客户记录交给模型；秘密以服务端引用存在，模型永远不看到 API key、会话 cookie 或密码重置码。

OpenAI 当前 Data controls说明：API 数据默认不用于训练或改进模型，除非客户明确选择共享；这不等于“绝不存储”。默认 abuse monitoring 日志可能包含客户内容并最长保留 30 天（法律或安全需要可能更久），部分 API 功能还保存 application state。符合条件的客户可申请 Modified Abuse Monitoring 或 Zero Data Retention，但有资格、功能和配置限制。

因此数据设计必须查具体端点表。以 Responses API 为例，当前文档列出默认 application state 保留规则，background mode 与音频输出又有不同需求；store、组织数据控制与 abuse logs 是不同层次，不能只设置一个参数就宣称满足所有保留要求。上线前把端点、功能、区域、保留期与删除流程写进 data inventory，并由合规/安全人员确认。

发送前删除无关 PII，稳定用户标识使用隐私保护映射，文件设最短生命周期。日志也遵循同样原则：不因“审计”就永久保存完整 prompt、原始附件、访问 token 或客户数据。对高敏内容保存 hash、分类、长度和受控证据引用；真正原文放在权限更严格、保留更短的存储中。

审计记录决策，不记录秘密

一条可用审计事件包含：trace/request/intent ID、时间、用户与租户的内部不可逆标识、输入来源及 hash、数据分类、政策/提示/模型版本、检索文档 ID、模型提议的工具与参数摘要、确定性校验结果、审批人/时间、真正执行的工具结果状态、外部目标、降级原因和关联告警。

审计日志追加写、访问受控、字段有保留期，并与业务数据库分开。对参数做字段级脱敏；日志里保存 recipient_domain=example.org 可能够调查，不必保存整封私信。不要把模型隐藏推理当合规证据：可审计的是输入来源、可见输出、政策决策和真实副作用。

监控关注行为变化：工具拒绝率、跨域请求、单用户批量读取、审批后参数变化、敏感字段命中、注入检测、异常输出链接与降级频率。告警必须能关联到当时政策和来源，否则只剩一条无法复现的“模型做错了”。

输出也可能成为攻击载荷

模型生成的 Markdown、HTML、代码、SQL 和 URL 都是不可信输出。网页渲染前使用允许列表 sanitizer，禁用原始脚本、事件属性和隐形外链；链接经过协议与域名政策，不自动加载可能携带数据的图片 URL。代码只在隔离 sandbox 运行，SQL 使用只读账户与参数化接口，不能把生成字符串直接交给 shell。

结构化输出能缩小通道，但业务语义仍需验证。amount: 1000000 可以完全符合 number Schema，仍可能超额度；https://trusted.example@evil.example 可能是合法 URL 字符串，却不是允许目标。格式验证之后必须有资源级权限与业务规则。

把降级设计成产品状态

检测到未知来源、策略冲突、审批缺失、数据分类过高或模型/工具异常时，系统按固定阶梯降低能力：

  1. 完整模式：仅在所有边界通过时允许经批准的读写工具。
  2. 只读模式：关闭外部写入，只返回带来源的查询结果。
  3. 隔离回答：关闭所有工具，仅基于已验证公开信息回答，并明确局限。
  4. 人工复核：保留 proposal 和证据，不执行副作用。
  5. 安全停止：无法隔离秘密或确认目标时拒绝，并给出恢复步骤。

降级继承相同身份、租户和审计，不能使用一条“简化备用链”绕开检查。对用户说明哪个能力不可用、什么没有执行、是否需要重新确认；不要显示攻击载荷或内部策略全文。恢复前撤销可疑会话 token，清理污染记忆/索引，复核已发生副作用，而不是简单重试同一 prompt。

失败模式 为什么无效 应有控制
只写“忽略外部指令” 模型仍同时处理指令与数据 隔离 reader、策略代理、最小权限
关键词黑名单 编码、多语言、图片和分步攻击可绕过 多层检测与确定性动作门禁
信任工具供应商 工具可访问的内容仍可能恶意 来源标记、参数/去向审查
所有读操作免审批 读取可成为跨系统泄露的第一步 字段级 scope、敏感读审批
保存完整日志 日志本身变成高价值泄露源 脱敏摘要、受控证据引用、保留期
失败后换弱模型 能力下降同时可能让安全约束下降 固定政策，降级功能而非权限

用对抗集持续验证

OWASP 的 Prompt Injection Prevention Cheat Sheet覆盖直接、间接、编码混淆、多轮、RAG 污染、多模态与工具攻击。把这些类别转成内部 abuse cases，并加入自己的真实连接器、语言和数据字段；每个样本不只判断最终文本，还断言检索范围、提议工具、策略拒绝、审批、网络 egress 和审计事件。

测试包含正常任务，避免安全层把产品完全锁死。按来源、权限、语言、模型、工具与风险切片观察误放和误拒；任何模型、提示、检索器、工具 Schema、MCP server、权限或 sanitizer 变更都跑回归。新攻击进入语料时保留最小可复现版本，敏感 payload 用受控访问。

NIST AI 600-1把生成式 AI 风险管理放在完整生命周期与组织治理中。工程上对应的是：上线前定义责任和资产，部署时测量风险与有效性，运行中监控、响应、恢复并更新政策。提示词只是其中一项控制，无法替代供应链、访问管理、事件响应和人员流程。

事故演练至少覆盖：恶意网页诱导外发、被污染知识库、工具返回注入、图片隐写指令、审批后参数替换、跨租户 ID、日志泄密和模型不可用。演练要证明 kill switch 能停写工具、凭据能吊销、已执行动作能定位、用户能被通知、证据在保留期内可取得。

结论

Prompt Injection 很难靠一句更强的提示根治，但它的影响半径可以被架构约束。不可信内容带来源进入隔离 reader，结构字段经过业务验证，模型只能提出 proposal，工具代理以真实身份和最小权限裁决，高风险动作绑定明确审批，数据进入与日志保存都最小化，异常沿固定阶梯降级。

系统的安全问题不该是“模型会不会听坏指令”，而应是“即使模型输出完全被攻击者控制，它最多能看到什么、能提议什么、哪一层会阻止副作用、我们如何证明发生过什么”。能清楚回答这四点，才算建立了可运营的防线。

Sources