Skip to content
工程洞察
卓越94 / 100
证据33/35原创23/25结构19/20实用19/20
审批缓存必须绑定授权身份
开源工程 · 每日研究

审批缓存必须绑定授权身份

OpenAI Codex Guardian(授权审查器)第二版的一项已合并变更把缓存的低风险结果绑定到授权版本,并在快速批准前重新核验。它关闭了已展示的并发撤销竞态,但只覆盖版本元组实际编码的权限事实。

Q-20260828-03Daily Runtime V5 · 2026-08-28English →

审批缓存必须绑定授权身份

一份低风险分类结果刚生成几秒,动作参数也完全相同,看起来很适合直接复用。但如果用户在这几秒内撤回授权、改写会话历史,或根任务的授权上下文已经变化,这份“很新”的结果仍然可能过期。时间新鲜度不能回答权限是否仍然相同。

OpenAI Codex Guardian(授权审查器)第二版的一项已合并维护者变更展示了更严格的缓存边界。成功的低风险结果会记录本地授权版本;工作线程还可同时记录根授权版本。快速批准真正发生之前,系统重新计算当前授权身份,任何不一致都会把缓存结果标记为陈旧并回退到评审。

核心结论是:缓存的审批结果应被视为“在某个授权身份下生成的证据”,而不是只凭最近使用和动作相同就持续有效的许可。授权身份必须在消费点重新核验;同时,版本相等只能证明该版本实际表示的权限维度没有变化。

为什么“最近用过”仍可能过期

常见审批缓存会记录动作、参数、风险分数和生成时间。这些字段能回答“是不是同一个动作”和“结果是否足够新”,却不能回答“当时允许它的治理条件是否仍成立”。撤销可能发生在有效时间窗内,也可能不改变动作本身。

因此,时间过期与授权过期是两个独立维度。一份结果可以时间上很新、动作上完全匹配,同时在权限上已经失效。只缩短缓存时间只能降低暴露窗口,不能消除这种逻辑缺口。

完全取消缓存当然最保守,却会放弃分类和评审的延迟收益。更有价值的设计,是识别真正决定授权连续性的事实,让相关变化精确使证据失效,而不是让所有事件都触发全局清空。

把审批证据绑定到授权身份

所选实现用会话历史重写代数、真实用户消息数量和宿主成功生成的用户输入响应数量组成授权版本;工作线程还可以关联根任务的授权身份。这个元组不是审批结果本身,而是描述审批生成时所处的权限上下文。

缓存命中因此需要多道条件:动作仍匹配,风险结果仍可用,时间条件满足,并且记录的本地与根授权身份仍等于当前身份。身份不相等时,系统不会把旧的低风险判断当成当前许可,而是标记授权已变化并回到正常评审路径。

这种做法保留了选择性失效。不会改变已表示权限事实的普通事件,无须清空全部缓存;真正影响授权的历史改写、用户消息或宿主输入结果则会推进版本。它比“每个事件都清缓存”更精确,也比“只看时间”更有治理含义。

并发撤销使消费时复核成为必要

只在分类开始时记录版本还不够。分类器运行期间,用户可能撤销授权;一个迟到的低风险结果随后写入缓存,如果批准路径只相信结果自带的旧版本,就会把撤销前证据转换成撤销后的执行权限。

维护者测试覆盖了这种竞争:授权在分类进行中发生变化,低风险结果虽然完成,却不能进入快速批准。关键检查位于消费点,也就是证据即将被转换成执行权限的时刻。

消费时复核仍不是绝对原子性。核验之后、工具效果发生之前,授权还可能再次改变。风险更高的动作可能需要把复核与准入提交放进同一原子边界,或在效果点再次检查。当前证据只支持已展示的缓存竞态关闭,不能自动证明更强边界。

版本相等只证明元组编码的事实

授权版本的力量取决于它包含什么。如果外部企业策略、工具配置、组织成员关系或远程主体身份没有进入元组,版本相等就不能证明这些事实未变化。一个结构清晰的版本号也可能制造超出其覆盖面的信心。

因此,每次新增携带权限的输入,都应审查授权版本结构:它是否进入本地身份、根身份或另一项独立有效性检查?恢复、分叉和跨进程重启后,缓存证据能否继续证明来源?是否需要不可变摘要或签名回执支持外部审计?

证据来自一个已合并实现及其维护者测试,没有独立基准,也没有证明分类器判断正确、下游工具正确或分布式主体绑定完整。它建立的是一个强而有界的工程规则:复用审批证据之前,先证明生成它的授权身份仍是当前身份。

一手证据: 代码智能体已合并提交 035295b4。该实现与并发回归测试支持授权版本绑定和消费时复核,不证明版本元组覆盖全部权限事实。

Last updated: