状态可以保留，权威必须重新确认
一条会话已经运行数小时，模型路由、请求头和项目配置都仍然有效。与此同时，管理员修改了当前供应商要求，身份提供者取得了新令牌，工作区也从可信变为不可信。
如果系统把“还在”理解成“仍有决定权”，连续性就会悄悄升级为永久授权。长寿命智能体真正需要的不是每次清空状态，而是明确：哪些状态可以保留，哪一来源负责当前权威，冲突时使用什么优先算子，以及检查必须发生在何种效果之前。
本文比较三个近期合并的工程变更。它们分别落在会话、传输和沙箱层，却给出一个共同结论：连续性状态可以继续有用，但不能永久拥有主权。每个会产生效果的操作都需要明确的当前权威所有者、确定性的优先算子，以及变更前仍可使用的安全控制。
连续性与权威是两条轴
保留会话可以避免反复重建上下文，保留请求配置可以支持身份切换前的连接，保留用户级命令可以维持个人工作习惯。这些都是连续性价值。
但状态有效编码、仍可读取或曾经通过校验，不等于它仍应控制下一次动作。权威可能已经转移到受管政策、当前认证提供者或受保护的主机状态。系统必须在状态“可用”与状态“有权决定”之间建立显式边界。
三个样本分别呈现三种算子：
- 重新校验：保留旧状态，但在特定操作前与当前权威比较；
- 替换：当当前权威值存在时，覆盖较低权威来源提供的同名字段；
- 隔离：让低信任执行域无法读取或修改决定未来权威的控制状态。
它们不能互相替代。
Codex（代码智能体运行环境）：在调用时重新校验保留会话
Codex 的变更针对已有应用服务器线程。运行时独立加载当前受管供应商要求，在选定的模型驱动或状态变更操作之前，把保留线程中的供应商选择和定义与当前要求比较。
关键不在“重新加载所有配置”。普通用户、项目和系统默认配置没有被用来重写既有线程；被单独提升为权威来源的是受管要求。若供应商不匹配，或当前要求加载、解析失败，受保护请求在改变队列或目标状态之前被拒绝。
这种失败关闭（fail-closed）行为是有边界的。中断、实时停止以及目标暂停和清除仍然可用；实时路由也不在该检查范围。换句话说，系统阻止需要新权威的正向工作，同时保留降低风险的负向控制。
该证据覆盖已枚举且有测试的调用路径，不能证明未来新增入口天然不会绕过检查。调用点完整性本身必须成为持续验证对象。
MCP TypeScript SDK（模型上下文协议 TypeScript 软件开发工具包）：给权威字段唯一所有者
模型上下文协议 TypeScript SDK（软件开发工具包）的问题发生在 HTTP（超文本传输协议）传输层。调用方可以提供 Authorization（授权）头、协议版本或会话标识，请求发送器也会根据当前认证与会话状态产生这些值。如果只是通用合并，两套来源可能同时存在；大小写不同的头名甚至可能组合成一个损坏的多值凭据。
修复先用调用方输入初始化标准 Fetch Headers（请求头集合），再通过不区分大小写的 set 操作写入传输层管理的授权头、协议版本和 Streamable HTTP（流式超文本传输协议）会话 ID（标识符）。认证提供者一旦取得令牌，运行时派生值就覆盖旧的调用方授权头；在令牌尚未出现的过渡阶段，已配置值仍可使用。
这里的算子是字段级替换，不是丢弃整组调用方配置。传输层只拥有它明确管理的名称，无关请求头继续保留。权威来自所有权和状态转换，而不是“哪个值最后写入”。
这个机制解决请求构造时的身份歧义，却不能证明服务端会正确授权令牌，也不等同于业务动作许可。
Gemini（谷歌人工智能）命令行工具：把控制状态隔离在低信任域之外
该命令行工具的变更处理另一个边界：沙箱或不可信项目内容不应读取、改写凭据、账户、信任判断、政策完整性状态和环境秘密。沙箱配置与主机路径检查缩小了可见和可写表面，并清理钩子及 API（应用程序接口）密钥相关设置。
命令加载也采用来源区分。不可信文件夹中仍允许用户全局拥有的命令，但项目和扩展命令被排除。系统没有因为信任下降而关闭全部功能，而是阻止低信任来源把自己提升为控制来源。
这类问题不能只靠调用前比较解决。若项目代码能够修改下一次比较所依赖的政策或凭据，重新校验只会忠实读取被污染的“当前”状态。隔离的作用是保护权威存储本身。
它的保证仍依赖主机强制执行和正确路径解析，不能从配置文件单独推导完整沙箱安全。
三种算子解决不同冲突
| 场景 | 保留状态 | 当前权威 | 合适算子 | 主要失败模式 |
|---|---|---|---|---|
| 长寿命会话遇到新受管政策 | 线程供应商状态 | 受管要求 | 重新校验并拒绝 | 启动时授权衰减 |
| 调用方请求头遇到当前认证身份 | 静态 Authorization | 认证提供者令牌 | 字段级替换 | 双重身份与大小写合并 |
| 项目执行域接近凭据与信任状态 | 工作区代码和配置 | 受保护主机存储 | 隔离 | 工作区提升为控制面 |
“全部刷新”会破坏仍然有效的连续性；“最新值优先”会让新写入的低信任项目值压过受保护状态；“保留旧值直到报错”则会让过期权威越过变更边界。正确选择取决于字段所有者、操作类型和威胁模型。
拒绝正向工作后，停止能力仍应存在
失败关闭经常被误写成一个总开关：校验失败，所有操作都不可用。这会产生恢复锁死。无法继续调用模型并不意味着应禁止中断；不能采用旧认证发送请求，也不应删除无关头；不可信项目命令被排除，也不等于用户全局命令必须消失。
一份负向控制策略应单独列出中断、停止、暂停、清除、回滚和只读诊断等操作，并验证它们不会间接创建新工作。安全系统的目标不是“什么都不动”，而是“需要当前权威的正向效果不发生，同时风险仍可降低”。
最小权威优先合同
每类效果至少要声明：
| 合同字段 | 要回答的问题 |
|---|---|
| 保留状态身份 | 为连续性保留了什么 |
| 当前权威来源与版本 | 谁现在有权决定 |
| 刷新点 | 何时重新获取或确认 |
| 优先算子 | 比较拒绝、字段替换还是隔离 |
| 权威不可用行为 | 失败关闭、受限缓存或人工恢复 |
| 变更边界 | 最晚在哪一步阻止效果 |
| 负向控制 | 拒绝后哪些风险降低动作仍可用 |
| 证据回执 | 如何证明使用了哪个来源和规则 |
合同必须绑定操作类别。供应商要求可能约束模型驱动动作而不约束中断；认证提供者可以拥有 Authorization 而不拥有所有头；沙箱可以读取业务文件，却不应读取信任与密钥存储。
测试状态转换，而不只测稳定状态
权威错误常发生在过渡期，因此测试矩阵需要覆盖：
- 政策更新之前与之后的同一线程；
- 认证提供者取得令牌之前与之后；
- 同一头名的不同大小写与不同 HeadersInit（请求头初始化形式）；
- 可信与不可信工作区；
- 权威服务可用、不可用和返回无效数据；
- 正向操作被拒绝时，中断和回滚是否仍可执行；
- 检查失败后，队列、目标和外部状态是否保持未变。
这些测试不只是功能回归，也是优先合同的可执行说明。
边界与待解决问题
三个样本都是一手合并代码和测试，不是独立生产事故率或完整对抗评估。供应商路由、HTTP 认证和文件系统沙箱位于不同层，不能因为共享“权威优先”抽象就忽略各自威胁模型。
失败关闭会在政策服务不可用时降低可用性。签名缓存可以缓解，但缓存有效期、适用操作和失效条件本身也必须属于权威合同。负向控制的分类也需保持单调：一个看似“暂停”的接口不应暗中启动新任务。
仍待回答的问题包括：如何证明所有效果入口都执行了检查；哪些更新使在途工作失效；跨会话、传输、工具服务器与外部目标的权威如何组合；用户怎样迁移旧会话而不丢失无关有效工作；以及如何度量误拒绝与陈旧权威拦截，同时避免泄露秘密。
证据与引用：