AegisKernel 发布：Agent 安全开始下沉，但还没真正进入内核

AegisKernel 近日公开了一个面向 AI Agent 的零信任安全运行时，试图在模型生成工具参数之后、操作系统执行动作之前，拦截文件写入、Shell 命令和数据库修改等高风险操作。项目采用 MIT 许可证，支持 Python 3.9 及以上版本，并提供 CrewAI、LangChain 等框架的工具包装接口。

它最吸引眼球的数据是延迟：项目给出的四组拦截结果分别为 0.061 毫秒、0.041 毫秒、0.022 毫秒和 0.016 毫秒。换句话说，最快一次策略判断只花了 16 微秒，远低于一次模型推理、网络请求甚至普通数据库查询的耗时。

但在看完代码后，我们的判断是：**AegisKernel 提出的问题是对的，工程方向也值得关注，但“POSIX 运行时”“系统调用边界”和“100% 免疫”这些表述，明显跑在当前实现前面。**截至 2026 年 11 月 6 日，它更准确的定位是一个 Python 进程内的 Agent 工具调用防火墙，而不是已经进入操作系统内核的安全边界。(github.com)

它要解决的不是“模型说错话”，而是“模型真的动手了”

**AI Agent 是能够根据目标自主规划步骤、调用工具并改变外部系统状态的软件实体。**它与聊天机器人的关键区别，不是回复更长或者推理更强，而是它可能拥有终端、文件系统、数据库、浏览器和云服务权限。

这也改变了提示注入的风险性质。

普通聊天机器人被提示注入，最坏结果通常是输出错误信息；一个连接 Shell 的 Agent 被提示注入，可能读取 .env 文件、上传 SSH 私钥、执行破坏性命令，或者把网页中的隐藏文本当成系统指令。

传统的 Agent 防护经常依赖另一层模型判断：“这个工具调用安全吗？”问题在于，模型判断本身仍然是概率性的。攻击者可以使用编码、上下文混淆、角色扮演、间接指令和参数拼接，让安全模型漏判。

**零信任是默认不相信任何身份、输入和执行请求，并在每次访问资源时重新验证权限的安全原则。**在 Agent 场景下，这意味着即使模型已经通过身份认证、即使请求来自可信工作流，也不能默认允许它执行任意命令。

AegisKernel 的核心思路因此不是继续改提示词，而是在工具执行边界增加确定性规则：模型可以自由推理，但真正产生副作用之前，必须先通过能力权限和输入来源检查。

这个方向是合理的。模型负责理解模糊目标，安全系统负责执行不可模糊的规则，两者不应该由同一个概率模型同时承担。

四个模块：污点、权限、拦截和审计

**污点追踪是为不可信数据附加来源标签，并让标签随着数据处理过程继续传播的技术。**AegisKernel 定义了一个继承自 Python str 的 TaintedString 类型，用来标记来自用户、网页、邮件或外部文档的数据。

当污点字符串被切片、拼接、转换大小写、替换或拆分时，新字符串会继续携带原始 taint_id。这样做的目标是避免恶意指令经过几次字符串操作后“洗白”，让执行层仍然知道参数来自不可信输入。(raw.githubusercontent.com)

**能力权限控制是把系统操作拆成明确权限，并要求工具在执行前获得对应授权的机制。**AegisKernel 当前定义了六类能力：

• FILE_READ：读取文件
• FILE_WRITE：写入文件
• SHELL_EXEC：执行 Shell 命令
• NETWORK_OUTBOUND：访问外部网络
• DATABASE_MODIFY：修改数据库
• ENVIRONMENT_ACCESS：访问环境变量

严格策略默认只开放文件读取，其余能力必须显式授权。对于 Shell、文件写入和数据库修改等危险能力，如果参数带有污点，并命中 .env、password、id_rsa、drop table、rm -rf、curl 等敏感模式，策略引擎会抛出异常并终止调用。(raw.githubusercontent.com)

拦截器则通过 Python 装饰器包装工具函数。Agent 调用工具时，拦截器先把参数转成字符串，再进行能力检查和敏感模式匹配；允许的请求进入原函数，拒绝的请求写入审计记录。

这套设计的优点是接入成本低。开发者不需要修改模型，也不需要重新训练安全分类器，只要把已有工具函数包装起来，就能获得一个基础的默认拒绝层。

0.016 毫秒很快，但“100% 防御”需要打折看

AegisKernel 给出的 CrewAI 测试结果覆盖了四种攻击：

| 攻击类型 | 未保护的 CrewAI | AegisKernel | 项目报告延迟 | |---|---:|---:|---:| | 破坏性根目录命令 | 被利用 | 已阻断 | 0.061 ms | | 路径穿越与 .env 泄露 | 被利用 | 已阻断 | 0.041 ms | | 数据库删除注入 | 被利用 | 已阻断 | 0.022 ms | | 命令链劫持 | 被利用 | 已阻断 | 0.016 ms |

**这些数字证明规则匹配本身非常便宜，但不能证明系统能够抵御所有提示注入。**项目的基准测试主要是预设攻击字符串与预设敏感词之间的匹配，而不是在真实模型、真实工具、复杂编码和操作系统隔离环境中进行的独立红队测试。

仓库中的基础 benchmark 甚至直接把所有标记为恶意的未保护请求判定为“被攻破”，再检查目标字符串是否包含固定关键词。这样的测试适合验证演示流程，却不足以支持“100% 免疫”这一安全结论。(github.com)

更关键的是，当前拦截器中存在一行值得注意的逻辑：污点检测结果后面连接了一个恒为真的条件。这意味着在没有显式传入状态时，所有输入都会被当作已污染数据处理。

这能提高默认拒绝强度，却削弱了“精确追踪输入来源”的意义。系统目前更像“默认把所有工具参数视为不可信”，而不是完整追踪数据从网页进入模型、经过推理和结构化输出、最终抵达系统调用的全过程。

严格模式下只授予 FILE_READ 也会带来另一个测试偏差：如果包装器要求的是 SHELL_EXEC，而策略根本没有授予该能力，那么无论参数是否恶意，请求都会被拒绝。阻断率可以达到 100%，但正常任务的可用率可能同时降到 0%。

真正有意义的安全基准必须同时报告至少四个指标：攻击阻断率、正常请求放行率、误报率和绕过率。只报告“恶意样本全部被挡住”，很容易得到一个安全但无法工作的系统。

名字叫 Kernel，实际仍在 Python 工具层

**POSIX 运行时是为进程、文件、权限、信号和系统调用提供统一执行语义的底层环境。**如果一个产品声称在 POSIX 或系统调用边界实施安全控制，开发者通常会预期看到 seccomp、Linux Security Modules、Landlock、eBPF、命名空间，或者至少是独立代理进程对系统调用进行强制拦截。

AegisKernel 当前没有做到这一层。

它的核心拦截逻辑是 Python 的函数装饰器，保护范围取决于开发者是否主动包装了工具函数。如果 Agent 能够调用一个未包装的工具、直接创建子进程，或者通过第三方库访问文件和网络，这层策略就可能被绕开。

这与真正的内核强制执行有本质区别：

| 方案 | 当前执行边界 | 是否依赖应用主动接入 | 隔离强度 | 主要代价 | |---|---|---:|---|---| | AegisKernel | Python 工具函数包装层 | 是 | 较低 | 接入简单、延迟低 | | Kernex | Landlock LSM 与 seccomp BPF | 否，包装进程启动 | 较高 | Linux 能力与策略配置更复杂 | | AegisVM | 独立 microVM 内核 | 否 | 高 | 启动、内存和运维成本更高 | | 容器沙箱 | Namespace、cgroup、seccomp 等 | 部分 | 中到较高 | 配置错误可能削弱隔离 |

Kernex 的路线是在 Linux 上通过 Landlock 和 seccomp BPF 对文件与系统调用实施约束；AegisVM 则为 Agent 提供独立 microVM，让工作负载不与宿主机共享内核。与它们相比，AegisKernel 更轻，也更容易嵌入 Python Agent，但不能提供同等级别的不可绕过保证。

因此，“Kernel”目前更像产品愿景，而不是技术事实。

审计日志也还没有达到“防篡改”

**防篡改审计日志是能够证明记录未被删除、插入或修改的事件链。**常见做法包括 HMAC、数字签名、哈希链、可信时间戳或写入不可变存储。

AegisKernel 的 README 将审计能力描述为 SHA-256 HMAC 日志，但当前代码实际使用的是普通 SHA-256：它把时间、工具名称、状态、延迟和参数预览拼接后计算哈希，再截取前 16 个十六进制字符。

这里没有看到 HMAC 密钥，也没有前后记录之间的哈希链。任何能够修改日志内容的人，都可以重新计算对应哈希。因此它现在更接近“带摘要的事件记录”，不能严格称为密码学防篡改日志。(raw.githubusercontent.com)

版本信息也存在不一致：项目主页显示 v0.6.0，而 Python 包配置仍然标记为 0.2.0。对于刚公开的早期项目，这不算严重问题，但生产安全工具必须建立可追踪的版本、发布包、变更日志和安全响应流程。(adikshatriyag-crypto.github.io)

它真正有价值的地方，是把安全判断放到动作边界

AegisKernel 当前最值得肯定的并不是跑分，而是它明确区分了“模型推理”和“系统授权”。

模型可以建议执行 rm、访问数据库或上传文件，但建议不等于权限。真正的生产级 Agent 平台需要在模型之外维护独立策略，并让执行系统拥有最终否决权。

对于开发者，AegisKernel 现在比较适合三个场景：

1. **验证 Agent 工具权限设计。**开发团队可以先用它梳理哪些工具需要文件、网络、数据库和环境变量权限。
2. **为演示或内部原型增加基础防线。**固定敏感词和默认拒绝策略，至少能阻止一部分明显危险命令。
3. **测试零信任 Agent 的开发体验。**它展示了如何在不修改模型的情况下，把策略检查插入工具调用路径。

它暂时不适合单独承担生产环境安全边界。更稳妥的组合应该是：AegisKernel 一类工具层策略负责理解 Agent 动作语义，Landlock、seccomp、容器或 microVM 负责提供不可绕过的系统隔离，网络出口策略限制数据外传，短期凭证控制身份权限，高风险操作再加入人工确认。

这几层的关系类似机场安检：工具层策略负责检查旅客申报了什么，操作系统沙箱负责确保他实际上只能进入被允许的区域。只做前者，仍然要相信应用没有漏掉任何入口。

OpenAI Hub 观点：方向正确，宣传需要降温

AegisKernel 抓住了 Agent 产品正在面对的真实矛盾：模型越能自主完成任务，就越不能把安全寄托在模型“自觉遵守规则”上。

但安全基础设施最忌讳过度承诺。16 微秒的字符串与权限检查值得关注，却不能直接等同于 16 微秒的内核系统调用防御；四类预设攻击全部被拦截，也不能推出对提示注入“100% 免疫”。

如果后续版本能够加入真正的进程级强制执行、完整的数据来源追踪、结构化参数策略、网络出口控制、不可变审计链，以及由第三方维护的绕过测试集，AegisKernel 才可能从一个有想法的 Python 原型，成长为可靠的 Agent 安全运行时。

现阶段最准确的评价是：它不是 Agent 安全问题的最终答案，但它把防线放在了比提示词更正确的位置。

参考来源

• AegisKernel GitHub 仓库：项目说明、许可证、目录结构及官方基准结果。
• AegisKernel 拦截器实现：工具函数包装、污点判断和策略调用逻辑。
• AegisKernel 污点追踪实现：TaintedString 的传播机制。
• AegisKernel 权限策略实现：能力矩阵、严格模式和敏感模式列表。
• AegisKernel 审计日志实现：SHA-256 摘要与事件记录代码。
• Kernex GitHub 仓库：基于 Landlock LSM 与 seccomp BPF 的 Agent 进程隔离方案。
• AegisVM GitHub 仓库：使用独立 microVM 运行 Agent 工作负载的隔离方案。