协议即边界
MCP 风格的传输层是为单一可信调用方调用工具而构建的。在该模型中，传输层是一根管道：它在客户端和服务器之间传递 JSON-RPC 帧，而真正重要的安全决策发生在它之上，即工具实现中。当同一传输层被用于具有不同主体的对等 agent 时，这根管道就变成了边界。每一次重新序列化请求的跳转，都是来源信息被丢弃的地方。一条最初是用户请求、被规划 agent 改写、又被检索 agent 转发的消息，到达工具服务器时，已经没有任何可靠信息表明是谁请求了什么。
能力发现与能力授权的混同使情况更糟。发现回答的是“这个端点能做什么？”授权回答的是“这个主体是否被允许为该任务调用该能力？”MCP 风格的注册表通常暴露前者，而把后者留给调用方。在单一调用方模型中，这是站得住脚的。在对等 agent 模型中，这意味着任何能访问注册表的 agent 都能枚举完整的能力面并尝试调用，而接收方 agent 在传输层没有任何依据来拒绝。注册表变成了一张攻击面地图，被交到每个参与者手中。
这不是 MCP 作为工具协议的缺陷。把工具协议扩展到对等消息传递而不重新审视其信任模型，是一种范畴错误。相关的问题不是帧是否格式良好，而是传输层能否证明是谁发送了它们、代表谁、以及在什么约束下。
共享命名空间的 agent 之间的冒充
当 agent 由消息字段中的字符串而非密码学主体来标识时，任何 agent 都可以声称任何身份。在一个规划 agent 按名称寻址工作 agent 的 swarm 中，一个被攻陷或仅仅有缺陷的工作 agent 可以发送看似来自规划 agent 的消息。下游 agent 无法区分真实指令和伪造指令，因为传输层不携带签名，也没有通道绑定。这种失败是静默的：伪造的消息格式良好，能力存在，调用成功。
混淆代理流
一个低权限 agent 转发一个高权限调用。只要传输层授权的是连接而不是消息，这种情况就会发生。一个为其自身合法工作持有宽泛凭证的 agent，可以被诱导代表一个本不应拥有该凭证的调用方使用该凭证。代理并非恶意；它只是在做协议允许的事。经典缓解措施——检查调用方身份——会失败，因为调用方就是代理，而代理是被授权的。缺失的是原始主体与具体调用之间的绑定。
长时程运行中的消息重放
长时程 agent 运行会检查点状态并恢复。如果传输层不携带能在检查点后存活的 nonce，那么在一个步骤捕获的消息就可以在另一个步骤重放。重放可能在语义上有效：能力仍然存在，参数仍然能解析，接收方 agent 也不记得曾见过该消息。在跨越数小时和许多 agent 的运行中，重放窗口很宽，而缺少持久 nonce 意味着传输层无法区分重试和攻击。
将每条消息绑定到主体和任务标识符
会话标识符不够。会话会被重用、池化，有时还会跨任务共享。每条消息都应携带明确的主体（谁在行动）和任务标识符（该动作属于什么），并且两者都应被消息签名覆盖。主体是原始请求者，而不是直接发送者。任务标识符让接收方能够应用针对工作而非连接范围的政策。
一个具体机制：对消息信封的规范序列化进行签名，包括主体、任务标识符、能力名称和单调递增的序列号，使用发送方 agent 持有的密钥。接收方根据绑定到主体的密钥验证签名，对照该任务上次见到的序
将能力范围限定到消息，而不是连接
连接级授权是混淆代理流的根源。一个被授权调用某能力的连接可以出于任何原因调用它。相比之下，消息级能力授予会指明能力、任务、主体和过期时间。接收方检查授予，而不是连接。这意味着代理无法提权：它只能出示发给它的、用于所给任务的授予。
权衡是真实存在的。消息级授予为每次调用增加一个 token，需要一个签发者，并引入撤销问题。在高吞吐的内部 swarm 中，开销在延迟和签发者复杂性上都是可测量的。替代方案——信任连接——更便宜，并且会失败开放。设计选择在于传输层是否应在来源上失败关闭。对于跨信任边界的 agent 间通信，它应该失败关闭。
让传输层日志成为权威记录
agent 侧日志仅供参考。一个 agent 可能被攻陷、被重启，或者只是对自己做了什么记错了。如果一条消息的唯一记录存在于发送或接收它的 agent 中，那么该记录就不是证据。传输层应记录每个已签名信封及其验证结果，并且该日志应成为审计和重放检测的权威记录。这也提供了一个跨检查点强制 nonce 唯一性的地方：是传输层，而不是 agent，记住已经见过什么。
诚实的权衡
这些规则中的每一条都把工作从 agent 转移到传输层。这正是重点，也是代价。验证签名、跟踪序列号、签发和撤销消息范围授予、维护持久日志的传输层，比搬运字节的管道更复杂。它们需要密钥管理、签发者和能在重启后存活的日志。它们增加延迟和故障模式。在单一调用方工具调用中，这种复杂性并不合理。在主体分化且长时程运行会检查点和恢复的对等 agent swarm 中，这种复杂性就是安全属性。问题不是是否要付出它，而是在哪里付出：在传输层中，一次；还是在每个 agent 中，反复且不一致地付出。
下一步该做什么
将传输层视为攻击面，并像审计攻击面一样审计它。枚举请求被重新序列化的跳转，并追问哪些来源信息得以保留。将能力发现与能力授权分离，并在调用时要求授予。将消息绑定到主体和任务，而不是会话。让传输层日志成为权威，并用它进行重放检测。这些都不需要放弃 MCP 风格的传输层；它需要的是用对等通信所需的信任原语来扩展它们。关于 agent 协议安全的相关工作，见这份分析。