零信任的理论基础（NIST SP 800-207）发表于 2020 年。此后三个领域的发展正在挑战它的基础假设——不是否定零信任，而是要求它进化。

本文不试图给出标准答案——这些问题仍在工程社区的早期探索阶段。本文的定位是：把挑战讲清楚，指出当前最优实践。

前置阅读：零信任策略引擎、mTLS 大规模部署。

LLM Agent（如 Claude Code、OpenAI Agents SDK、LangChain Agent）的兴起正在制造一个零信任尚未解决的难题：身份不是”一个用户”，而是”一个 Agent 代表一个用户执行一系列自主操作”。

1.1 传统模型 vs Agent 模型

传统模型:
  用户 → 认证（用户身份） → 授权（用户权限） → 访问资源
  
Agent 模型:
  用户 → 委托（"帮我完成 X"） → Agent → 认证（是谁？Agent 本身？用户？） → 授权（以谁的权限？）

Agent 的权限困境： - 如果 Agent 以用户的全部权限运行：Agent 可以执行任何用户能执行的操作——包括危险操作（删除文件、修改数据库） - 如果 Agent 的权限被严格限制：Agent 无法完成用户委托的复杂任务（“帮我分析 Q4 数据并生成报告”需要读取多个数据库和文件） - 如果 Agent 在操作中途需要提升权限：传统 Step-up Auth 要求用户输入密码或 FIDO2 密钥——但 Agent 没有手，无法响应 step-up 挑战

1.2 OAuth 2.0 Token Exchange 的实践

当前的最优实践是 OAuth 2.0 Token Exchange（RFC 8693）——用户通过 OAuth 2.0 授权 Agent，Agent 获得一个受限的 token（scope 被限制为完成任务所需的最少权限），Agent 使用这个 token 来验证自己的身份和权限：

用户 → 向 IdP 授权 Agent "读邮件 + 创建文件" (scope: mail.read files.create)
IdP → 签发 delegration token (绑定到 Agent + 用户 + scope + 有效期)
Agent → 使用 delegration token 访问资源
资源 → 验证 token: subject = Agent, on_behalf_of = 用户, scope = mail.read + files.create

关键要求：token 必须同时编码 Agent 的身份（是谁在执行操作）和用户的身份（在代表谁执行操作）。审计日志需要同时记录两者。

1.3 SQL 查询的授权粒度

一个更棘手的问题：当 Agent 生成 SQL 查询时，授权检查应该在什么粒度上执行？

-- Agent 生成的查询：查询用户的订单
SELECT * FROM orders WHERE user_id = 12345;
-- 这个查询是安全的（只读取用户自己的订单）

-- 但如果 Agent 生成了这个查询：
SELECT * FROM orders;
-- 这应该被授权引擎阻止（读取所有用户的订单）

传统的 API 授权模型（“GET /orders 需要 ‘orders:read’ 权限”）无法处理”允许 orders:read 但只允许读取当前用户的 orders”这种粒度。需要的是查询级别的授权——策略引擎检查 SQL 的 WHERE 子句，确认它限制了数据访问范围。这是数据层零信任的自然进化方向。

二、边缘计算的零信任挑战

边缘计算设备（工厂 IoT 传感器、零售终端、5G MEC 节点）有三个特征，每个都对零信任的假设形成挑战：

2.1 间歇性连接的证书管理

SPIRE 的”1 小时 SVID TTL + 到期前自动续期”模型依赖 Agent 和 Server 之间的持续连接。在间歇性连接的边缘环境中： - 设备可能在下一次连接之前就已经错过了数次续期窗口 - 如果 SVID 过期了而设备仍在使用它——要么完全拒绝所有操作（fail-closed），要么允许过期证书继续使用（fail-open，安全降级）

当前的最优实践是更长的证书 TTL + 离线验证： - 边缘设备的证书 TTL 设为 24-168 小时（而非通常的 1 小时） - 验证方持有一个本地的证书吊销列表（CRL）缓存，在离线时也能检查证书是否已被吊销 - 设备重新上线时，SPIRE Agent 优先更新吊销状态再执行其他操作

2.2 没有 TPM 的设备身份

对于没有 TPM 的边缘设备，设备身份的建立只能依赖软件层面的证明： - MAC 地址 → 极其不可靠（可以伪造） - 预配的对称密钥（在烧录固件时注入）→ 对称密钥容易泄露 - 硬件序列号 + 制造商 CA 签发的证书 → 比软件方案强但仍然不够

这个领域目前没有标准答案。在实践的层面，对于关键基础设施的边缘设备（如电网控制设备），通常要求硬件安全模块（如 TPM 或 SE — Secure Element）。对于非关键设备（如温度传感器），软件层面证明 + 网络层隔离（该设备只能在受限的 VLAN 中通信）组合使用。

三、PQC 对零信任基础设施的冲击

NIST 在 2024 年 8 月发布了后量子密码学（PQC）的首批标准：

对零信任基础设施的直接影响：

3.1 X.509 证书和 SVID 的格式

当证书中的公钥从 ECDSA P-256（64 字节）切换为 ML-DSA（Dilithium，公钥 1.3KB，签名 2.4KB）： - SPIRE SVID 的大小增长：SVID 是一个 X.509 证书，公钥部分从 64 字节增长到 ~1312 字节 - mTLS 握手数据量增大：首次握手需要交换两个证书（客户端 + 服务端），加上双方都要出示签名。Dilithium 的签名是 2.4KB vs ECDSA 的 64 字节——握手数据包从几 KB 增长到十几 KB - 握手延迟增加：Dilithium 的签名操作比 ECDSA P-256 快（0.1ms vs 0.3ms），但数据传输时间增加了——在高延迟链路上，这可能是瓶颈

3.2 mTLS 握手的变化

TLS 1.3 的 PQC 支持仍在草案阶段。当前的最佳实践是混合模式——在 TLS 1.3 握手期间同时进行传统密钥交换（ECDH P-256）和 PQC 密钥交换（ML-KEM-768）：

TLS 1.3 Hybrid Handshake:
  1. ClientHello: 提供 ECDH 公钥 + ML-KEM 公钥
  2. ServerHello: 选择 ECDH + ML-KEM，发送 ECDH 公钥 + ML-KEM 密文
  3. 双方计算 shared_secret = HKDF(ECDH_shared_secret || ML-KEM_shared_secret)
  4. mTLS: 双方交叉发送证书和签名（ECDSA + ML-DSA 双重签名）

混合模式的理念是：即使 ML-KEM 在未来被新的攻击所破解，ECDH 部分仍然提供安全性。迁移到纯 PQC 需要在对 PQC 算法的长期安全性建立足够信心后才能进行——这可能需要 5-10 年。

3.3 哪些现在就可以准备

PQC 的标准刚刚发布（2024 年 8 月），广泛部署预计需要 5-10 年。但以下事情现在就可以做：

1. 确保加密算法可通过配置替换——不要在代码中硬编码 ECDSA P-256。证书格式、加密套件、密钥长度都应该是可配置的。
2. 关注 SPIRE 和 Envoy 的 PQC 路线图——SPIRE 社区的 PQC 工作正在进行，Envoy 的 TLS 库（BoringSSL）在 Chromium 的驱动下将是第一批支持 PQC 的实现。
3. 开始评估最大的风险——不是”有人用量子计算机攻破 TLS”，而是”攻击者现在截获加密流量，存起来，等未来有了量子计算机再解密”（Harvest Now, Decrypt Later, HNDL）。对于长期保密的数据（如密钥材料、身份数据），混合模式的双重加密可以减轻 HNDL 风险。

四、总结

三个新兴前沿的共同主题：零信任的基础原则是正确的（不信任任何单一因素、持续验证、最小权限），但具体机制需要针对新场景重新设计。

• AI Agent 的挑战是权限的粒度和代理——如何把”用户的全部权限”拆解为”Agent 执行特定任务所需的最少权限”
• 边缘计算的挑战是连通性和资源的约束——零信任的”持续心跳”模型在间歇性连接的边缘世界需要改写
• PQC 的挑战是加密原语的全面替换——从证书格式、TLS handshake、签名算法到整个 PKI 基础设施

本系列到此结束。建议从头阅读 系列索引 了解完整阅读路径。

参考资料

1. IETF. OAuth 2.0 Token Exchange. RFC 8693.
2. NIST. (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.
3. NIST. (2024). FIPS 204: Module-Lattice-Based Digital Signature Standard.
4. NIST. (2024). FIPS 205: Stateless Hash-Based Digital Signature Standard.
5. SPIFFE. SPIRE PQC Working Group. https://github.com/spiffe/spire/issues?q=label%3Aarea%2Fpost-quantum
6. IETF. TLS 1.3 Hybrid Key Exchange Using X25519Kyber768 / ML-KEM. (Draft)