Grimlock论文学习：如何用eBPF和可信通道保护高自治Agent通信

这篇文章基于 AgenticOS 2026 论文《Grimlock: Guarding High-Agency Systems with eBPF and Attested Channels》整理，重点讨论当 Agent 拥有越来越高自治权时，系统层应该如何把身份、通信和最小权限授权重新收回到可信边界里。

写在前面

---

• 博文内容为 AgenticOS 2026 论文 Grimlock: Guarding High-Agency Systems with eBPF and Attested Channels 的学习笔记
• 论文地址：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_23.pdf
• 这篇论文不是在讲 Prompt 或 Agent 编排，而是在讲更底层的事情：高自治 Agent 的通信链路怎么做强制中介、身份绑定和最小权限
• 论文关键词很集中：eBPF、kTLS、attested channels、least privilege
• 理解不足小伙伴帮忙指正 :),生活加油

我看远山，远山悲悯

持续分享技术干货，感兴趣小伙伴可以关注下 ^_^

---

一句话先说结论

这篇论文最核心的观点是：

当 Agent 已经能自主开进程、连网络、调外部工具时，安全问题不能再只靠应用层 SDK 或运行时库兜底，而应该把 通信中介、身份验证、授权范围和可审计委托 重新下沉到系统边界，用 eBPF + TLS 通道绑定 + 远程证明 做成不可绕过的 guard layer。

作者提出的 Grimlock，想解决的是三个系统级目标：

• no-bypass：所有沙箱流量都必须经过防护层
• channel binding：授权必须和当前加密通道绑定
• least privilege：权限委托必须最小化、短时化、可审计

名词解释

• eBPF：Linux 内核中的可编程机制，可在网络和系统调用等关键点插入策略与观测逻辑
• kTLS：kernel TLS，把 TLS 记录处理下沉到内核数据路径中
• attestation：证明某个执行环境和软件栈确实处于可信状态的机制
• CVM：Confidential VM，机密虚拟机，用于提供更强隔离和可证明执行环境
• channel binding：把身份或授权结果绑定到一个已经建立好的加密通道上，避免被重放或转接
• least privilege：最小权限原则，只授予完成当前任务所必需的最小能力
• no-bypass mediation：系统保证所有流量都必须经过 guard 层，不能绕开
• guard proxy：部署在主机侧、负责中介、认证和授权的高权限代理
• Scope Token：带有权限范围、时效和通道绑定信息的授权令牌
• TLS 1.3 exporter：从当前 TLS 会话导出绑定材料的标准机制，常用于通道绑定
• confused deputy：高权限组件被低权限请求误导，代替其执行越权操作的问题
• provenance：请求、身份、执行环境和授权链路的可追溯来源信息
• remote authorization：基于远程身份和证明结果做出的授权判定

论文到底在解决什么问题

随着 Agent 权限越来越高，很多本该由系统层负责的安全问题，开始被应用自己硬扛：

• 身份校验
• 授权逻辑
• 凭据传递
• 通信信任链
• 审计与归因

论文认为，这会导致几个经典问题重新出现：

• confused deputy
• privilege escalation
• policy bypass
• 审计边界模糊

尤其是高自治 Agent 往往具备这些特征：

• 能开任意 socket
• 能派生子进程
• 能调应用地址空间之外的工具
• 能跨主机和其它 agent 通信

这种情况下，如果你只靠：

• 应用库
• SDK
• 用户态拦截
• 运行时约束

那很容易被绕过。

Grimlock 的核心思想是什么

论文给出的答案是把安全职责拆成两层：

上层：应用继续做编排

Agent 框架和应用层依然可以负责：

• orchestration
• 任务拆分
• 高层业务逻辑

下层：高权限系统基座负责 trust enforcement

更低层的基座来统一负责：

• identity
• authentication
• authorization
• provenance

Grimlock 就是这样一个 guard layer。

它不是修改每个 agent 的代码，而是在沙箱边界建立一个不可绕过的中介路径，把 Agent 的所有通信都先导入防护层，再决定能不能放行。

Grimlock 的架构设计

论文里的部署图很清楚。

每台主机上主要有两类组件：

• per-agent sandbox CVM
• per-host proxy CVM

也就是说：

• 每个 Agent 在自己的机密沙箱里运行
• 每台宿主机有一个更高权限的 guard proxy

流量路径大致是：

1. Agent 在沙箱里发起连接
2. eBPF 在沙箱边界拦截流量
3. 流量被强制重定向到本地主机 guard proxy
4. proxy 和目标主机 proxy 建立标准 TLS 1.3
5. 在握手后执行 attestation，并把授权绑定到当前通道
6. 目标侧 guard 再次校验 token、scope、expiry 和 channel binding
7. 只有通过策略检查后，明文流量才会被释放到目标沙箱

为什么论文选择 eBPF

论文对这一点解释得很直接：

高自治 Agent 是不可信且高度动态的，纯应用层或运行时级别的 enforcement 太容易被绕过。

eBPF 在这里的作用是：

• 在沙箱 ingress / egress 位置做强制中介
• 把流量和稳定的沙箱身份关联起来
• 把所有通信导向受控 guard 路径
• 不需要修改 Agent 自身代码

这就是论文强调的：

• no-bypass mediation

它的意思不是“理论上建议走代理”，而是系统必须保证不经过代理就根本出不去。

为什么选择 post-handshake attestation

很多远程证明系统喜欢把 attestation 放在握手前或握手内。

论文这里选择的是：

• post-handshake attestation

原因是它想同时满足两件事：

• 兼容标准 TLS 1.3
• 又能把授权结果绑定到已经建立好的具体通道上

作者的做法是：

• 先建立标准 TLS
• 再通过 exporter-based channel binding 和 freshness nonce，把 attestation 结果绑定到当前通道

这样做的好处是：

• 不用改 commodity TLS 1.3 协议栈
• 能减轻 replay、diversion、relay 这类攻击风险

kTLS 在这里解决了什么问题

如果所有安全控制都要经过用户态，性能和透明性都会受影响。

论文引入 kTLS 的目标是：

• 让 TLS record 的加解密下沉到内核数据面
• 保持对 agent 代码透明
• 降低代理式强制中介的性能损耗

换句话说，Grimlock 想做的不是“为了安全把通信路径做得特别重”，而是：

在系统边界变硬的同时，尽量让数据路径继续高效。

Scope Token 和最小权限委托

论文里另一个关键点是：

• Scope Token

guard 在 attestation 通过后，会签发：

• 短生命周期
• 通道绑定
• 带作用域

的 token。

这个 token 里编码的是：

• 当前连接允许做什么
• 面向谁
• 多久有效

这正是论文强调的 scope-bound authorization。

它的价值在于，Agent 和 Agent 之间的授权不再是粗粒度的“能连就都能做”，而是：

• 绑定到当前连接
• 绑定到当前身份
• 绑定到具体授权范围

论文的贡献点怎么看

这篇论文篇幅不长，贡献也很聚焦，主要是四点：

1. Transparent mediation

给出一种对 Agent 代码透明的通信中介架构。

2. No-bypass enforcement

用 eBPF 把“必须经过 guard”做成系统级强制约束。

3. kTLS dataplane

在不改 Agent 代码的情况下，把 TLS 数据路径尽量留在内核里。

4. Scope-bound A2A authorization

把 Agent-to-Agent 授权和当前通道绑定，并保持可审计、最小权限。

我对这篇论文的几个理解

下面是我自己的理解。

1. 它抓住了高自治 Agent 的一个真问题

随着 Agent 权限增加，很多系统会越来越像“小型分布式系统”：

• 多个 agent 彼此通信
• 不同 host 间有流量往来
• 本地和远程工具混合调用

这时如果还把安全边界主要放在应用代码里，迟早会出问题。

2. 这是把“服务网格 + 机密计算 + 最小权限授权”揉到 Agent 场景里

从系统直觉看，Grimlock 像是把几类成熟思想结合起来了：

• 服务网格的强制中介
• 机密计算的远程证明
• 零信任里的最小权限
• 内核路径里的网络强制执行

但它的特别之处在于，这一切都是围绕高自治 Agent 的威胁模型组织的。

3. no-bypass 比“建议接入代理”重要得多

很多系统都会有代理、sidecar、服务网关，但问题常常不是没有代理，而是：

• 代理是否可绕过

Grimlock 最有价值的地方之一，就是明确把“不可绕过”放在第一位。

论文的局限

1. 更偏架构与机制设计

这篇论文更像架构提案，重点是威胁模型、数据路径和安全机制组织，不是大规模性能 benchmark 论文。

2. 部署复杂度不低

要落地 Grimlock，需要：

• CVM 支撑
• eBPF 能力
• kTLS 支撑
• attestation verifier / issuer

这对很多普通环境来说门槛不低。

3. 主要聚焦通信安全，不是完整 Agent 安全系统

它解决的是 Agent 通信链路和授权边界，不等于已经解决：

• Prompt Injection
• 工具供应链
• 模型越权推理

这些其它层面的安全问题。

对工程实践的启发

1. 高自治 Agent 的安全边界要尽量下沉

越依赖应用自己记住每一步权限逻辑，越容易出现绕过和漂移。

2. 授权最好绑定到具体通道，而不是只绑定身份

否则 replay、relay、diversion 这类问题会更难处理。

3. “可绕过的安全代理”很危险

如果代理只是建议路径，而不是强制路径，那在高自治系统里往往不够。

总结

如果只用一句话总结这篇论文，我会这样说：

Grimlock 的真正价值，不是简单给 Agent 通信加一层 TLS，而是把高自治 Agent 的通信重新收编到一个不可绕过、带远程证明、通道绑定和最小权限授权的系统级 guard layer 里。

对我来说，这篇论文很有代表性，因为它说明：

• Agent 能力越强
• 安全边界就越不能只停留在应用层

最终，真正可靠的 Agent 平台，很可能都要在系统层把身份、流量和授权重新硬化一遍。

参考

• 论文 PDF：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_23.pdf
• AgenticOS 2026 Workshop：https://os-for-agent.github.io/

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :)

---

---

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)