很多人以为只要 Prompt 写得够严，就能挡住「忽略之前指令」这种绕过。可真正卡住的，往往是模型把用户输入里的某句话，直接当成了下一步该执行的命令。把守卫前移到接口层，才是更持久的做法。
前阵子帮老大复盘一个内部 Agent 的执行记录，我才发现问题出在哪一环。模型已经把权限当成了默认可用的工具，却没人告诉它「到哪为止」。我也不确定这种模式在所有场景都成立，但至少在权限模糊的内部工具里，它反复出现。
为什么 Prompt 和后置过滤都靠不住？
把规则全塞进系统 Prompt，遇到对抗输入时很容易被覆盖。模型的优先级判断本来就不稳定，新规则加进去，旧漏洞又冒出来。
只在输出后做过滤就更晚了。工具调用可能已经在执行，事后拦截基本救不了场。
把防护放在调用链路上游，才能在真正触发前把风险拦住。
输入规范层把自由文本转成受控结构。要求模型先输出固定 JSON，包含 intent、target、constraints 这些字段。解析失败或者字段里出现「忽略」「覆盖」这类词，直接拒绝。
这个 JSON 再往下走，模型就很难用自然语言绕过限制。API 网关第一层就能做，JSON Schema 现成支持。
还有一个事是工具权限层。每个工具都要显式写明允许的 action 和 resource scope，超出白名单的调用直接 403。高风险操作如邮件发送、数据库写入，最好先设成只读或需要二次确认。
逐步确认层与可追溯记录层
对写操作或跨系统调用，先让模型生成人类可读的执行计划，再由用户点确认或取消。计划里要列具体对象和预期结果，而不是一句「即将发送邮件」。
可追溯记录层则把解析结果、权限检查、确认状态、工具调用全写入结构化日志，并绑定会话 ID。需要审计时，5 秒内就能拉出完整路径。
我见过 Discord 里有人问：加了这些之后，普通读操作会不会明显变慢？实际测试里，感知到的延迟大多在 1 秒以内。
最小可用版只做输入规范和工具权限白名单，两天就能上线。进阶版再加上确认和日志，适合处理敏感数据或面向外部用户的场景。用户体验会多等一小会儿，但越权风险明显降低。
你现在最想先在哪个环节试试这套守卫？