AgentKernel：信任原生的智能体操作系统

TL;DR AgentKernel 把安全做成 agent 的内核层，而非应用层中间件：通过 Identity、Perception、Cognition、Execution 四大强制支柱，让恶意输入无法绕过边界触发危险工具调用。

问题

问题背景

现代 AI agent 已开始在生产中执行复杂任务，跨越多个信任边界：读取不可信网页/邮件，与私有数据结合，调用数据库、shell 等高权限工具。安全成为首要关注。

现有方法局限

当前 governance 栈多为应用层 middleware，与受监控 agent 共享同一进程信任边界，无法提供强制、不可绕过的服务。典型缺陷包括：

• 策略可绕过：安全检查作为外部过滤器，agent 运行时或插件可直接越过。
• 语义攻击失防：prompt injection、记忆投毒、工具误用等攻击发生在语义平面，传统 OS 原语（文件权限、进程隔离）无法映射“不可信输入 → 危险工具调用”的因果链。
• 工具碎片化：identity、perception、memory、execution 控制分散在不同框架/sandbox，缺乏统一内核层，一致性与审计性差。

为什么这个问题难/重要

攻击路径跨越语义平面和系统调用平面，需要在身份、感知、认知、执行四个阶段持续强制，而非单点过滤。生产环境要求不可绕过的安全边界、全生命周期可审计，但现有中间件只能提供事后检测或 best-effort 策略。业界对 agent 安全的关注度随自主性提升而急剧上升，缺少 OS 级信任基已成为规模化部署的关键瓶颈。

行业类比

类似自动驾驶系统将 safety kernel 与应用逻辑分离，AI agent 在处理第三方 PR 或邮件时，也需要内核级强制边界，防止一句 prompt injection 演变为 rm -rf 或数据外泄。

核心洞察

• 将 agent 安全治理从应用层中间件下沉到操作系统内核，构建不可绕过的强制信任边界。现有治理栈与 agent 共享同一进程信任边界，策略可被应用层代码绕过或篡改；AgentKernel 以 OS 原语强制实施身份、感知、认知、执行四支柱，类比微内核的强制访问控制，但针对语义层面的提示注入、委派滥用等失败模式，提供结构性的非旁路保障，而非依赖易被绕过的策略检查。
• 通过格模型实现条目级 taint 传播，在记忆治理中同时提高检索保真度并限制投毒影响。传统方案多采用会话级 taint 或规则过滤，粒度过粗或易被绕过；AgentKernel 将信息流控制精确到单条记忆，引入格结构约束，使低信任来源的数据无法提升信任级别，从架构上阻断了记忆投毒对后续推理和工具调用的污染路径，与仅做输入过滤或输出检测的方法形成本质区别。

方法

输入与总体流程

AgentKernel 将 agent 生命周期内的所有交互（模型输入、工具调用、记忆读写、身份验证）统一纳入内核强制边界。输入包括不受信任内容、特权指令、长期记忆请求和工具调用意图；输出为经内核仲裁后的净化内容、强制策略决策、受控工具执行与可审计身份凭证。

四大支柱模块

• Identity：内核管理身份，TEE 托管密钥，委托作为内核原语，底层提供跨组织可信协作与不可伪造凭证。
• Perception：分层输入中介，由 P1 Source Tagger、P2 Rule-Based Filter、P3 Semantic Firewall、P4 Jailbreak and Multi-Turn Detector 组成，从来源标记到语义检测逐级收紧。
• Cognition：基于格的条目级污点传播（lattice-based entry-level taint propagation），限制记忆投毒，支持跨 agent 受控共享和反注入。
• Execution：E1 Rule/Policy Evaluator、E2 LLM Validator、E3 eBPF/Kernel Hook Manager、E4 Plan-Trace Aligner 等构成执行链，将语义策略转化为内核级强制，支持技能权限清单、工作流编排、调度与并发隔离，并坚持 deterministic-first。

差异点

与现有应用层 governance middleware 不同，AgentKernel 是位于 orchestration framework、runtime、sandbox 之下的 OS 层，提供不可绕过的强制服务，把安全从附加策略变成系统结构。

实验

实验设计

本文未报告传统机器学习实验数据,评测以 架构安全分析 与 系统对比 为主。论文通过四个支柱(Identity / Perception / Cognition / Execution)的威胁模型分析,论证强制边界如何阻断 提示注入 / 记忆投毒 / 工具误用 等攻击。由于没有公开基准测试,无法给出可复现性能指标;重点在于安全不变量与跨支柱组合保证。

关键发现

• 身份由内核绑定 TEE 密钥托管,实现跨组织可信协作。
• 感知采用 分级过滤(源标记 → 规则 → 语义防火墙 → 越狱检测),替代单一过滤点。
• 认知采用格基污点传播,限制记忆投毒。
• 执行采用 语义到内核桥接,在非旁路边界的后方授予更宽工具权限。

与基线对比

与现有 Agent Harness(编排框架 / Runtime / 治理平台 / 沙箱)相比,AgentKernel 不是应用层中间件,而是提供强制隔离边界。结构上实现最低权限,而不是依赖策略配置;污点粒度从会话级提升到条目级。

行业影响

落地场景

AgentKernel 适用于需要高信任保障的多 agent 系统，尤其是那些处理用户生成内容并调用敏感工具的场景。典型 use case：

• 电商智能客服 agent 面对用户消息可能包含 prompt injection，诱导 agent 执行退款、改价等操作。AgentKernel 的 Perception 层语义防火墙和 Execution 层规则/策略评估器可在工具调用前强制拦截，避免越权。
• 金融交易 agent 在跨机构协作时，Identity 层提供 TEE 密钥托管和 kernel 级 delegation，确保只有授权 agent 能发起交易，并记录审计日志。

商业价值

主要降低安全漏洞导致的直接损失（如错误退款、数据泄露）和间接成本（人工审核、安全补丁）。同时，将安全从应用层下移到 OS 层可减少每个 agent 项目重复实现防护逻辑的开发量，缩短上线周期。更高的安全保证让企业更敢于将 agent 接入核心业务流程，提升自动化覆盖率，实现降本增效。

与现有工作流的接口

AgentKernel 定位在编排框架（LangGraph、AutoGen）和 agent runtime 之下，可作为容器内的强制策略执行层。现有 agent 堆栈无需大幅重构：通过 sidecar 或宿主 OS 服务提供非旁路的安全接口，agent 运行时将工具调用、记忆读写等操作委托给 AgentKernel 的对应 pillar。例如，将现有的 execution sandbox 替换为 AgentKernel 的 Execution 层，或在容器中启用其 Identity 和 Perception 服务，即可渐进式集成。

局限

• - **缺乏实现原型与定量评估**：论文主要提供架构设计、安全不变量分析和与相关系统的比较，未报告任何原型实现、性能基准或真实 agent 工作负载下的开销测量。因此无法验证强制边界（如信息流控制、TEE 密钥托管、语义防火墙）对 agent 延迟、吞吐和资源消耗的实际影响；也无法检验其安全机制在多样化 agent 框架中的兼容性和可部署性。这削弱了结论的可信度，后续需要原型验证和基准测试方能确立工程可行性。
• - **对硬件信任根 TEE 的依赖带来限制**：方案将身份密钥托管于 TEE，但 TEE 并非绝对安全，存在侧信道、微架构攻击、供应链风险以及不同硬件厂商的信任模型差异。此外，许多现有 agent 部署环境（如云端多租户、异构设备）可能没有可用 TEE 或不愿引入硬件依赖，导致 AgentKernel 的强制安全属性难以普适落地。论文在威胁模型中假设 TEE 可信，但未深入讨论 TEE 失陷后的降级方案或替代信任根，这限制了方案的适用范围与鲁棒性。
• - **强制 OS 层可能破坏 agent 的灵活性与生态兼容性**：AgentKernel 要求所有输入、记忆和工具调用经过内核强制边界，这可能与现有编排框架（如 LangChain、AutoGen）的即插即用哲学冲突；细粒度信息流控制和会话级污点追踪可能降低检索召回率或限制合法工具调用，增加开发复杂度。论文虽然讨论了集成定位，但缺乏实际迁移案例或开发者体验评估，难以说明其“能力倍增器”断言在工程上成立，实际采纳可能面临较大阻力。