Agent libOS:把权限边界放在运行时,而非工具包装层

在当下大多数智能体技术栈中,“模型能看到 write_file 工具”这件事,与”运行时拥有写磁盘的权限”这件事,被当成了同一件事。2026 年 6 月 2 日的论文 Agent libOS(arXiv:2606.03895,cs.OS)认为,正是这种混淆,导致包装层级别的安全措施屡屡失效;论文进而勾勒出一种把二者刻意分离的运行时。

这是什么?

Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents 由 Yingqi Zhang 于 2026 年 6 月 2 日发布到 arXiv。它既不是新攻击,也不是新模型,而是一种运行时设计:一个受 library-OS 启发的底层,位于常规宿主操作系统之上,把每个智能体视为一个 AgentProcess——一个可调度的主体,具备进程身份、父子谱系、生命周期、显式能力、带类型的对象内存、人工审批队列、检查点与审计记录。

论文的核心规则只有一句话:工具是类 libc 的包装,运行时原语才是权限边界。 换言之,暴露给模型的工具 schema 只是一层便利接口,如同对 C 标准库的调用。底层操作究竟能否触及某个文件、对象、时钟、人工审批者或工具注册表,要在下一层、在原语处、依据显式的能力与策略来决定。

工作原理

Agent libOS 把传统工具注册表悄悄合并的三个决策拆开。可见性——进程能否看到该工具 schema——由进程私有的工具表管理。调用——进程能否提交该调用——由一个 broker 校验。权限——由此产生的操作能否触及受保护资源——由原语管理器依据能力与策略校验。由此得到的不变式很直白:工具可见并不意味着拥有资源权限。 一个进程可以看到 write_text_file,却对任何路径都不持有写权限。

这一操作系统类比一直延伸到生命周期操作。spawn 创建的子进程拥有自己的命名空间,以及仅含目标的内存视图,而非父进程对话记录的副本。fork 会削减子进程的内存视图与预算,在原型中,除非显式授予,否则不继承父进程的文件写权限。exec 替换智能体的镜像与工具表,但保留进程标识,且不会自动授予新镜像所需的能力,因此无法提权。对象内存遵循 object-capability 传统:知道某个已存对象的名字,并不能在缺乏相应能力的情况下读取它。这些都不是模型层面可微分的行为,而是确定性执行的”管道工程”。

作者对适用范围说得很清楚。原型是一个 Python 底层,具备异步调度、命名空间局部的对象内存、运行时集成的人工审批、一次性权限授予、置于系统调用 broker 之后的即时生成 Deno/TypeScript 工具,以及一套涵盖隔离、撤销、fork/exec 权限削减与”包装纯净性”的 123 项回归测试。它不是内核级隔离,不是形式化验证,也不是在任务基准上得分更高的规划器。

为何重要

威胁模型这部分值得读两遍。Agent libOS 精准瞄准了该领域反复重新发现的失效模式:诱导高风险工具的提示注入、改变后续决策的工具输出注入、越出工作区的路径逃逸、经由 fork 的能力泄漏、导入危险 API 的生成工具,以及”把工具表成员身份与外部资源权限混为一谈”。最后一点,正是把致命三要素与混淆代理(confused deputy)问题表述为系统缺陷,而非模型缺陷。

关键在于,论文并不声称解决了语义层面的提示注入。一份恶意文档——正是 Greshake 等人在 2023 年首次系统化的那类——仍可能说服模型请求某个危险动作。其主张更窄也更诚实:即便如此,该请求仍会在原语边界处撞上能力检查、策略、必要时的人工审批以及审计记录。容器与 microVM 保护的是宿主免受不可信代码侵害,但正如论文所言,它们本身并不决定沙箱内的某个动作是代表哪位用户、是否被授权。这正是 Agent libOS 试图填补的空隙,也是 AgentDojo 等基准一再显示包装层防御被穿透的那道空隙。

防御

该设计可当作一份清单使用,无需采用其原型。

1. 别再把工具注册表当成访问控制列表。 把”模型能看到这个工具”与”这个操作被授权”分开。如果你唯一的边界是一个直接调用宿主的包装,那么一条到达规划器的注入指令就到达了宿主。
2. 把策略检查放在原语,而非提示。 文件、网络、shell、时钟、对象与工具注册等操作,都应各自经过一个在行动前查询显式能力的管理器——就放在你做审计的同一处,而不是包在函数外面的确认对话框。
3. 在 fork、spawn 与工具生成时削减权限。 子进程或即时生成的工具应以更少的权限起步,绝不默认继承父进程的环境权限。这是智能体版的”放弃特权”。
4. 让名字不等于能力。 发现与权限是两回事:知道某个对象、路径或工具存在,不应授予使用它的权利。
5. 把人工审批与审计做成一等、可恢复的操作。 审批应是调度器可恢复的阻塞原语,而非贴在某个 demo 上的回调;每一次授予、拒绝与副作用都应留下记录,说明是哪一项权限放行了它。这与把工具输出视为不可信以及对改状态调用施加原子性控制天然契合。

状态

项目	参考	日期	备注
论文发布	arXiv:2606.03895v1	2026-06-02	cs.OS,CC-BY 4.0,单一作者(Yingqi Zhang)
工件	Python 原型	2026-06-02	异步调度器、对象内存、syscall broker、JIT 工具
评测	123 项回归测试	2026-06-02	隔离、撤销、fork/exec 权限削减、包装纯净性
设计规则	工具 = libc;原语 = 权限边界	2026-06-02	可见性 ≠ 调用 ≠ 权限
明确的非目标	语义提示注入	2026-06-02	运行时控制的是后果,而非欺骗本身
渊源	间接提示注入(Greshake 等人)	2023-02	为何包装层级别的安全措施不足

Agent libOS 不会阻止模型被骗。它提供的,是当模型确实被骗时的一个立足点:在这样的运行时里,危险的请求仍须越过一项它从未被授予的能力。对于 2026 年部署长时运行、手握工具的智能体的团队而言,论文最有用的贡献是一套词汇——可见性、调用、权限——让人得以察觉:如今的框架,通常把这三者塌缩成了一个。