2024年,有个细节很少被人注意到。微软的Agent Governance Toolkit,一个专门给企业做AI智能体治理的产品,在自己的官方文档里写了一句挺诚实的话：我们提供的是"应用层治理,不是操作系统内核级隔离"。
翻译一下这句话的意思：我们的安全防护,和你的AI智能体活在同一个房间里。
这听起来好像没什么大不了。但你想一下,如果一个小偷已经进了你家客厅,而你的保险柜和小偷用的是同一把钥匙,那这个保险柜到底还有什么用?这正是当下几乎所有AI智能体安全方案的真实处境。它们和被保护的对象共享同一个进程、同一个内存空间、同一套权限体系。一旦智能体被攻破，防护系统大概率也跟着一起沦陷。
这篇来自清华大学DeepKernel实验室的论文,提出了一个听起来有点疯狂的想法：AI智能体需要的不是更强的护栏,而是一整套操作系统。
这事儿到底难在哪
先说说现在的AI智能体到底在干什么。
你现在用的Cursor、Claude Code这些编程助手,或者企业里跑的DevOps自动化流水线,本质上都是同一种东西：一个大语言模型,连接着私有代码库、终端命令、网页内容、其他智能体发来的消息,然后根据这些信息做出判断,再去调用各种工具执行动作。
问题是,这些输入来源里,有相当一部分是不可信的。
网页内容可能被人精心设计过,藏着让AI"忘记之前的指令"的文字陷阱。第三方插件可能声称只需要读文件权限,实际却在偷偷联网。长期记忆里存的一条笔记,可能是几个月前被污染进去的,现在正冒充"可信历史信息"影响当下的决策。
论文里给了一个具体场景。假设有个多智能体的DevOps系统,一个协调者智能体把代码审查和部署任务分给两个专门的子智能体去做。这时候有人在Pull Request的评论区里藏了一段间接提示注入的攻击文字。
*间接提示注入：攻击者不直接跟AI对话,而是把恶意指令藏在AI会读取的第三方内容里,比如网页、文件、评论区,让AI在处理这些内容时被"劫持"。*
这段攻击文字会怎么走完它的全程？审查智能体因为没有办法验证"这个任务到底是谁派下来的",没法识别出异常委托;有毒的内容混进了模型的输入上下文,因为没有任何机制把可信指令和不可信内容分开标记;这段被污染的总结被写进了长期记忆,下次检索的时候被当成"可信事实"重新调出来;最后部署智能体基于这条被污染的记忆,把恶意代码真的推上了生产环境。
论文的作者们指出,这四步失败不是四个孤立的漏洞,而是同一条故事线里缺失的四个环节。传统操作系统能防住类似的应用层攻击,靠的是隔离、强制访问控制、来源追踪这些机制永远在线,覆盖每一次资源转移,并且统一由一个仲裁者来强制执行。AI智能体现在完全没有这套东西的对等物。
那当下业界都在做什么呢?论文把现有的解决方案分成四类。编排框架比如LangChain,专注于让智能体的推理链更聪明、工具调用更顺畻,基本不管安全。运行时系统比如AIOS、OpenFang,提供调度和存储管理,安全能力参差不齐。治理平台比如刚才提到的微软AGT,提供策略引擎和审计日志,但和智能体共享同一个进程空间。执行沙箱比如E2B、nono,把代码执行隔离在容器里,但只管执行环节,不管输入怎么进来、记忆怎么被污染。
每一类工具都在做自己那一块拼图,但没有一整块地板能把它们连起来。
这就像什么呢？想象一个写字楼,一楼前台有保安查身份证,五楼办公室门口有指纹锁,顶楼档案室有密码柜,但整栚楼没有统一的门禁系统,任何一层出了问题,其他楼层完全不知道,而且这些安全设施之间互相看不到对方的记录。真正有效的安防,应该是一进大楼刷卡的那一刻,信息就同步给所有楼层,而不是每层楼各管各的一亩三分地。如果不这样统一起来,攻击者只需要找到最薄弱的那一层楼,就能绕开所有其他层的防护,因为各层之间根本不共享风险信息。
四大支柱：给AI智能体建一个"内核"
论文提出的AgentKernel,核心思路是把整个AI智能体的运行过程,用一个强制的、不可绕过的安全边界包起来,这个边界分成四个支柱：身份、感知、认知、执行。
身份：不再是自称的名字,而是加密签发的证件
现在大部分AI智能体系统里,"身份"是什么？就是一个配置文件里写的字符串,或者一个API密钥。这个字符串谁都能改,谁都能伪造,而且它和使用它的智能体本身是同一个东西,一旦智能体被攻破,这个"身份"自然也就被攻破了。
AgentKernel的做法是,把身份变成内核托管的资源,智能体的应用代码根本碰不到。
*Agent Identity Card（AIC）：一种加密签发的智能体身份证,把开发者、代码版本、运营方、部署环境这四个维度绑定在一张不可篡改的凭证里。*
具体是怎么运作的？每个智能体在部署时,会由本地的"Agent Kernel"(智能体内核)生成一对Ed25519加密密钥,私钥永远留在内核里,不会暴露给上层的应用代码。然后内核把这个身份信息提交给一个叫Global Agent Registry（GAR，全球智能体注册中心）的远程可信服务去签名,拿到一张正式的AIC。之后任何需要签名、验证身份的操作,都是内核代劳,智能体本身只能拿到一个"不透明的操作句柄",看不到、也碰不到真正的密钥。
这个设计的关键,在于当多个智能体之间需要委托任务时,子智能体的权限边界永远是父智能体权限边界的子集,而且这个约束是靠密码学签名强制的,不是靠某条可以被篡改的策略配置。撤销父智能体的凭证,会级联撤销整棵委托树,这是结构性保证,不是靠某个管理员记得去手动清理。
这有点像公司里发工牌的逻辑。如果每个员工自己写一张纸条声明"我是财务部经理",那这张纸条毫无价值,谁都能伪造。真正有效的做法是,工牌由人力资源部统一制卡、统一签发,员工本人根本没有制卡权限,想要伪造一张假工牌,你得先攻破人力资源部的整套系统,而不是随便复印一张纸就行。如果不这样做,任何一个被攻陷的员工账号,都能自称是CEO去调用高权限系统,因为身份本身就是自封的。
感知：让攻击在进入AI大脑之前先过几道关
第二个支柱针对的是那些藏在网页、文件、工具返回结果里的注入攻击。
论文设计了一个四层递进的过滤管道,越往后处理成本越高,但也越能抓住更狡猾的攻击。
第一层叫Source Tagger（来源标记器）,给每一条进入系统的内容打上信任等级标签,系统指令最可信,用户输入次之,工具返回的结果算"有条件可信",外部网页内容标为低信任度并加上边界标记。第二层是规则过滤器,用高速的模式匹配拦截"忽略之前的所有指令"这类已知的注入套路,处理速度是毫秒级,不需要调用大模型。第三层是语义防火墙,用一个轻量级模型专门判断内容是否试图操纵智能体的行为,判断标准会根据来源信任度动态调整,对低信任来源的审查更严格。第四层专门盯多轮对话里的越狱攻击,因为有些攻击者不会一次性下手,而是分好几轮慢慢引导AI放松警惕,这一层专门分析整段对话历史,识别这种渐进式的角色重塑。
这个设计的逻辑,类似机场安检。你过安检门的时候,金属探测器先筛一遍(规则过滤),如果响了,安检员再手动检查(语义判断),对于某些高风险航班或旅客,还会有额外的行为观察(多轮追踪)。没有哪一道关卡是万能的,但四道关卡叠在一起,漏网的概率会大幅下降。如果只设一道关卡,比如只装金属探测器,那带塑料炸弹的人根本不会被拦下,单点防御永远存在盲区,而分层防御的意义就是让攻击者必须同时躲过好几种完全不同的检测逻辑。
认知：记忆不再是一个无差别的数据库,而是带标签的信息流
这是我觉得整篇论文里最巧妙的一个设计,叫做基于格结构的条目级污染追踪。
问题是这样的：智能体的长期记忆里可能同时存着一条用户偏好(完全可信、公开)、一封私人邮件(可信但机密)、一段网页摘录(不可信但公开)。传统的信息流控制理论,做法是给整个会话打一个"最坏情况"的标签,只要有一条内容不可信,整个会话就被标记为不可信且机密,结果就是几乎所有记忆都变得没法用了。
*信息流控制：一种源自经典操作系统安全理论的方法,给数据打上"来源"和"敏感度"标签,并在数据被复制、加工、传播时,自动追踪这些标签如何变化。*
AgentKernel的做法是,不给整个会话打一个笼统标签,而是精确到每一条记忆条目。具体流程是：先把对话切成带明确来源的片段,提取出候选记忆条目,然后针对每一条候选条目,反向追溯到底是哪些来源片段真正支撑了这条记忆的成立,再在一个"完整性乘以机密性"的二维格子里,搜索能维持这条记忆有效性的最小安全标签。最后输出的不是单一的最坏标签,而是一组互不可比的最小标签集合。
这就像图书馆的借阅系统。如果图书馆的规则是"只要有一本书逾期未还,你就不能借任何书",那大部分正常读者都会被这条规则误伤,因为大家借的书本来就来自不同渠道、不同状态。更合理的做法是给每一本书单独记录状态,而不是把整个借阅记录打包成一个"好"或"坏"的标签。记忆系统如果不做条目级追踪,后果就是要么把整个系统变成"宁可错杀不可放过"的废物,要么干脆放弃追踪,任由污染的内容悄悄渗透进后续的每一次决策。
这个机制还依赖一个前提,就是"来源切分"必须准确。如果攻击者刻意设计内容,故意模糊不同来源之间的边界,那这套算法可能会低估真实的污染程度。论文自己也承认了这一点,把它列为一个尚未完全解决的开放问题。
执行：从"意图"到"系统调用"之间,不能有断层
第四个支柱解决的是一个特别现实的问题：就算前面三关都过了,一个恶意的工具实现,依然可以在运行时干出超出它声明范围的事情,比如偷偷派生子进程、访问没被授权的文件、连接一个数据外泄的服务器。
*eBPF：一种可以在操作系统内核层面动态安装监控和过滤逻辑的技术,原本用于网络和性能监控,这里被用来在工具执行前动态设置权限白名单。*
论文设计了四层执行治理。第一层是快速规则检查,把工具的权限清单和智能体的身份权限边界做交叉核对,毫秒级完成,不涉及大模型。第二层是留给高风险、高模糊度决策的大模型验证,判断这个动作是否真的符合用户原本的意图,必要时触发人工确认。第三层是整篇论文里最有特色的设计，一个特权守护进程,在工具真正开始执行之前,先算出这次调用允许访问哪些文件路径、哪些网络端点,把这份清单编译成eBPF内核探针,装进操作系统层面,然后监控这个工具派生出的整棵进程树,一旦有子进程试图突破清单范围,立刻暂停并处理。第四层是事后的计划与实际执行轨迹对齐,把大模型声称做过的动作和真实发生的系统调用记录做比对,专门用来揭穿"幻觉行为",也就是大模型嘴上说自己完成了某个操作,但系统日志里根本没有这回事。
这四层里最关键的是第三层,因为它解决了一个纯语义层防护永远解决不了的问题：语义层的检查只能看工具声称要做什么,却完全信任工具的具体实现,一旦这个工具本身就是恶意的,声明和行为完全可以是两回事。而纯系统调用层面的检查又完全看不懂"为什么"要执行这个操作,一次文件写入,不管背后驱动它的是正常的逻辑推理,还是一条被污染的记忆条目,在操作系统看来长得完全一样。
这好比给一个临时工发放门禁卡。如果只靠这个人自己填写的工作说明书来决定放行权限,那他完全可以写"只需要打印室权限",实际却在申请服务器机房的门禁。而如果只靠门禁系统死板地按卡片类型放行,系统压根不知道这个人今天到底该不该进服务器机房,因为门禁卡本身不会告诉你"意图"。真正靠得住的做法,是先根据这个人今天的具体任务算出一份动态的、仅限当天有效的权限清单,再把这份清单实时刷进门禁系统,而且他带的任何跟班(子进程)都必须遵守同一份清单。如果不这样做,你要么被卷入"信任声明就完了"的陷阱,要么陷入"系统看不懂意图"的盲区,这两种失败模式在AI智能体的世界里都真实发生过。
安全和能力,原来不是一道单选题
论文里有一个我觉得特别值得展开说的观点,叫"结构性安全是能力的放大器"。
一般人的直觉是,安全措施越严,系统能做的事就越少。你给一个系统上锁,它自然就不能自由行动了。但论文提出了一个反直觉的推理链条：如果一套安全机制是不可绕过的,那么运营方要回答的问题,就从"这个智能体值得信任吗"变成了"这个机制能不能防止智能体越权",而后者是一个关于机制本身正确性的问题,比前者好回答得多。
这在实际场景里体现得非常具体。
没有加密验证的身份系统时,跨组织的智能体协作基本没法搞,因为你根本没法验证对方到底是谁、授权到什么程度,大家只能退回到人工审批,或者干脆不合作。有了身份内核之后,不同公司的智能体之间可以做双向的相互认证,发一个生命周期极短的会话令牌,过期自动失效,这就打开了跨组织协作的大门。
没有分级感知过滤的时候,运营方出于谨慎,只能选择让智能体少接触网页、少处理多模态内容,或者每一步都要人工审核,这直接限制了自动化的效率上限。有了四层感知管道之后,输入源可以更丰富,系统仍能保持基本的安全底线。
没有污染追踪的记忆系统,存储越久污染的概率越高,运营方最后只能选择限制记忆的使用范围,或者做昂贵的手动审计。有了条目级污染标签之后,检索时可以优先呈现高置信度的条目,污染条目会带着明确的警告,记忆反而从一个风险源变成了可以放心依赖的资产。
没有语义到系统调用的桥接机制之前,应用层的护栏只能检查参数,管不住工具的真实执行行为,运营方只能把工具集限制得非常窄。有了这套桥接机制之后,运营方可以放心地扩大工具授权范围,因为无论工具内部藏着什么,它都跑不出内核动态算出来的白名单。
所以这套架构的核心逻辑是,安全不是拿能力去交换的东西,安全就是能力扩张的机制本身。每一处更强的约束,都直接对应着一处此前被谨慎限制住的能力空间被打开。
这些工具都在做什么,又漏了什么
论文花了相当篇幅去梳理现有的智能体基础设施生态,分成四层：编排框架、运行时系统、治理平台、执行沙箱。
编排框架比如LangChain、AutoGen、CrewAI,核心目标是让智能体的推理链更聪明、多智能体协作更顺畻,安全能力从缺失到可选插件不等。运行时系统这一层最有意思,几个项目都借用了"内核""调度""内存管理"这些操作系统术语,但实际做法差异很大。
AIOS的所谓"内核"其实是一个跑在本地的HTTP服务器,和智能体本质上共享同一个Python进程地址空间,访问控制只是一个空壳的权限管理器,没有加密身份、没有污染标签。OpenFang在这几个运行时里做得最完整,支持WASM沙箱、Ed25519签名的智能体清单、Merkle审计链、信息流污染标签,但这些能力只对内核直接托管的智能体有效,一旦智能体是通过外部协议连接进来的,这些保护就管不到它了。SmythOS走的是纯Node.js库的路子,和主机应用共享同一个进程,访问控制装饰器理论上可以被任何能碰到底层连接对象的代码绕过。Letta专注于记忆管理,做得很扎实,但记忆条目本身没有任何信息流约束。
治理平台这一层,微软的AGT是目前业界最全面的方案,它的策略引擎、SPIFFE身份组件、执行熔断机制加在一起构成了一套相当成熟的治理体系。但AGT自己在文档里承认,它的策略引擎是以应用层库的形式跑在和智能体同一个进程里的,这意味着任何能碰到解释器的代码,理论上都能修改策略状态、绕过检查钩子。
执行沙箱比如nono、E2B,提供的是相对纯粹的进程或容器隔离,做得也不错,但它们管的是"隔离",不管输入怎么被污染、记忆怎么被追踪。
论文用一张对比表格,横向比较了AgentKernel和这六个代表性系统在十五个维度上的差异。看这张表你会发现一个规律,几乎所有现有系统都是"在某一个或某几个支柱上做得不错,但从来没有一个系统同时把身份、感知、认知、执行四个环节用统一的溯源标签串起来"。这正是AgentKernel想要填的那个空白。
这套架构也有它没解决的问题
论文很坦诚地列出了几处尚未完全解决的风险。
来源切分的准确性问题前面提到过,如果攻击者故意设计内容去模糊边界,污染标签可能会失真。语义防火墙本身是一个基于大模型的分类器,天然存在假阳性和假阴性的取舍,懂得分类器决策边界的攻击者理论上能找到盲区。GAR作为全局身份的信任根,一旦签名密钥被攻破,整个身份体系会连带崩塌,论文提到跨GAR联邦是未来的解法,但这本身又引入了新的信任协商问题。整套架构的安全论证,建立在一个前提上，智能体和它的应用代码，绝对不能保留绕过三个适配器接口的直接访问路径,这个前提在实际部署中是一个操作层面的责任,不是理论上能自动保证的。eBPF这套机制原生只支持Linux,在macOS和Windows上的可移植性还是个问题。而且论文里给出的那些安全不变式,目前都是"架构层面保证",还没有经过Coq、TLA+这类工具做机械化的形式验证。
这些坦白说都是很实在的短板,但恰恰是这些坦白,让整篇论文的可信度更高,因为它没有假装自己已经把所有问题都解决了。
写在后面
读完这篇论文,我印象最深的其实不是那四个支柱的具体设计,而是"身份不能自封"这个看似简单的判断背后隐藏的东西。
现在几乎所有关于AI安全的讨论,都聚焦在"怎么让模型更听话""怎么设计更好的提示词护栏"上,这些讨论有一个隐含的假设,就是把模型本身当成需要被说服、被引导的对象。但AgentKernel的架构选择了一个完全不同的立场，把整个智能体，包括它的推理循环、它的应用逻辑，直接归类为"不可信的计算基质",安全边界画在智能体外面,而不是想办法在智能体内部塞进更多的安全指令。
这个立场转变挺值得琢磨的。它意味着你不再问"这个AI会不会做坏事",而是问"如果这个AI一定会在某个时刻做坏事,我的系统会不会因此崩掉"。这是一种悲观但更诚实的设计哲学,类似操作系统对用户进程从来不抱任何"它会自觉遵守规则"的幻想,而是靠硬边界把它框死。
另一个让我反复想的细节,是那个"条目级污染追踪"的设计。论文特意强调,如果用最保守的方式,给整个会话打一个笼统的污染标签,系统会变得几乎没法用,这个观察背后其实是一个更普遍的教训：任何安全机制如果做得太粗糙,最终的代价不是被攻破,而是被用户绕开,因为没人愿意用一个把90%正常操作都拦下来的系统。真正难的从来不是"设计一个绝对安全的系统",而是"设计一个既够安全、又不会把自己逼成废物的系统"。这条平衡线,可能比论文里任何一个具体的加密协议都更难画。
Q&A
Q1：AgentKernel是什么?
A：AgentKernel是清华大学DeepKernel实验室提出的首个"信任原生"AI智能体操作系统,它把身份、感知、认知、执行四个环节用统一的安全内核包起来,让智能体的每一次输入、记忆存取、工具调用都必须经过强制、不可绕过的审查,而不是像现在大多数安全方案那样和智能体共享同一个进程空间。
Q2：AgentKernel和现有的AI智能体安全工具有什么区别?
A：区别在于是否强制、是否不可绕过。现有的治理平台、运行时系统大多以应用层库的形式和智能体共享同一个进程,理论上可以被绕过;AgentKernel把安全逻辑放进独立的内核,智能体只能通过三个受限的适配器接口访问模型、工具和存储,没有其他路径可走。
Q3：AgentKernel真的能让AI智能体既更安全又更强大吗?
A：论文的核心论点是安全和能力不是对立的。因为不可绕过的边界让运营方能够放心扩大授权范围,比如跨组织协作、更丰富的输入源、更长期的记忆使用,这些原本因为怕不安全而被限制的能力,反而因为有了可信的机制保证而被释放出来。
