提示注入防护：把资料与执行权限分开

注入从哪里进入

网页、检索片段、文件和工具返回值都可能包含要求模型改变目标的文本。攻击不一定长得像“忽略此前指令”，也可能伪装成引用、系统消息或必须执行的修复步骤。关键问题是低信任内容被提升成了执行权限。

不能仅靠关键词黑名单解决提示注入。模型可能误解文字，而业务程序仍应保证它无法跨用户读取数据、调用未授权工具或把密钥发送到任意地址。

可运行的目的地约束示例

下面采用精确 origin 白名单；它只适用于目的地固定的服务，不是完整 SSRF 防护。允许任意主机时还必须处理 DNS 解析、私有地址、重绑定和每次重定向。

import assert from "node:assert/strict";
function allowedDestination(raw) {
  try {
    const url=new URL(raw);
    return url.protocol==="https:" &&
      url.origin==="https://api.example.com" &&
      !url.username && !url.password;
  } catch { return false; }
}
assert.equal(allowedDestination("https://api.example.com/v1"),true);
assert.equal(allowedDestination("https://api.example.com.evil.test"),false);
assert.equal(allowedDestination("https://user:[email protected]"),false);

执行层检查清单

工具参数采用明确 schema 和长度上限；资源查询带服务端用户 ID；写操作验证来源并提供幂等处理；外部请求配置时间和响应大小限制。检索语料本身只能提供证据，不负责决定工具权限。

日志保留必要的状态与追踪信息，避免为了调试收集全部私人正文。测试应包含越权 ID、嵌入恶意指令的文档、超大输入、重复请求和工具超时。防护结果需要通过攻击样本验证，而不是仅检查系统提示词是否写了“安全”。

原始资料

• MCP Security Best Practices：工具网关安全边界与令牌处理。本文不宣称存在能够完全消除提示注入的文本过滤器。