圈内内参｜这期讲一篇 arXiv 论文提出的 post-fulfillment activation gap 到底是一个什么内部机制，以及它跟大厂 agent 试点里那层“权限一直收着”的传导链怎么对上号。结论轮廓：论文最值得内参圈留意的，不是八个安全属性那些条，而是它把“代理间委托时权限在激活那一刻才汇合”这个时点问题说清楚了，这东西在现网试点里是含糊的。信源说明：论文本身公开可查；涉及到的大厂试点这层，用的都是此前记录过的平台团队做法模式，不是这篇新采的匿名信源，所以相应地方我会标成“观察到的模式”，不硬凑成具名信源。
先把公开可核验的几项摆出来（确认）：论文编号 arXiv:2609.14744，v1 是 9 月 13 日提交，v2 是 9 月 18 日修订；作者 Genliang Zhu 和 Chu Wang，两人单位都是 Accentrust 加各挂一份高校——前者佐治亚理工，后者伊利诺伊香槟。分类 cs.AI/cs.CR，55 页，1 图 9 表 4 算法。v2 改的是标题和术语，加了共同作者，补了同行评议文献基础；技术结果不变。这句“技术结果不变”先放这，下面展开时你就不用担心是不是 v2 改了什么关键东西。
论文把桩打在最容易混过去的地方：支付、预算、OAuth、mandate、fulfillment 这一串机制，都是在“交易条件”这一层把关。OAuth 管你能不能访问某个 endpoint，管得住那次访问；mandate 管这次委托符不符合委托人说的用途；预算和支付管这次交易有没有越过边界。但资源回来之后，token 会在什么时候变成一条能被调用的权限、被委托方这个代理会不会带着它自己的凭据去碰委托方的资源，这不在这些检查的射程里。论文管这个射程之外的地方叫 post-fulfillment activation gap——资源交付之后、激活之前的那条授权缺口。它存在于三个场景里：工具介导创建、代理间委托、代理商务。
我这次只盯着中间那个。不是前两个不重要，是代理间委托这条在大厂 agent 试点里最能暴露“权限到底从哪条链上长出来”这件事，而这件事现在没人拆。工具介导创建那条，对应用“工具返回一个数据库连接或其他 credential 后，什么时候变成可用权限”；代理商务那条，对应用“支付完成之后返回的服务订阅，怎么在被调用前变成能力”。这两条本质是同一个缺口的两种表面，只是场景不同。不准备摊开，因为只要把代理间委托那个时点讲透，另外两个的机制是同一个。
据论文给的定义（确认）：代理间委托发生的时候，被委托方带着自己的权限，去替委托方干一件事，返回的资源可能要激活成可用能力。问题就在这里——“要激活”这三个字，在大多现网试点里是没有单独执行的那一步的。代理间委托这块，此前记录过的情况是，几个平台团队试点让一个 agent 拿着委托方给的一小撮权限去访问某个镜像仓库或数据库，返回之后，那个 agent 会顺手把这个资源递给另一个 agent 做后续步骤。争议点不在第一步，而在第二步：第二个 agent 自身带的权限，会不会因为接手这个资源而自动放大到它原本不该碰的范围。论文的立场很明确：不该自动放大，激活这一步必须独立剥出来做一次合并计算。观察到的模式是：现网试点把第二个 agent 的权限直接收到最小，以减少出事面。效果不错，但代价是业务跑不动，这也是“权限收着不放开”这种状态背后的一个实际来源。这里有个时间错位，大厂收的是“进”，论文说的是“出”。这个错位本身，就是这 55 页里我最在意的观察。
论文那套 provenance-bounded runtime authorization 架构，核心逻辑不是给代理更多权限，而是把激活这一步单独拿出来当最后一道门。它先把获取到的输出隔离起来，不让它直接作用于现有权限；然后通过带版本的解析器，从经过认证的提供方证据里解析出实际能力；再只在当前激活事务通过后激活资源。激活事务要检查的，不是“这事能不能干”这类宽口径，而是解析后的清单、来源、epoch，以及类型化资源-能力超图上的向下封闭关系包络。关系包络是给委托链做底稿用的，它要把身份、效果、数据、委托以及图范围限制都框在里面，避免被委托方的权限链在激活的那一刻溢到委托方去。代理间委托的难点，在“被委托方是否继承委托方权限”上，论文不是说不能继承，而是说这个继承必须在激活事务里经过关系包络那一层。也就是说，被委托方自身那条权限链，和委托方交出去的那条权限链，在激活时要能合起来算一笔账，但不能溢出去。单次效果许可则在这个合算之后重新验证并消耗。
如果把大厂一线常见那种“拿到 token 就等于拿到权限”的顺序排在这套逻辑旁边，差别就出来了：论文的顺序是隔离→解析→激活，前者是“拿到即生效”。这种排法下面，很多收着权限的操作其实是把“隔离”提前做了半截，但没收口到“激活”那一拍。在明确假设下，论文证明了八项安全属性：覆盖隔离、背书、非放大、拆分不可规避、崩溃/重试、退款、epoch 和效果限制。我判断（分析）：把这个清单摆出来，图的是“非放大”和“拆分不可规避”这两条，因为这两条恰好对应现网试点里最难沟通的两个点——一个被委托代理会不会把自己的权限放大到委托方的资源上，一个攻击者能不能把一次授权拆成多次绕开审批。剩下六条是完整性的必要填充，不展开。
交叉印证这层用论文自己公开的实验数字：五个资源类别，参考语义接受了 20/20 条良性轨迹，拒绝了 40/40 条已登记不安全轨迹，总计涉及 810 个事件。独立检查器在 60 条基础轨迹加 40 条细化轨迹上跟参考语义一致，并拒绝了 89/89 个篡改测试。代码这头，冻结的 Codex 和 Gemini MCP 客户端组件跑完 54/54 次确定性本地 stdio 调用。最接近现网的一组是登记的 18 例分阶段 MCP 到 Docker 组合测试——两条良性路径都完成，16 条不安全路径没有增加未授权的 Docker 启动请求。另外五源审计对 32 个单元里的 1,248 个字段对做分类，结论是没一个单元单独提供完整的激活画像。这最后一条我放一下：它说明的是，光靠单一来源（比如 OAuth 日志或 Docker daemon 审计日志）拼不出“这个返回资源该不该激活”的全图。这其实跟大厂内部合规审查里“数据出域申请”“代码留痕”这层是同一个道理，单点记录证明不了全链路。
把论文这套拆解摆到大厂 agent 试点的内部传导链上，能看出一个不算新的对位。观察到的模式是，平台工程效能团队先试点，业务团队跟进慢半拍；卡点不在工具能力，也不只是合规检查，而是“返回的资源几时成为可用权限”没有统一认定。论文把“激活事务”这个步骤单独抽出来之后，这种内部模糊就开始显形：现网试点的做法是把被委托代理的权限先收掉，论文的做法是在激活那一刻做一次独立审批。两种顺序的差别不是语义，是时点。这个时点差，正是大厂试点里常说的“权限收住了但业务跑不起来”的那条缝。
几个值得盯的信号，盖文不下注，只列出来一起看：一、这篇论文能不能从 cs.CR 这层被 agent 平台工程团队收进内部讨论——如果后面有平台团队开始把“激活”这个动作单独拆进审批流，那才是这篇东西的机制价值落地的信号。二、大厂内部 AI 编程使用规范文档下次更新时，有没有把“代理间委托的权限激活”单独拎出来写，这比任何媒体解读都直接。三、几家主流的 MCP 网关和 agent runtime 的后续版本，是否把 provenance-bounded 这套隔离+激活的时点策略纳进去，需要盯公开更新日志。四、那 89/89 个篡改测试和 18 例 MCP 到 Docker 那条，有没有被哪家内部安全团队复现过，看出现网差异。本期到这，有更准确信源的同学欢迎匿名补充。