制度：授权矩阵
明确哪些数据源可接入、哪些工具可被调用、谁有权批准新增。把可用输入源清单与工具授权矩阵做成可查的表，新增一项就走一次评审，避免临时开权限后没人记得收回，也避免权限悄悄扩大，矩阵要能被业务查询。
流程：四道关卡
需求阶段做威胁建模，开发阶段做输入输出约束，上线前跑红队用例集，上线后按季度复测。每道关卡有明确产物与责任人，缺一道就等于没有证据，评审时也很难说服安全与法务签字，关卡产物要归档。
技术：分层不靠提示词
用角色分层把系统指令、用户输入与工具返回值放在不同通道，输入做清洗与长度限制，输出做结构化校验。系统提示只能作为其中一层，不能当作唯一防线，它本质上是一段可以被绕过的文本，提示词的版本也要管起来。
技术：工具网关
所有工具调用经过网关，校验参数结构、检查权限、记录调用，并对不可逆动作挂人工确认。网关还能在异常频率时自动熔断，比在每个应用里各写一套更可靠，也更容易统一升级策略，网关日志要能按会话检索。
边界：没有零风险
防护目标是限制可利用影响，而不是消灭所有注入。对高风险动作保留人工门，对低风险场景接受残余风险并留记录，这比承诺「完全防住」更诚实，也更经得起真实攻击的检验，接受残余风险要有人签字。
适用与不适用
适合谁
- 正在把 Agent 接入生产流程的团队，动作有风险
- 已有 RAG 应用需要加固的企业，输入来源复杂
- 要建立 AI 安全评审流程的安全部门，需要可查证据
不适合谁
- 尚未上线的概念验证，且不接真实数据
- 希望用一条系统提示解决全部问题的团队
典型场景
某制造企业的采购助手需要读报价单、比价并生成汇总。团队把报价单解析限定为字段抽取，工具只开放查询与草稿写入，提交动作由采购员确认；上线前用三十条注入用例测了两轮，发现两处越权读取，修完才放行，复测记录一并归档。
可执行步骤
- 列出可用输入源与工具清单，逐项指定授权人、审批方式与回收条件，并挂到统一目录下。
- 在需求评审阶段做威胁建模，输出攻击面清单与对应控制措施，并注明例外情形。
- 按系统、用户、工具三类角色分层改造提示词结构，隔离指令与数据，并给模板版本号。
- 建设工具网关，统一做鉴权、参数校验、调用审计与异常熔断，并约定复核频率。
- 用自建注入用例集做红队测试，按可利用影响排修复顺序，并同步到知识库。
- 把季度复测、用例更新与责任人写进安全运营计划，在系统里留操作记录。
常见坑
- 只在系统提示里写「忽略可疑指令」，换个说法或换种语言就被绕过去，团队还以为已设防，影响面会持续扩大。
- 工具权限按人配而不按任务配，Agent 直接继承了员工的全量权限，越权面比想象中大，一旦被诱导后果很重。
- 红队只跑一次，模型换版或插件更新后防护失效，却没人知道也没人安排复测，责任往往落不到人。
- 异常调用没有告警与限流，攻击者可以慢慢试错，直到找到那个没防住的入口，同类问题会重复发生。
自检与验收清单
- 输入源与工具是否有可查的授权矩阵，含回收条件
- 需求评审是否包含威胁建模与攻击面清单，产物可归档
- 系统指令与外部数据是否分通道处理，分通道实现
- 工具调用是否统一经过网关并留审计，可按会话查
- 是否有自建注入用例集与季度复测计划，含复测频率
常见问题
能不能用一个更强的模型来防？
模型能力提升有帮助，但注入利用的是「模型会执行文本里的指令」这一架构特性，换模型不消除它。还是要靠权限收窄、工具网关与人工确认把影响限住，防护要跟着版本走。
小团队没有安全团队怎么办？
先做三件成本最低的事：限制工具权限、对不可逆操作加确认、把输入当不可信数据处理。用例集可以从公开的攻击样例改起，重点覆盖自己业务的真实入口，先用小范围试点验证。
加了人工确认会不会太慢？
只对不可逆或对外发送的动作设确认门，查询与草稿类操作不必。把确认做成批量审批或抽样复核，可以把等待时间压到可接受范围，不必每次逐条等人，确认门可以批量处理。