如何用eBPF和可信通道保护高自治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 的通信链路怎么做强制中介、身份绑定和最小权限理解不足小伙伴帮忙指正 ,生活加油我看远山远山悲悯持续分享技术干货感兴趣小伙伴可以关注下_一句话先说结论这篇论文最核心的观点是当 Agent 已经能自主开进程、连网络、调外部工具时安全问题不能再只靠应用层 SDK 或运行时库兜底而应该把通信中介、身份验证、授权范围和可审计委托重新下沉到系统边界用eBPF TLS 通道绑定 远程证明做成不可绕过的guard layer。作者提出的Grimlock想解决的是三个系统级目标no-bypass所有沙箱流量都必须经过防护层channel binding授权必须和当前加密通道绑定least privilege权限委托必须最小化、短时化、可审计名词解释eBPFLinux 内核中的可编程机制可在网络和系统调用等关键点插入策略与观测逻辑不用修改内核源码就能实现灵活的流量拦截和控制这也是它能做“不可绕过”中介的核心原因。kTLSkernel TLS把 TLS 记录处理下沉到内核数据路径中简单说就是让内核负责加解密比用户态 TLS 更高效还能保证透明性。attestation证明某个执行环境和软件栈确实处于可信状态的机制比如确认 Agent 运行在安全的沙箱里没有被篡改。CVMConfidential 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 escalationAgent 利用权限漏洞提升自己的权限policy bypassAgent 绕开应用层的安全策略直接发起未授权通信审计边界模糊操作记录分散在应用层无法形成完整的审计链路。尤其是高自治 Agent 往往具备这些特征让上述问题更难解决能开任意 socket自由发起网络连接不受约束能派生子进程通过子进程绕开应用层限制能调应用地址空间之外的工具直接和系统底层交互绕过应用层防护能跨主机和其它 agent 通信通信范围广安全边界难以管控。这种情况下如果你只靠以下方式做安全防护那很容易被绕过应用库Agent 可以修改或绕过应用库的逻辑SDKAgent 可能不加载 SDK或篡改 SDK 的执行流程用户态拦截用户态的拦截逻辑容易被 hook 或绕过运行时约束运行时的约束可被动态修改无法保证持久性。Grimlock 的核心思想是什么论文给出的答案很明确把安全职责拆成两层上层负责业务下层负责安全 enforcement各司其职既不影响 Agent 功能又能保证安全边界不被突破。上层应用继续做编排Agent 框架和应用层依然可以负责自己擅长的事情不用修改核心逻辑orchestrationAgent 任务的编排和调度任务拆分把复杂任务拆分成可执行的子任务高层业务逻辑实现具体的业务需求比如数据处理、工具调用。下层高权限系统基座负责 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 一个沙箱一台主机一个守门人”。流量路径大致是这样的结合论文逻辑拆解成步骤方便理解Agent 在自己的沙箱里发起网络连接比如和其他主机的 Agent 通信eBPF 程序在沙箱的 ingress / egress 位置拦截所有流量——这一步是强制的Agent 无法绕开eBPF 把拦截到的流量强制重定向到本地主机的 guard proxy本地 guard proxy 和目标主机的 guard proxy 建立标准TLS 1.3加密通道确保通信链路本身的安全在 TLS 握手完成后双方 guard proxy 执行 post-handshake attestation握手后远程证明并把授权结果绑定到当前建立的 TLS 通道上目标侧的 guard proxy 再次校验本地 proxy 发送的 Scope Token包括权限范围、有效期和通道绑定信息确认无误后才允许流量通过只有通过所有策略检查后明文流量才会被释放到目标 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 连接绕开应用层的 sidecarAgent 可以通过派生子进程绕开。Grimlock 最有价值的地方之一就是明确把“不可绕过”放在第一位——用 eBPF 从内核层拦截所有流量Agent 没有任何绕开的可能这才是真正的强制中介而不是“建议性中介”。对工程实践的启发结合平时做系统安全和性能调优的经验这篇论文给我的工程实践启发主要有三点很务实也很容易落地参考1. 高自治 Agent 的安全边界要尽量下沉越依赖应用自己记住每一步权限逻辑越容易出现绕过和漂移——就像我们平时做 Linux 系统安全把防护逻辑放在内核层、网络层比放在应用层更可靠。高自治 Agent 的安全也是一样尽量把身份、授权、流量管控下沉到系统层做成不可绕过的约束才能从根本上保证安全。2. 授权最好绑定到具体通道而不是只绑定身份如果只绑定身份不绑定通道很容易出现“身份凭据被窃取后滥用”的问题——比如 Agent 的身份凭据被窃取攻击者可以用这个凭据在其他通道上发起未授权请求。把授权绑定到具体的通信通道上能有效减轻 replay、relay、diversion 这类攻击风险让授权更安全。3. “可绕过的安全代理”很危险如果代理只是建议路径而不是强制路径那在高自治系统里往往不够——Agent 可以轻易绕开代理发起未授权通信。工程实践中一定要确保代理是“不可绕过”的比如用 eBPF 拦截流量、用内核防火墙限制出站路径只有这样代理的安全管控才有意义。总结如果只用一句话总结这篇论文我会这样说Grimlock的真正价值不是简单给 Agent 通信加一层 TLS而是把高自治 Agent 的通信重新收编到一个不可绕过、带远程证明、通道绑定和最小权限授权的系统级 guard layer 里。对我来说这篇论文很有代表性因为它说明Agent 能力越强安全边界就越不能只停留在应用层最终真正可靠的 Agent 平台很可能都要在系统层把身份、流量和授权重新硬化一遍——这和我们做 Linux 系统安全“底层加固、分层防护”的思路完全一致。博文部分内容参考© 文中涉及参考链接内容版权归原作者所有如有侵权请告知 论文 PDFhttps://os-for-agent.github.io/papers/AgenticOS_2026_paper_23.pdfAgenticOS 2026 Workshophttps://os-for-agent.github.io/© 2018-至今 liruilongergmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)