为什么可观测性不足以支撑 Agent 治理
如今，AI 代理之间相互委派任务，调用工具，并触达那些处理资金与数据流动的 API。几个月后，若有人追问某代理当时被允许做什么、为何被允许，大多数机构只能翻查操作追踪（trace），却发现追踪日志天生就不是为了充当证据而设计的。
今天，我们正式推出 Traefik Hub 中的 Sovereign Trust Plane。它旨在回答关于任何代理操作的三个核心问题：谁授权的？依据哪条策略放行或拒绝的？自记录生成以来，其内容是否被篡改过？它在一个能看清所有交互跳板的地方给出答案。
目前，AI 基础设施市场上的每家供应商都在销售监控代理行为的手段。但细看之下，大多止步于同一环节：调用被允许的那一刻。请求通过了认证，越过了护栏，工具获得许可，追踪日志写入完毕，大家便各自收工。
问题在于，六个月后，没人再关心那通调用是否被允许。人们关心的是：谁允许的？依据是什么？手头这份记录，是否就是当时写入的那一份？这是截然不同的问题，而单纯的追踪日志无法解答。
我过去十年都在构建位于请求路径中的软件。随着代理的兴起，我发现这个位置恰恰是治理能够真正落地完成的唯一场所。
代理操作跨越三条边界
剥离表象，看代理在运行时到底在做什么，你会发现三类调用。它通过模型进行推理；通过工具执行行动，且越来越多地经由 Model Context Protocol（MCP）完成；而行动最终落在 API 上——无论是你的还是合作伙伴的——在那里资金流动，数据发生改变。
这些边界中的每一个都可以单独治理。 模型网关 负责治理第一层边界。 MCP 网关 负责治理第二层。 API 网关 已经治理第三层边界长达二十年。但几乎没有谁会用同一身份、同一策略和同一记录来同时治理这三层边界，因为在大多数环境中，这三层分属三个产品，由三个不同团队维护。
这种割裂带来一种我频繁看到的特定故障模式。团队在 Agent 和 MCP 服务器之间放置一个网关，便以为万事大吉。然而，MCP 服务器随后通过另一个拥有不同规则的后端 API 网关调用后端，甚至完全绕过网关。第一层边界得到了治理，而真正产生效果的第二层边界，却成了别人的问题。模型侧的情况也类似：每个 Agent 默默持有自己的 Provider Key，没人能说清哪个 Agent 调用了哪个模型。
我们打造 Traefik Hub，旨在将模型网关、MCP 网关和 API 网关整合为同一个二进制文件、同一套配置模型和同一条中间件流水线。这不是简单的打包策略，而是下文所有功能的前提条件，因为只有当同一系统观察到完整操作链路时，记录才是完整的。
这也解答了一个我在所有关于 Agent 的对话中常被问到的问题：治理逻辑是否应该嵌入 Agent 框架内部？不，不应该。企业通常会运行多种框架，再加上一些无法进行插桩监控的采购 Agent。框架（Harness）只治理自己内部的 Agent，而网关在仍由你控制的边界处治理所有 Agent。
调用被允许，治理并未结束
审计要依次回答三个问题。我们构建 Sovereign Trust Plane 就是为了在每次调用中都回答这三个问题，并据此将三项能力分别命名为 Delegate、Authorize 和 Prove。
谁授权的？
这就是 Delegate。当一个 agent 把任务交给另一个 agent 时，绝不能把凭证直接交出去，而是要换取一个 token——只针对这一个任务、这一个资源，有效期以分钟计而非小时。权限在每一跳都逐步收窄，而"从人 → 第一个 agent → 第二个 agent"这条链路本身也清晰可查地写在 token 里。接收方拿到的凭证，是发送方无法伪造的。这就是标准的 OAuth token exchange，具体来说是 IETF Identity Assertion JWT Authorization Grant（ID-JAG）——也就是 Okta Cross App Access 背后的草案，MCP 最新修订版所称的企业托管授权。Traefik 从不签发权限，签发权始终在你的身份提供方手里，我们只负责传递和收窄。
依据什么策略？
这就是 Authorize。凭证不等于决策：工卡能让你进大楼，却批不了一笔五万欧元的采购。所以在执行动作的那一刻，网关会询问你的策略引擎——这个主体能否对这个资源执行这个操作——并内联执行判定结果，无论 API 流量还是 MCP 工具调用都一视同仁。引擎是你的，策略语言也是你的。我们只通过开放的 AuthZEN 标准与它对话，不代写任何策略。
而且当答案是"不"时，它不是一个让 agent 反复重试的干巴巴的 403，而是明确指出限制和对应的策略：
403 Forbidden
{
"error": "forbidden",
"reason": "amount 2400.00 exceeds agent limit 500.00",
"policy": "refund-cap-tier2"
}agent 据此可以采取行动：降低金额、请求审批，或上报给人工。调用方能看到多少细节由你配置：可信的内部 agent 可以被告知策略内容，外部 agent 则知悉更少。无论哪种情况，这次拒绝都会像一次批准一样如实写入记录——这就引出了第三个问题。
怎么证明你没撒谎？
这就是 Prove，也是人人都忽略的问题。下面详细拆解 Traefik Hub 的 Prove 能力。
Trace 不等于证据
我们针对每次模型调用、工具调用和 API 调用都输出 OpenTelemetry 数据，如果你的 Agent 在生产环境中运行，这必不可少。但我需要精确定义什么是 Trace，因为行业正在悄然要求 Trace 完成一项其设计初衷从未包含的任务。
Trace 服务于工程师处理事故。它针对查询和成本进行了优化，这意味着它会被采样、过滤，并遵循保留策略到期。这些权衡对于找出“第六分钟为什么慢”是合理的。但对于作为证据，它们却是致命的。每十个请求采样一个，审计员无法从中了解那九个未采样的请求。此外，Trace 是由被检查系统写入的，该系统可以对其进行重写。
把它想象成行车记录仪。它有助于你厘清发生了什么。但它不是保险公司定损的依据，因为它并非为作为证据而设计，所以每隔几天就会覆盖旧数据。
证据服务于不同的受众，且要在数月之后。这需要不同的保障。它必须是完整的，包含所有决策，无论是允许还是拒绝。它必须携带决策发生时的上下文，因为决策无法基于事后已改变的状态来解释。并且它必须由没有理由采信你单方说法的人进行验证。
错误在于要求同一条管道完成两项任务。我们的观点是，捕获只在网关处发生一次，然后馈送到组织中的任何消费者。事故遥测数据发送到你的可观测性堆栈并进行采样。安全事件在其自身的保留策略下发送到 SOC 的 SIEM。而一个独立的证据存储则获取每一个未采样的决策，并具备其他存储不需要的一致性强保证。相同的事件，多个终端，不同的承诺。
签名你自己的日志毫无意义
大多数“不可篡改审计日志”的说法在此处失效，而推理过程正是问题的核心。
假设你对每个决策进行哈希链处理，使得中间的任何编辑都会破坏后续所有内容，将其放入 Merkle 树 中，以便通过几十个哈希值即可证明任意条目存在，并用你的密钥签署树的检查点。这是可靠的密码学。这确实是我们所做的。但就其本身而言，它对组织外部的任何人都不具备证明力。
每位工程师都知道为什么，因为他们都用过 Git。你控制的仓库无法证明被强制推送（force-push）掉的内容。丢弃最近五百条记录，重建目录树，签署一个新的检查点：所有验证依然通过。日志在逻辑上完全自洽，但它描述的是一段从未发生过的历史。没有人去修改那条有罪证据，他们只是在故事到达那里之前就把它截断了。
桶锁（Bucket locks）和仅追加文件（append-only files）也是同样的逻辑。这是运营方基于自身基础设施做出的承诺。它是个好的控制手段，但不是证据。
唯一的出路是借助他人的记忆。见证方（Witness）是一个独立服务，针对每条日志只保留一样东西：它看到的最后一个检查点。当你发送新检查点时，它验证你的签名，要求证明新树是旧树的延伸，只有通过验证后才进行联合签署。一旦见证方在条目 184,203 时看到过你的日志，它就永远不会再签署 183,703。这种单调性由一个你无法施压的第三方强制保证。这正是证书透明度（Certificate Transparency）背后的机制，它让公共 Web 的证书诚实了十年，你使用的每个浏览器都依赖于此。
人们常搞错的一点是见证方看到了什么。以下是跨越你边界的完整负载：
POST /add-checkpoint
// 跨越你边界的完整负载
old 184203
logs.yourbank.internal
184203
Ilb9V0s7j...jJQL40wm0=
— logs.yourbank.internal tZ3TC14t...xwLDmQQ=
— witness.example.org x101AAAA...S1ATmkmk=注意，这里没有具体的条目、负载或决策。银行的内部日志可以由外部方见证，而无需泄露日志内容。这意味着你可以自己选择见证方：我们的服务、你自己的团队（前提是该团队不运行网关），或者在受监管环境中最锋利的选择：让审计方作为见证方。他们的密钥、你的网络，以及最终判定证据的一方，正是为证据背书的一方。
实际交付的内容
我讨厌那种把设计蓝图吹嘘成成品的发布文章，所以下面是本周早期访问版本中实际包含的内容，通用版本计划于 2026 年 9 月 30 日发布。
透明度日志正式推出。网关已有的每一条日志和访问日志——覆盖 API、模型和 MCP 流量——都会被哈希后写入一个只能追加的 Merkle 日志，并附带签名检查点。提交的是哈希而非内容。你的日志仍留在原处，这正是设计的初衷：它是网关已有输出的第二存储目标，而不是一个新埋点项目，也不会给请求路径增加任何延迟。日志存放在普通文件系统或对象存储中，运行在你自己的基础设施上。
校验器也正式推出。它跑在你自己的机器上，从你的存储中读取日志，检查检查点签名和见证人副署，证明每条记录确实包含在日志中，并根据原始日志文件重新计算每条已提交的哈希。只要某一行的某一个字符被改动，它就能告诉你具体是哪一处。
随本次发布，Traefik 提供一个公开见证人服务，你也可以自己搭建。你可以把网关指向我们的服务，在你掌控的基础设施上运行这套实现，或者让独立团队或审计方来运行。没有见证人时，日志能检测到除签名密钥持有者之外的任何篡改行为。有了见证人，日志运营方也会受到约束——因为一旦你无法控制的第三方看过日志，任何内容都无法再被删除。我希望这个区别被真正理解，而不是被含糊带过。
记录承载的是决策，而不仅仅是请求。每条记录都写明网关做了什么决策、产生该决策的策略，以及实际操作的人和 agent。拒绝请求和批准请求会被同样记录，因此记录既能体现允许了什么，也能体现阻止了什么。访问日志本身就带有 trace 标识符，任何证据条目都能回链到完整 trace，供工程师深入排查。
委托与执行都是经过验证的，而非仅仅声称。我们已经端到端跑通了完整流程——先做 RFC 8693 token exchange，再做 RFC 7523 redemption——对接了 Okta Cross App Access 和自托管的 Janssen Auth Server，整条链路无需经过云端身份服务即可闭环。我们还通过网关内置的 AuthZEN 中间件，对接 OpenFGA 和 Cerbos 完成了执行验证。
主权由架构保证
若主权建立在他人云上，便称不上真正的主权。请求路径中不存在 SaaS 控制平面。网关完全自主托管，且配备支持离线运行的管理器。有权授权的身份提供方由你掌控，负责决策的策略引擎也由你掌控。日志只是你自有文件系统上的一个目录，验证程序只需在笔记本上运行。整个系统可无限期在气隙环境中运行，唯一需要跨越边界的只是一串哈希值。
这套系统构建于我们七月发布的底层之上：一个符合 FIPS 140-3 标准的版本 以及 Distro Zero 镜像，后者不残留任何需要加固的成分。我曾撰文指出该镜像是一项安全决策。对于最需要此类能力的场景，它也是合格标准——在这些环境里，"能否在无出站流量的情况下运行" 是人们在阅读功能列表之前首先关注的。
职责边界何在
任何诚实的控制系统描述，都必须指明其边界在哪里。
Traefik Hub 管控通信路径，而非内部逻辑。它看不到 API 背后的微服务，看不到 Agent 自身的日志，也看不到模型推理所依赖的上下文。哪里触达不到处理器，就审计其输入和输出。网关能准确记录在每个边界上发生了什么，以及基于什么依据。但它无法解释 Agent 为何想做这件事。行为是可观测的，认知不是，模型输出的推理内容只是另一种模型输出，而非计算过程的记录。混淆这一界限的厂商，正在兜售无法兑现的东西。
日志只能证明某条记录未被篡改，却不能证明其内容真实。完整性不等于准确性。
记录无法倒填
我刻意没有将论证建立在监管截止日期上。根据 欧盟 AI 法案，针对高风险 AI 的留存记录义务从 2027 年 12 月起生效——这一日期已推迟过一次，且高风险的定义仍在争议中。日期可能再次变动，但需求本身不会改变。
这是一个经得起任何截止日期考验的论据。你提到的其他所有控制手段都可以事后补救。下个季度加个策略引擎，它管的就是下个季度的流量；明年收紧授权，它从上那天起就生效。唯独记录是唯一的例外。等到明年才开启它，你拿到的就只有明年的数据。在那之前的一切，无论付出多大代价，都永远是一片空白。
分类标准可以稍后再定，而且不单由你说了算。如果 2027 年标准反了过来，记录中的缺口就是发现的问题。这使得记录变得像一份廉价的保险，而它现在只需要一次配置变更就能搞定。
该问自己团队哪些问题
如果你是CISO（首席信息安全官）：对于上个季度移动资金的 Agent，你能否指出是谁授权了该操作、依据哪条策略，并证明记录完整无损，而无需让平台团队去重建？除了运行平台的团队外，还有谁能确认记录没有被截断？
如果你负责风险与合规：你的证据来源是否和你那些会过期的事故遥测数据一样，来自同一个采样管道？你的控制手段是否记录了拒绝行为，以便你不仅展示 Agent 做了什么，还能展示它被阻止做了什么？
如果你负责产品和 Agent 本身：当 Agent 做出糟糕的决定时，你能否重构当时的上下文，还是只能看到系统现在的样子？而且，从你的 MCP 服务器到后端 API 这条链路，是否像从 Agent 到服务器那条链路一样受同一规则约束，还是处于无人管辖的状态？
接下来该怎么做
业界大多数人在决策阶段就止步了。我们要一直走到记录这一层。
阅读这篇工程深度剖析，看看为什么哈希链（hash chain）无法检测截断，为什么 Merkle 树能获得单条哈希链无法提供的两项证明，以及见证人（witness）究竟改变了什么。然后运行验证器检查你自己的日志，篡改其中一条条目，观察它变红。如果你更想和我们直接讨论这个话题，我们非常乐意。
别全信我们。去检查见证人。
常见问题
面向 Agent 的 AI 治理框架需要覆盖哪些内容？
Agent 的操作会跨越三个边界：调用模型进行推理、通过 MCP 调用工具、对后端 API 执行操作。如果治理框架只覆盖其中一个边界，另外两个就处于无人监管的状态。因此框架必须基于同一身份和同一策略源，对这三个边界统一进行授权、策略执行和证据记录。
这与 MCP gateway 有什么关系？
MCP gateway 治理的是工具调用这一边界，检查 Agent 是否有权调用某个工具。但单靠它只能覆盖整个链路中的一段。如果 MCP server 通过另一个网关、甚至完全不经过网关去调用后端 API，那么真正触发资金或数据变动的那个操作就处于无治理状态，尽管工具调用本身已经过授权。
为什么 trace 不足以满足审计需求？
Trace 会经过采样和过滤，是为排查故障而设计的，而不是为了在数月后作为证据使用。Traefik Hub 在常规 tracing 之外增加了一个独立的、不做采样的证据通道，并提供 trace 从未具备的完整性保证。
为什么仅靠防篡改的自签名日志还不够？
因为持有签名密钥的人仍然可以截断历史记录，重新签发一个“干净”的检查点，而所有密码学证明依然能针对这份缩短后的日志验证通过。内部的一致性，对组织外部的一方来说并不构成证明。
什么是 Certificate Transparency，它为什么在这里很重要？
Certificate Transparency 是一个公开系统，通过要求将证书签发记录存储在独立监控可访问的日志中，确保过去十年 Web 证书的可信度。Sovereign Trust Plane 借用了其核心机制——一个仅向前反签的独立见证者——并将其应用于 agent 决策记录，而非证书。