写在前面

---

• 博文内容为 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 的通信链路怎么做强制中介、身份绑定和最小权限
• 理解不足小伙伴帮忙指正 😃,生活加油

我看远山，远山悲悯

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

---

一句话先说结论

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

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

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

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

名词解释

• eBPF：Linux 内核中的可编程机制，可在网络和系统调用等关键点插入策略与观测逻辑，不用修改内核源码就能实现灵活的流量拦截和控制，这也是它能做“不可绕过”中介的核心原因。
• kTLS：kernel TLS，把 TLS 记录处理下沉到内核数据路径中，简单说就是让内核负责加解密，比用户态 TLS 更高效，还能保证透明性。
• attestation：证明某个执行环境和软件栈确实处于可信状态的机制，比如确认 Agent 运行在安全的沙箱里，没有被篡改。
• CVM：Confidential VM，机密虚拟机，用于提供更强隔离和可证明执行环境，论文中每个 Agent 和 guard proxy 都运行在独立的 CVM 里。
• channel binding：把身份或授权结果绑定到一个已经建立好的加密通道上，避免被重放或转接，防止授权被滥用。
• least privilege：最小权限原则，只授予完成当前任务所必需的最小能力，比如 Agent 只允许访问特定目标，且授权有时间限制。
• no-bypass mediation：系统保证所有流量都必须经过 guard 层，不能绕开，这是 Grimlock 安全的核心前提。
• guard proxy：部署在主机侧、负责中介、认证和授权的高权限代理，相当于每台主机的“安全守门人”。
• Scope Token：带有权限范围、时效和通道绑定信息的授权令牌，相当于 Agent 通信的“临时通行证”，过期即失效。
• TLS 1.3 exporter：从当前 TLS 会话导出绑定材料的标准机制，常用于通道绑定，确保授权和当前通信通道绑定。
• confused deputy：高权限组件被低权限请求误导，代替其执行越权操作的问题，比如 guard proxy 被恶意 Agent 欺骗，执行未授权操作。
• provenance：请求、身份、执行环境和授权链路的可追溯来源信息，方便后续审计和问题排查。
• remote authorization：基于远程身份和证明结果做出的授权判定，比如 Agent 跨主机通信时，目标主机的 guard proxy 校验其身份和授权。

论文到底在解决什么问题

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

• 身份校验：怎么确认通信的 Agent 是合法的，不是伪造的？
• 授权逻辑：Agent 能做什么、不能做什么，谁来统一管控？
• 凭据传递：授权凭据怎么安全传递，避免被窃取或篡改？
• 通信信任链：Agent 之间的通信的链路，怎么保证不被监听、劫持？
• 审计与归因：出了安全问题，怎么追溯是谁发起的请求、做了什么操作？

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

• confused deputy：高权限的 guard 被低权限 Agent 误导，执行越权操作；
• privilege escalation：Agent 利用权限漏洞，提升自己的权限；
• policy bypass：Agent 绕开应用层的安全策略，直接发起未授权通信；
• 审计边界模糊：操作记录分散在应用层，无法形成完整的审计链路。

尤其是高自治 Agent 往往具备这些特征，让上述问题更难解决：

• 能开任意 socket：自由发起网络连接，不受约束；
• 能派生子进程：通过子进程绕开应用层限制；
• 能调应用地址空间之外的工具：直接和系统底层交互，绕过应用层防护；
• 能跨主机和其它 agent 通信：通信范围广，安全边界难以管控。

这种情况下，如果你只靠以下方式做安全防护，那很容易被绕过：

• 应用库：Agent 可以修改或绕过应用库的逻辑；
• SDK：Agent 可能不加载 SDK，或篡改 SDK 的执行流程；
• 用户态拦截：用户态的拦截逻辑容易被 hook 或绕过；
• 运行时约束：运行时的约束可被动态修改，无法保证持久性。

Grimlock 的核心思想是什么

论文给出的答案很明确：把安全职责拆成两层，上层负责业务，下层负责安全 enforcement，各司其职，既不影响 Agent 功能，又能保证安全边界不被突破。

上层：应用继续做编排

Agent 框架和应用层依然可以负责自己擅长的事情，不用修改核心逻辑：

• orchestration：Agent 任务的编排和调度；
• 任务拆分：把复杂任务拆分成可执行的子任务；
• 高层业务逻辑：实现具体的业务需求，比如数据处理、工具调用。

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

更低层的系统基座来统一负责安全相关的核心能力，做成不可绕过的防护层：

• identity：统一管理 Agent 的身份，确保身份可验证；
• authentication：校验 Agent 的身份合法性，防止伪造；
• authorization：统一管控 Agent 的权限，遵循最小权限原则；
• provenance：记录 Agent 的操作链路，确保可审计、可追溯。

Grimlock 就是这样一个 guard layer。它不是修改每个 agent 的代码，而是在沙箱边界建立一个不可绕过的中介路径，把 Agent 的所有通信都先导入防护层，再决定能不能放行——这和我们平时做系统安全“拦在门口”的思路完全一致，只不过是针对高自治 Agent 做了专门的适配。

Grimlock 的架构设计

论文里的部署图很清晰，核心架构不复杂，每台主机上主要有两类组件，分工明确：

• per-agent sandbox CVM：每个 Agent 都运行在自己独立的机密沙箱 CVM 里，实现隔离，防止 Agent 之间互相影响，也防止 Agent 篡改主机系统。
• per-host proxy CVM：每台宿主机有一个更高权限的 guard proxy，运行在独立的 CVM 里，负责该主机上所有 Agent 的通信中介、身份校验和授权管控。

简单来说，就是“一个 Agent 一个沙箱，一台主机一个守门人”。

流量路径大致是这样的（结合论文逻辑，拆解成步骤，方便理解）：

1. Agent 在自己的沙箱里发起网络连接，比如和其他主机的 Agent 通信；
2. eBPF 程序在沙箱的 ingress / egress 位置拦截所有流量——这一步是强制的，Agent 无法绕开；
3. eBPF 把拦截到的流量强制重定向到本地主机的 guard proxy；
4. 本地 guard proxy 和目标主机的 guard proxy 建立标准 TLS 1.3 加密通道，确保通信链路本身的安全；
5. 在 TLS 握手完成后，双方 guard proxy 执行 post-handshake attestation（握手后远程证明），并把授权结果绑定到当前建立的 TLS 通道上；
6. 目标侧的 guard proxy 再次校验本地 proxy 发送的 Scope Token，包括权限范围、有效期和通道绑定信息，确认无误后，才允许流量通过；
7. 只有通过所有策略检查后，明文流量才会被释放到目标 Agent 的沙箱里，完成一次通信。

整个流程的核心就是“强制拦截→加密通信→身份验证→授权校验→流量放行”，每一步都由系统层强制保障，Agent 没有任何绕开的可能。

为什么论文选择 eBPF

论文对这一点解释得很直接，也很务实：

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

结合我们平时做 Linux 系统安全的经验，eBPF 在这里的核心作用，就是解决“不可绕过”这个痛点，具体有这几点：

• 在沙箱 ingress / egress 位置做强制中介：eBPF 可以挂载到内核的网络钩子上，拦截所有进出沙箱的流量，Agent 无论怎么发起连接，都必须经过 eBPF 的拦截；
• 把流量和稳定的沙箱身份关联起来：eBPF 可以获取沙箱的身份信息，确保流量和 Agent 身份一一对应，防止身份伪造；
• 把所有通信导向受控 guard 路径：eBPF 可以强制重定向流量，不管 Agent 想连接哪个目标，都先转发到本地 guard proxy，由 proxy 统一管控；
• 不需要修改 Agent 自身代码：这一点很关键——高自治 Agent 可能来自不同的开发方，修改所有 Agent 的代码不现实，eBPF 可以在不侵入 Agent 代码的情况下，实现强制防护。

这就是论文反复强调的 no-bypass mediation，它的意思不是“理论上建议走代理”，而是系统必须保证不经过代理就根本出不去——这和我们平时配置防火墙“只允许特定端口出站”的思路一致，只不过 eBPF 更灵活、更精细，能适配 Agent 动态通信的场景。

为什么选择 post-handshake attestation

很多远程证明系统喜欢把 attestation（远程证明）放在 TLS 握手前或握手内，比如先做证明，再建立加密通道。但论文这里选择的是 post-handshake attestation（握手后远程证明），原因很务实：想同时满足两件事，既兼容标准，又能保证安全。

作者的核心诉求是：

• 兼容标准 TLS 1.3：不用修改现有的 TLS 协议栈，降低部署成本，也能保证和现有系统的兼容性；
• 把授权结果绑定到已经建立好的具体通道上：如果在握手前做证明，证明结果和通道是分离的，可能出现“证明通过，但通道被劫持”的问题，握手后证明可以直接绑定当前通道，避免这种风险。

作者的具体做法也很简洁：

• 先建立标准 TLS 1.3 通道，确保通信链路的加密安全；
• 再通过 TLS 1.3 exporter 导出通道绑定材料，结合 freshness nonce（新鲜随机数），把 attestation 结果绑定到当前通道上。

这样做的好处很明显：

• 不用改 commodity TLS 1.3 协议栈：复用现有成熟的 TLS 实现，减少开发和部署成本，也降低了安全风险；
• 能减轻 replay、diversion、relay 这类攻击风险：因为授权结果和当前通道绑定，即使攻击者窃取了授权凭据，也无法在其他通道上复用。

kTLS 在这里解决了什么问题

我们都知道，用户态的代理和加解密会带来性能损耗——如果所有 Agent 的通信都要经过用户态的 guard proxy 做加解密，当 Agent 数量多、通信频繁时，性能会成为瓶颈。

论文引入 kTLS 的目标很明确，就是在保证安全的同时，解决性能问题，具体有这几点：

• 让 TLS record 的加解密下沉到内核数据面：内核级别的加解密比用户态更高效，能显著降低通信延迟和 CPU 占用；
• 保持对 agent 代码透明：Agent 不需要知道 kTLS 的存在，依然按照正常的方式发起通信，不用修改任何代码；
• 降低代理式强制中介的性能损耗：guard proxy 只负责身份校验和授权管控，不用再处理加解密操作，减轻了 proxy 的压力。

换句话说，Grimlock 想做的不是“为了安全把通信路径做得特别重”，而是：在系统边界变硬的同时，尽量让数据路径继续高效——这和我们做 Linux 性能调优“在安全和性能之间找平衡”的思路完全一致。

Scope Token 和最小权限委托

论文里另一个关键点是 Scope Token，它是实现“最小权限委托”的核心载体。

具体逻辑很简单：guard proxy 在 attestation（远程证明）通过后，会给 Agent 签发一个 Scope Token，这个 Token 不是永久有效的，也不是全权限的，而是带有明确的约束条件：

• 短生命周期：Token 有明确的过期时间，过期后自动失效，即使被窃取，也无法长期滥用；
• 通道绑定：Token 和当前的 TLS 通道绑定，只能在当前通道上使用，无法在其他通道复用；
• 带作用域：Token 里编码了具体的授权范围，比如“只能访问目标主机的某个 Agent”“只能执行某个操作”，超出范围的请求会被拒绝。

这正是论文强调的 scope-bound authorization（范围绑定授权）。它的价值在于，Agent 和 Agent 之间的授权不再是粗粒度的“能连就都能做”，而是：

• 绑定到当前连接：只能在当前建立的 TLS 通道上使用；
• 绑定到当前身份：只有签发时对应的 Agent 才能使用；
• 绑定到具体授权范围：只能做授权内的事情，多一步都不行。

这种方式很好地遵循了最小权限原则，也让授权变得可审计——通过 Token 里的信息，就能清楚地知道某个 Agent 在某个时间、通过某个通道、做了什么操作。

我对这篇论文的几个理解

下面是我自己的理解，结合平时做系统安全和性能调优的经验，不一定完全准确，供大家参考：

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

随着 Agent 权限增加，很多系统会越来越像“小型分布式系统”：多个 agent 彼此通信、不同 host 间有流量往来、本地和远程工具混合调用。这时如果还把安全边界主要放在应用代码里，迟早会出问题——就像我们平时做 Linux 系统安全，只靠应用层防火墙，而不加固内核和网络层，很容易被绕过。

Grimlock 的核心价值，就是意识到了“高自治 Agent 的安全，必须从系统层入手”，这和我们“安全防护要从底层加固”的思路完全一致。

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

从系统直觉看，Grimlock 像是把几类成熟思想结合起来了，但不是简单的堆砌，而是针对高自治 Agent 的威胁模型做了适配：

• 服务网格的强制中介：像 Istio 一样，把所有流量都导入代理，统一管控；
• 机密计算的远程证明：用 CVM 和 attestation 保证执行环境的安全性；
• 零信任里的最小权限：授权只给必要的权限，且有时间和范围约束；
• 内核路径里的网络强制执行：用 eBPF 实现不可绕过的拦截，从内核层加固安全边界。

它的特别之处在于，这一切都是围绕高自治 Agent 的威胁模型组织的——Agent 不可信、动态性强、权限高，所以需要更底层、更强制、更透明的防护机制。

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

很多系统都会有代理、sidecar、服务网关，但问题常常不是没有代理，而是“代理是否可绕过”。比如我们平时配置的 HTTP 代理，Agent 可以直接发起 TCP 连接绕开；应用层的 sidecar，Agent 可以通过派生子进程绕开。

Grimlock 最有价值的地方之一，就是明确把“不可绕过”放在第一位——用 eBPF 从内核层拦截所有流量，Agent 没有任何绕开的可能，这才是真正的强制中介，而不是“建议性中介”。

对工程实践的启发

结合平时做系统安全和性能调优的经验，这篇论文给我的工程实践启发主要有三点，很务实，也很容易落地参考：

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

越依赖应用自己记住每一步权限逻辑，越容易出现绕过和漂移——就像我们平时做 Linux 系统安全，把防护逻辑放在内核层、网络层，比放在应用层更可靠。高自治 Agent 的安全也是一样，尽量把身份、授权、流量管控下沉到系统层，做成不可绕过的约束，才能从根本上保证安全。

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

如果只绑定身份，不绑定通道，很容易出现“身份凭据被窃取后滥用”的问题——比如 Agent 的身份凭据被窃取，攻击者可以用这个凭据在其他通道上发起未授权请求。把授权绑定到具体的通信通道上，能有效减轻 replay、relay、diversion 这类攻击风险，让授权更安全。

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

如果代理只是建议路径，而不是强制路径，那在高自治系统里往往不够——Agent 可以轻易绕开代理，发起未授权通信。工程实践中，一定要确保代理是“不可绕过”的，比如用 eBPF 拦截流量、用内核防火墙限制出站路径，只有这样，代理的安全管控才有意义。

总结

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

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

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

• Agent 能力越强，安全边界就越不能只停留在应用层；
• 最终，真正可靠的 Agent 平台，很可能都要在系统层把身份、流量和授权重新硬化一遍——这和我们做 Linux 系统安全“底层加固、分层防护”的思路，完全一致。

博文部分内容参考

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

---

• 论文 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)