eMicro: Real-Time Multi-Hop Access Control for Microservices with eBPF

Rizky Ramadhana Putra, Osama Bajaber, Saimon Amanuel Tsegai et al. · IBM Research / UNT · 2026-08-05

🎯 核心问题
微服务架构中传统的 service-to-service 访问控制只校验单跳请求合法性，无法检测多跳攻击（每一跳看起来合法，但整条调用路径违反安全策略）。这使得数据渗透和越权访问可以通过合法中间服务"接力"实现。现有方案要么需要侵入式改代码，要么无法在微秒级完成路径级策略判定。

🔧 关键方法
三项核心技术：(1) 基于历史的访问控制（history-based access control），将服务调用序列作为策略判定依据而非单次 hop；(2) 安全策略编码为确定性有限自动机（DFA），支持 O(1) 查找和紧凑的 label 逐跳传播——50M 条策略仅 100 MB 内存；(3) 基于 eBPF 的内核态请求追踪，无需修改业务代码即可透明注入执行路径，内核层面完成标签传播和策略匹配。与传统 sidecar proxy 方案（如 Istio/Envoy）的关键差异：eMicro 在内核态完成全部工作，避免了用户态到内核态的上下文切换开销。

📊 实验或论据
在 DeathStarBench 和来自 Uber、Alibaba、ByteDance 的生产级 trace 上评估，覆盖 1200 万请求工作流和数千服务实例。策略检查延迟 1 微秒，label 传播开销降低 90%，运行时性能影响"可忽略"。评估规模覆盖了真实大规模微服务场景。

⚠️ 局限
DFA 方案对策略表达力有限——无法处理需要上下文变量（如时间窗口、请求内容）的复杂策略。eBPF 对内核版本有依赖，abstract 未提及具体支持的最低内核版本。对加密 mTLS payload 的透明追踪能力存疑。

💼 对系统人的启示
这是 eBPF 在安全领域最有实操价值的方向之一——如果你的微服务集群已经超过百级服务且有合规需求（如 zero-trust path validation），eMicro 的 DFA + eBPF 架构值得直接借鉴。1μs 级策略检查意味着可以在生产环境无感部署。

Architectural Implications of Agentic AI Workflows

Jirong Yang, Peizhe Liu, Chaojie Zhang, Jovan Stojkovic · Microsoft Azure · 2026-08-05

🎯 核心问题
Agentic AI 工作负载在数据中心快速增长，但其对服务器架构的影响尚未被系统研究。Agentic 执行本质是碎片化且异构的：一个请求展开为 LLM 推理、工具调用、编排决策三类子任务，反复穿越 CPU-GPU 边界。传统均匀配置的服务器对这种"低利用率 + 突发尖峰"的负载模式严重不匹配。

🔧 关键方法
先建立 agentic workflow 分类学，再基于 Azure 生产数据 + 开源框架做首次架构画像。关键发现：CPU 处于关键路径上（编排和工具在 host 端执行），GPU 利用率因 model composition 而分化。基于此提出 Agora 原型方案，三项机制：(1) 动态收割空闲 CPU 核用于吞吐型旁路任务，同时保护 agentic 尾延迟；(2) GPU 内存超分——在每块 GPU 上放置更多 agent，预取下一个 agent 状态以隐藏 swap 延迟；(3) 按角色池化核心 + 亲和性感知调度恢复微架构局部性。三项机制自动适配工作负载。

📊 实验或论据
生产研究来自 Microsoft Azure（具体规模 abstract 未披露），受控研究基于开源 agentic 框架。Agora 在商用服务器上原型化，改善利用率和吞吐同时保持 agent 尾延迟。具体数字 abstract 未给出，需读全文。

⚠️ 局限
Agora 是"commodity server"上的原型，尚未涉及定制硬件（如 CXL 池化内存、disaggregated GPU）场景。GPU 内存超分的预取策略对 agent 切换模式的预测准确性有依赖——在高度随机的工作负载下可能退化。Abstract 未提及与现有 orchestrator（如 K8s device plugin、NVIDIA MPS/MIG）的集成。

💼 对系统人的启示
这篇对做 LLM serving infra 和集群调度的工程师极其相关——它首次量化了"agentic workload 和传统 LLM batch inference 的资源需求差异"。CPU 重回关键路径、按角色池化核心、GPU 内存超分这三个思路可以直接影响调度器设计。如果你在做 AI 集群的 capacity planning，这篇必读。

AtumAI: A Principled Framework for Agentic Generation of Datacenter Control-Plane Policies

Qiushi Lin, Chaojie Zhang, Íñigo Goiri, Aditya Akella, Ricardo Bianchini, Jovan Stojkovic · Microsoft Research / UT Austin · 2026-08-03

🎯 核心问题
数据中心控制平面策略（放置、扩缩容、电源管理）的设计空间巨大且相互依赖，人工原型一个策略需要数月。直接用 LLM agent 搜索存在三个不足：无形式化保证（hard constraint 可能违反）、无迁移性（任务间经验不复用）、不系统（只靠 LLM 提名候选，容易陷入局部最优）。

🔧 关键方法
两个核心组件：(1) Datacenter Task Compiler——将自然语言描述的目标自动编译为形式化的、可机器校验的任务规约（目标、约束、决策变量、评估方法），使搜索有结构可利用；(2) Evolutionary Design Discovery Loop——在规约空间上搜索，不只靠 LLM 提名候选，而是引入扩散模型（生成新候选）、进化算法（变异交叉）和代理模型（快速评估），扩大探索范围。两者配合将"接入新任务"从数月工程降为写一段任务描述。

📊 实验或论据
在三类控制平面任务上评估：workload placement、resource scaling、power management——每类有不同的问题规模和设计空间。AtumAI 生成的策略在所有任务上"一致优于专家手工基线"。具体数字和评估环境（集群规模、硬件配置）abstract 未提及，需读全文。

⚠️ 局限
形式化编译依赖自然语言描述的准确性——如果目标/约束表述含糊，编译结果的质量上界就受限。进化搜索对计算资源有需求（代理模型和扩散模型的训练开销）。此外，三类任务均为"offline policy generation"，对需要在线快速适应的场景（如突发故障切换）的适用性不明。

💼 对系统人的启示
对做集群管理和自动化运维的团队有方法论价值——将"用 AI 调参"升级为"用 AI 从规约出发系统搜索策略"。如果你的控制平面决策能被形式化为约束优化问题，AtumAI 的 Task Compiler 思路值得借鉴。但短期内更可能作为 offline policy 设计辅助工具，而非替代在线决策。

Source-Bounded Exact Recovery over Docker's Logs API

Kelvin Amoaba · 独立研究者 · 2026-08-03

🎯 核心问题
Docker 日志采集器（如 Grafana Alloy）在 attach 之前或宕机期间可能丢失容器已产生的日志。仅持久化读取位置（read position）不足以保证生命周期变更后的恢复。核心问题：通过 Docker Logs API 究竟能达到什么级别的恢复保证？

🔧 关键方法
定义"source-bounded exactness"语义：在源头保留的、可区分的记录最终恰好出现一次在持久化输出中。设计 generation-aware multiset oracle 来区分"源截断"和"采集器遗漏"，暴露同时丢失和重放的场景。应用于自研 LogDeck 系统后发现并修复了三个 bug：start-to-attachment 竞态、一条记录的 attachment 重叠、以及有限的 Docker API reconciliation 窗口。关键修复手段：单记录重叠容忍 + 精确插入语义。

📊 实验或论据
120 次 collector-run 对照实验：LogDeck 在 60/60 场景中达到 exact，Grafana Alloy 1.18.0 在 20/60 场景中 exact。Alloy 在"容器退出/重启后需重新发现源"的场景失败。因果控制实验：5000 条记录的源在采集前退出——stock discovery 0/20 exact（什么也没采到），直接给容器 ID 则 20/20 exact。在 OrbStack、Ubuntu（Docker 29.4.0 / 24.0.9）上复现。

⚠️ 局限
exact 保证依赖"物理 generation + timestamp + stream + bytes 四元组可区分"假设——对完全相同的日志行（如无时间戳的重复心跳）可能退化。20 万条 byte-identical 记录测试未观察到碰撞，但作者明确声明"不是碰撞自由性的证明"。另外，容器被 remove 后 Docker 不再保留日志——这是 API 层的硬限制，非采集器能解决。

💼 对系统人的启示
如果你用 Docker + 日志采集器且有审计级的 exactly-once 需求，这篇给出了可操作的结论：光 persist offset 不够，必须做"生命周期重获取"（lifecycle reacquisition）。对 Alloy/Fluentd/Vector 等采集器的选型和配置有直接参考价值。论文方法论（multiset oracle 测试框架）也适用于验证其他有序流的 exactly-once 实现。

Mutate to Bypass: Autonomous Endpoint Evasion via Knowledge-Driven Multi-Agent Orchestration

Weifeng Yuan, Wenbo Guo, Qingyun Du et al. · 多机构合作 · 2026-08-03

🎯 核心问题
商用 EDR（Endpoint Detection and Response）系统是否真能抵御已公开的绕过技术？验证这一点需要把碎片化的安全知识转化为可执行 payload，并从不透明的告警中迭代改进——目前缺乏自动化手段。

🔧 关键方法
AutoBypass 框架包含三部分：(1) Detection-Aware Knowledge Base——将威胁情报、专家分析、开源 PoC 结构化为规避技术和操作约束的知识库；(2) 多 agent 协作——攻击规划 agent、多态代码生成 agent、二进制编译 agent 分工；(3) 遥测驱动的推理引擎——诊断失败原因（为什么被检测到），将修正证据反馈回策略形成闭环。核心创新在闭环：不是一次性生成 payload，而是根据 EDR 反馈迭代变异。

📊 实验或论据
对 7 款商用终端安全平台测试。结果：全部成功绕过，Windows Defender 达 90% evasion rate，Trend Micro AV 达 86.7%。消融实验显示知识库将 8B 开源模型的成功率从 27-53% 提升至 43-83%，接近大型闭源模型水平。

⚠️ 局限
论文聚焦静态/启动阶段的绕过，对运行时行为检测（如 behavioral sandbox、memory scanning）的绕过能力 abstract 未提及。另外，这类工作的伦理边界需要注意——虽然定位为"resilience assessment"，但技术可直接武器化。

💼 对系统人的启示
对做终端安全、内核防护（如 LSM hook、ETW 事件源）的工程师是警钟——公开知识 + 闭环 LLM 就能系统化绕过商用 EDR。如果你在维护检测引擎，这篇的测试框架（知识库 + 闭环反馈）值得反向利用来做"自动化红蓝对抗"。

本周亮点：Jovan Stojkovic 和 Chaojie Zhang 以共同作者身份出现在两篇论文中（Agora + AtumAI），均来自 Microsoft，形成了"Agentic AI × 数据中心架构"的持续输出线。IBM Research 在 eBPF 安全方向保持活跃。

AI × Systems 双向渗透加速：本周 6 篇中有 4 篇涉及 AI 与系统的交叉——不是"用系统优化 AI serving"就是"用 AI agent 优化系统策略"。Microsoft 连发两篇（Agora + AtumAI）形成完整闭环：先画像 agentic workload 的架构需求，再用 agentic AI 反过来生成数据中心策略。这标志着"AI for Systems"从零星探索进入系统化阶段。

eBPF 持续扩展安全边界：eMicro 展示了 eBPF 从观测（tracing/monitoring）向主动执行（real-time access control enforcement）的演进——1μs 级策略判定意味着内核态安全执行的性能代价已经可以忽略。预计后续会有更多将 eBPF 用于数据平面安全策略实时执行的工作。