L4.06.3auditable permission use设计研究
权限使用记录需可审计
别名: 权限审计 · agent audit trail · 谁用了哪张票
概念解释
票发出去之后，还要能回答：哪一次任务、哪一个对象、哪一个动词、谁批准的、结果是什么。权限使用可审计（auditable permission use）不是运维调试日志，是事后能按对象把权限因果链走一遍的记录。缺一环，越界被拦住或没拦住都无法复盘。
「系统日志里大概有」不等于可审计。可审计的标准是一个不写代码的人能按对象查出那一笔。
机制
权限的生命周期跨过授权、调用、结果三拍。产品常只在授权时弹一次窗，调用时不留对象级记录，结果散落在各外部系统。复盘时人只能看到「某日连接过帐户」，看不到「十五点零三分用读票去写了另一文件夹」。没有这条链，最小权限和拦截都无法被验证，责任也找不到落点。
审计要为人读：字段是任务、对象、动词、票、批准者、结果、时间。调试堆栈不是给人读的。保留时长按追责可能发生的时点，不按磁盘便宜与否——那是可追溯的邻接问题，这里先要求字段齐。
怎么研究
做一次授权、一次范围内调用、一次越界尝试（被拦或没被拦）。让不熟悉系统的人只凭审计界面回答：谁批的、碰了什么、有没有越界。因变量：答对率、找到一笔的时间、是否需要工程师。自变量：记录是否对象级、是否含批准者、界面是否按对象可检索。
能答出来才叫可审计。工程师用 grep 能挖出来，不算。
边界
完全不能越世界边界的本地草稿代理，审计需求弱，但仍建议留下授权记录以免范围以后变。拦截本身不产生给人看的账，审计就空了——拦也要记账。责任追溯还要求输入和决策依据，比权限账更宽；这里只覆盖权限这一段。
怎么落地
- 每张票的每次使用写一条对象级记录：任务、对象、动词、批准者、结果（做成 / 被拒 / 失败）。提供按对象与按任务的检索，不把这层只留给基础设施日志。
- 授权与调用必须能关联。只有授权没有调用，或只有调用对不上票，都算缺链。
- 验证：把工程师拿走，给运营一张对象名，问「这张票被用来做过什么」。查不到或要翻服务器，审计就不存在。再故意做一次被拒的越界，看账上有没有「被拒」——没有，拦截即使发生了也无法被证明。