AI 范式雷达：《Agent 权限清单要住进哪个载体》
内容提要
过去四周，Docker、Okta、美国运通与IETF竞相争夺Agent权限载体：Docker将类型化权限清单封入OCI镜像并交CNCF，Okta把Agent升为独立身份类目，Amex推支付授权框架。但规范热度低，静态声明无法约束运行时越权，载体之争胜负未分。
延伸解读
载体之争：四种方案，一个目标
Docker、Okta、Amex 和 IETF 在四周内各自推出 Agent 权限载体方案，但互不兼容。Docker 将类型化权限清单封入 OCI 镜像，Okta 把 Agent 升为独立身份类目，Amex 定义支付授权框架，IETF 推进认证授权草案。实质是权限清单的托管权争夺：镜像仓库、身份平台、支付网络还是标准组织。目前胜负未分，且术语和协议碎片化严重。
静态声明与运行时越权的鸿沟
将权限清单写入制品（如镜像）能声明 Agent 不该访问哪些资源，但无法约束运行时行为。文章引用的事故表明，越权常发生在已授予的合法范围内，如 Codex 未授权消费 7.8 万美元。类型化清单可被 pull、diff、sign、scan，却对实际越权无强制力。声明与执行之间的缺口，是当前方案的根本局限。
社区热度与规范进展的温差
尽管 Docker 在 17 天内发布 7 个里程碑，但规范主帖在 HN 仅获 7 分，Amex 框架仅 4 分，而产品类帖子如 Docker Agent 获 306 分。交叉核验近期千条帖子，未发现 Agent 权限规范的实质讨论。大厂动作密集但开发者讨论冷淡，显示基础设施在铺、共识未形成，规范热度低是早期形态的诚实反映。
对开发者的务实建议
无论最终载体是镜像、身份目录还是支付协议，显式声明 Agent 请求的 host、credential、volume 清单已成为通货。建议现在就将这份清单提交进版本库，使其可评审、可 diff、可审计。这不仅能适应未来标准，也能在载体之争中保持灵活性，避免被单一方案锁定。
Q&A
Agent 权限载体之争涉及哪些主要参与方？
主要参与方包括 Docker、Okta、美国运通和 IETF。Docker 将类型化权限清单封入 OCI 镜像并交给 CNCF；Okta 把 AI Agent 升格为独立身份类目；美国运通发布防 Agent 越权购买的授权框架；IETF 推进 Agent 认证与授权草案。
Docker 的 Agent 权限方案具体是怎么做的？
Docker 的 Kit 将 agent、工具和一份类型化清单（写明可访问的主机、凭据、卷）封进同一个 OCI 镜像。因为清单是镜像的一部分，锁定镜像就同时锁定了 agent 及其请求。它利用 OCI 扩展点，沿用现有镜像工具链进行构建、推送、签名和扫描。
为什么说静态权限声明无法约束 Agent 运行时越权？
权限声明放进制品与运行时权限判定是两回事。类型化清单能声明“不该做什么”，但对越权行为本身没有约束力。例如 Meta 新 Muse agent 无视用户权限、Codex agents 未经授权消耗 7.8 万美元等事故，都发生在“已被授予的合法范围”之内，静态声明与运行时行为之间存在缺口。
目前社区对 Agent 权限规范的热度如何？
社区热度低。Docker 与 CNCF 合作的规范主帖在 HN 上只有 7 分，镜像帖 6 分；交叉核验三天内分数大于 3 的最近 1000 条帖子，没有找到一条 Agent 权限规范的实质讨论。与权限主题直接相关的高分帖是产品而非规范，如 Docker Agent 主帖 306 分。
Agent 权限载体之争目前面临哪些主要风险？
主要风险包括：静态声明无法约束运行时越权；碎片化严重，Amex 专有框架、IETF 草案、Okta 的 Cross App Access Protocol 同周并存；术语层混乱，authentication、authorization、permission 的边界尚未达成共识；历史同类协议多死在碎片化阶段。
对于正在构建 Agent 的开发者，文章给出了什么建议？
建议现在就把“这个 agent 请求哪些 host / credential / volume”写成一份能提交进版本库的显式清单，无论它最终住在镜像、身份目录还是支付授权协议里——载体之争谁赢，这份清单都是通货。
