准入检查更多，不等于更安全
一个 Agent（智能体）在全新机器上配置 API（应用程序编程接口）密钥。Provider（服务提供方）接受了密钥，在线验证也通过了，但第一个 Agent 仍然启动失败：运行时要求本机完成一项 CLI（命令行界面）探测，而这项探测只属于另一条订阅执行通道。
这不是“少装了一个工具”这么简单。系统把未被选择通道的依赖变成了当前通道的权威门禁。准入检查只有与实际执行通道语义一致才有意义；检查更多，并不自动更安全。
当正确凭证仍进不了门
同日研究对象分析了 Paperclip（智能体编排项目）的一次干净机器失败与合入修复。直接密钥通道的凭证已经在服务提供方边界通过验证，旧流程却继续执行本地订阅命令行界面的连接探测。机器没有安装该工具，于是有效路线被错误拒绝。
修复先解析连接模式，再按模式验证：密钥通道在服务提供方边界重新核验密钥，不再咨询本地命令行界面；订阅通道仍保留连接探测要求。发布冒烟测试使用窄范围的安全超文本传输协议模拟，只响应预期的模型列表请求，意外路径返回 404。
来源报告相关环境路由测试 26/26 通过，连接与兼容性测试 42/42 通过，TypeScript（类型脚本语言）检查也通过。这些结果支持修复机制，但不能代替包含该修复的下一版 Canary（金丝雀版本）在真实发布路径上的端到端证据。
通道决定证明义务
一个产品可以提供多条执行通道，但每条通道依赖的事实并不相同。
直接 API 通道需要证明：密钥属于哪个 Provider、Provider 当前是否接受它、请求将发往哪个端点。订阅 CLI 通道需要证明：本机二进制是否存在、会话是否有效、当前环境是否能启动它。混合通道可能同时需要远端凭证和本地主机能力。
因此，准入规则不应从“产品支持什么”推导，而应从“这次实际选择了什么通道”推导。否则，系统会把所有通道的要求取并集，看起来严格，实则把不相关事实提升为拒绝权。
反方向同样危险。通道化并不是跳过检查。它应当删除不适用的证明，同时加强适用证明。此次修复没有简单放行 API-key 路线，而是把验证放回真正的权威边界：Provider。
四种事实不能压成一个布尔值
至少四种证据身份需要分开：
- 凭证有效性：特定 Provider 是否接受这份凭证；
- 主机能力：当前机器是否具备所选通道需要的运行条件；
- 执行通道身份：系统最终将通过哪一条具体路线执行；
- 业务授权：这个 Agent 此刻是否可以产生目标业务效果。
它们回答不同问题。凭证有效不说明本机能运行本地工具；主机具备工具不说明会话有效；前三项全部成立，也不说明 Agent 可以给客户发消息、修改生产数据或发生费用。
一个总的 admission=true 会抹掉这些差异。发生故障时，审计者只能看到“没进门”，却不知道是哪项要求适用、谁验证了它、证据何时过期。
一份可审计的准入证明包
更可靠的机制是让通道选择器同时产出一份版本化的 Proof Bundle（证明包）。它至少记录：
- 稳定的通道标识与合同版本；
- 该通道要求的事实清单；
- 每项事实的权威验证者；
- 证据值或摘要、采集时间与新鲜度窗口；
- 明确不适用的负面要求；
- Provider、凭证、主机与运行环境身份；
- 证明包与实际执行路线之间不可含糊的绑定；
- 独立的动作时业务授权证据。
如果执行时换了通道，旧证明包立即失效。若凭证、主机或 Provider 状态具有时效性，超过窗口后必须重新读取。可缓存不等于永久有效。
这套设计的关键不是增加日志，而是保存“这项事实为什么适用”。只有这样，错误的跨通道复用才会在审计中显形。
更多检查为何反而危险
统一检查清单常被理解为保守策略：要求越多，漏掉的风险越少。但安全取决于语义，不取决于数量。
未使用通道的依赖可能造成两种伤害。第一是误拒绝：合法 Worker（工作器）无法进入本来可用的路线。第二是错误权威：团队开始把“安装了某个工具”当成整套系统可执行的证明，却没有验证真正使用的凭证与 Provider。
通道化规则也有成本。要求映射若散落在多个调用点，会产生配置漂移。因此系统需要一个规范化的“通道—要求”注册表，并为每种路线编写正例、反例与切换测试，而不是在各处堆叠临时条件。
技术可用不等于业务授权
Provider 接受密钥，只能证明这份密钥在那个边界可用。它不证明组织允许本次业务动作。主机探测通过，也只证明运行条件存在。
高影响动作仍需在调用时检查当前授权：任务所有者是谁，目标与范围是否一致，人工批准是否仍有效，策略是否变化，外部前置状态是否满足。技术准入回答“能不能走这条路”，业务授权回答“现在可不可以做这件事”。
把两者拆开还有一个好处：技术环境可以复用，动作权限不必随之继承。长期运行的数字员工不应因为昨天通过过一次环境检查，就自动获得今天的新目的地与新效果。
边界与未决问题
当前证据来自一个产品的一条干净机器路径。它没有证明所有 Provider、企业联合身份或混合通道都能使用同一种模式，也没有给出统一的新鲜度窗口。
但有界原则已经足够清楚：准入必须证明所选路线真正依赖的事实，并把证明绑定到实际使用的路线；无关依赖不能拥有拒绝权，技术可用性也不能拥有业务授权权。
仍需回答的问题包括：混合通道怎样组合远端与本地证明；长任务中合同版本变化如何迁移；怎样证明执行通道没有在准入后悄然切换；哪些动作必须在技术准入后再次获得人工批准。
证据与来源：
- Paperclip PR（项目拉取请求）#13372：按执行通道修复准入探测，合入工程证据，2026。