三条硬规则
记录 chapter.rules raw
1. 边界优先于纪律
能让系统强制的事,不交给"记住别做"。
提示词、行为规范、自我承诺都属于纪律层:可被绕过、扛不住上下文压缩、无法审计。它们有效,但只能当第二层。
判据很简单:这条规则失效时,会不会有东西真的读不到、发不出、删不掉? 不会,那它就是纪律。
2. 先想办法读不到,再想怎么不说
"能读到但答应不说"和"读不到"是两件事,成本相差一个数量级,效果也是。
3. 一次通过不等于性质成立
单次拒答、单次成功、单次跑通,只说明那一个用例通过。要断言性质,得多形态用例 + 可留存的断言记录。
这条是被驳倒之后写进来的,见「判断与研判」里的复盘。
混淆代理
记录 chapter.confused-deputy raw
问题长什么样
共享盘时代,权限判定对着提问的人算:每个请求都按发起人算一次 ACL。
agent 接进来之后,判定的主体变成了代理你的那个进程——一个有高权限的 deputy,被一群低权限的人使唤。ACL 没消失,但它现在回答的是"这个 agent 能不能读",而不是"问的人该不该读"。
你的权限被借出去了。这就是 confused deputy。
为什么它比"泄露"更麻烦
泄露是一次事件,可以事后追。混淆代理是结构性的:只要 agent 带着主人的身份跑,它就一直成立,而且从服务方看,所有请求都是同一个身份发的,分不出是谁在用。
它推翻了什么
推翻了"给 agent 写一句'除非本人问否则别说'"就行的直觉。那句话管的是意愿,混淆代理是能力问题。
缓解
见「权限与凭据」。要点只有一句:该分的是身份,不是目录。
提示词能做什么
记录 chapter.prompt-can-do raw
先说结论:能显著降低无意泄露,不能当边界。
它做不到的四件事
- 不改变能力。 规则约束"会不会说",不改变"拿不拿得到"。实测过:规则里没写允许,文件照样可读。
- 可被绕过,且不需要恶意。 换个问法、套一层转述、让它在推理里拼碎片,都可能漏。模型是概率性的。
- 扛不住提示注入。 agent 会读网页、文件、工具返回,这些内容里夹带指令就能盖过原规则。
- 不可审计。 出事只能说"它应该没说",没法证明。
它值得做的地方
写成明确的行为规范,能挡住大部分无意泄露。作为纵深防御的第二层有价值,成本几乎为零。
一个容易漏的点
这类规则要求 agent 能可靠判断"提问的是谁",而频道里这件事并不牢——引用、转述、多人指代不清都会让身份判断出错。身份判定本身也是软的,最后还是得靠频道成员关系这种硬约束兜底。