Agent 联邦与零信任通信

Agent 联邦与零信任通信

学习目标

本章介绍多个 Agent 实例如何在跨机器、跨组织、跨信任边界的环境中安全地协作。核心挑战是：Agent 之间需要在不共享敏感数据的前提下完成协同工作，同时能够动态评估对方的可信度。

前置知识

本章涉及 Agent 间通信的通用原理，建议先阅读：

• 多 Agent 路由与隔离 — Agent 隔离与消息路由
• 记忆系统设计 — Agent 记忆与状态管理

下文假设你已理解上述概念，直接聚焦跨信任边界的联邦通信。

核心概念

为什么需要 Agent 联邦

单个 Agent 系统的能力受限于本机资源。当多个团队、多个组织、多个云区域的 Agent 需要协作时（例如：共享欺诈信号、联合模型训练、分布式任务分解），就建立了 Agent 联邦——一组互相通信的 Agent 实例。

联邦的核心矛盾：协作需要信息交换，但信息交换可能泄露敏感数据。

零信任架构

零信任的核心原则是：默认不信任任何外部 Agent，信任必须通过验证逐步建立，且可以随时被撤销。

身份验证：mTLS + Ed25519

联邦成员之间的身份验证采用两层机制：

层	技术	作用
传输层	mTLS（双向 TLS）	确保通信双方都是合法的证书持有者
应用层	Ed25519 签名	每条消息都有发送方的数字签名，防止伪造

为什么不用共享密钥？ 共享密钥在多方协作中难以管理（每对参与者需要一个密钥），且密钥泄露后所有通信都受影响。mTLS 的证书体系支持逐个体吊销。

PII 门控数据流

联邦中最关键的安全管线：在数据离开本机之前，自动检测并处理个人身份信息（PII）。

14 种 PII 类型（通用分类，不依赖具体实现）：

类别	示例	敏感度
电子邮件	user@example.com	高
电话号码	+1-555-0100	高
社会安全号	XXX-XX-XXXX	极高
信用卡号	4111-XXXX-XXXX	极高
IP 地址	192.168.1.1	中
API 密钥	sk-ant-…	极高
密码	••••••	极高
姓名	John Doe	中
物理地址	123 Main St	中
出生日期	1990-01-01	中
医疗 ID	—	极高
驾照号	—	高
护照号	—	高
银行账户	—	极高

关键设计：PII 检测必须是自适应的——根据历史误报/漏报数据自动调整检测阈值，避免过度脱敏导致协作失效。

动态信任评分

信任不是一次性授予的，而是通过持续的行为评估动态调整：

通用信任评分公式：

trust_score = 0.4 × 成功率 + 0.2 × 可用性 + 0.2 × 安全评分 + 0.2 × 数据完整性

因子	含义	如何测量
成功率（40%）	完成任务的质量	任务结果评估（成功/失败/部分完成）
可用性（20%）	在线时间与响应速度	心跳检测、响应延迟统计
安全评分（20%）	是否触发安全告警	入侵检测、异常行为标记
数据完整性（20%）	传输数据是否被篡改	签名验证、哈希校验

信任升级规则：

• 新成员默认从 Untrusted 开始
• 连续 N 次成功交互 + 高评分 → 升级到 Trusted
• 任何安全违规 → 即时降级（无需人类介入）
• 信任历史衰减：长期不活跃的 Agent 信任度逐渐降低

Circuit Breaker（熔断器）模式

当检测到异常行为时，自动触发熔断：

状态	行为
Closed（闭合）	正常通信，持续监控
Open（断开）	停止所有通信，记录审计日志
HalfOpen（半开）	允许有限试探请求，验证对方是否恢复

问题与规避

陷阱 1：信任评分被操纵

问题：恶意 Agent 通过少量低价值任务快速提升信任评分，然后发起高价值攻击。

规避：

• 信任升级需要时间门槛（不能仅在短时间内完成大量任务）
• 不同信任级别的权限差异足够大，即使被突破也能限制损害
• 异常行为检测独立于信任评分（例如：突然访问从未访问过的资源类型）

陷阱 2：PII 误报导致协作失败

问题：过于激进的 PII 检测将正常的协作数据（如技术文档中的示例邮箱）误判为敏感信息。

规避：

• 使用上下文感知检测（不仅匹配正则，还检查使用场景）
• 维护白名单（已知的非敏感模式）
• 提供人工复核通道，对拦截数据快速放行

陷阱 3：联邦中的级联故障

问题：一个节点的故障通过联邦网络传播，导致多个节点连锁崩溃。

规避：

• Circuit Breaker 在连续失败时自动断开
• 联邦成员之间的连接应该是松耦合的（任务超时、重试有上限）
• 关键路径不依赖单一联邦成员

陷阱 4：证书管理复杂度

问题：mTLS 需要为每个 Agent 颁发、更新、吊销证书，规模增大后管理成本高。

规避：

• 使用自动化 CA（证书颁发机构）和短生命周期证书
• 证书轮换期间保持双证书有效期重叠
• 联邦规模较小时可考虑 Ed25519 签名验证替代 mTLS（降低一层复杂度）

设计取舍

mTLS vs 应用层签名

维度	mTLS	应用层签名（Ed25519）
安全层	传输层	应用层
防护范围	通信通道加密	每条消息独立签名
证书管理	需要 CA 基础设施	只需管理密钥对
性能	TLS 握手开销	签名验证开销小
防伪造	防止中间人攻击	防止消息伪造

推荐：两者结合使用。mTLS 保护通道，Ed25519 保护消息——即使通道被攻破，消息伪造仍可被检测。

集中式 vs 分布式信任

维度	集中式信任（CA 颁发）	分布式信任（Web of Trust）
管理复杂度	低（单一 CA）	高（每个节点管理自己的信任）
单点故障	CA 被攻破 = 全网受损	无单点
扩展性	好	差
适用场景	企业内联邦	开放互联网联邦

推荐：封闭联邦用集中式，开放联邦用分布式。

同步 vs 异步审计

维度	同步审计（每次交互都记录）	异步审计（定期批量记录）
合规性	强（HIPAA、SOC2、GDPR 友好）	弱
性能	每次交互增加延迟	延迟分摊
存储	实时存储压力	批量写入更高效

推荐：高合规要求场景用同步审计，一般场景用异步审计。

参考来源

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)
• NIST SP 800-207: Zero Trust Architecture