像保护操作系统一样保护 AI 智能体:CISPA 给出的设计蓝图

What is this?

2026 年 5 月 14 日,Lukas Pirch 与来自 CISPA 亥姆霍兹中心和柏林工业大学的六位合著者(包括 Thorsten Holz 与 Konrad Rieck)在 arXiv 上发表了 Toward Securing AI Agents Like Operating Systems(2605.14932,cs.CR,CC-BY 4.0 许可证)。这篇论文并未宣告一类新的攻击手法,而是为系统构建者提供了一件更有用的工具:它论证了 LLM 智能体正在重新发明操作系统在 1970 年代就已经解决过的安全问题,而同一套工具——进程隔离、特权分离、通信中介——正是现实可行的出路。

作者们用一项动手实验为这个类比背书。他们构建了一个覆盖主流开源智能体技术栈的统一架构,把攻击面映射到该架构之上,并对四个被广泛部署的 OpenClaw 类智能体应用同一套威胁模型。核心结果令人警醒:在攻击者能力相当有限的前提下,有两类弱点——跨用户数据外泄与未授权出网——在所测的全部智能体上都被攻破。

How it works

论文将一个智能体拆为四个相互连接的部分:规划核心(LLM 本身)、工具层(技能、MCP 服务器、浏览器、Shell)、记忆层(短期上下文与长期存储)以及会话边界(每用户状态)。每一部分都对应到操作系统文献中已经成熟的概念。

Operating system              LLM agent
-----------------             -----------------
Process                  ≈    Session
Process isolation        ≈    Per-user state separation
User vs. kernel          ≈    Trusted plan vs. untrusted tool output
Capabilities / syscalls  ≈    Tool-call ACLs
File system permissions  ≈    Memory + RAG read/write policies
Network namespace        ≈    Egress policy for the agent process
IPC mediation            ≈    Inter-agent / inter-skill communication

在这张映射图之上,论文列出了在所测系统中无一幸免的两类弱点:

• PI-1 — 跨用户数据外泄。 当多个会话共享同一份后端记忆存储、工具缓存或技能索引时,一名用户的内容(文档、对话历史、此前粘贴的密钥)可能被另一个用户的会话取回,有时只需一次精心构造的请求。其操作系统对应物正是缺失”按用户隔离的进程”:所有会话都从同一个地址空间读取。
• NF-1 — 未授权的消息外发。 即便那些自称”仅回复”的智能体,也常常会主动外联:开发者以为已经被沙箱限制的 HTTP 请求、转发到上游服务的 MCP 服务器、偷偷发送邮件或贴文的技能。智能体进程之上并没有出网防火墙,只要工具层能发起任意一条出站请求,外泄通道就会迅速扩散。

论文用可复现的实验环境记录了上述两类弱点,但出于负责任披露的考虑,并未发布可直接利用的攻击载荷。论文的论点是结构性的、而非个案的:即便在”攻击者能力相当有限”的设定下(单一用户账号、单一上传文档、单一已安装技能),两条安全边界都会被突破。

这项研究与本季度其他几项成果互相印证。微软安全团队在 2026 年 5 月 7 日发布的关于 AI 智能体框架 RCE 漏洞的公告 指出,一旦运行时混淆了”规划”与”执行”的特权,提示词就会退化为可执行的 Shell。2026 年 4 月 14 日发布的 OWASP GenAI Exploit Round-up Q1 2026 在事件层面看到了同样的模式:故障不再仅来自模型输出,而是来自身份、编排层与供应链。CISPA 这篇论文,正是这些事件报告所缺少的那种”系统安全”框架。

Why it matters

有三点超出了本篇论文本身。

第一,问题在架构层,而不在行为层。PI-1 与 NF-1 不会被更强的安全分类器、更严格的系统提示或更精细的越狱过滤器解决。一个完全按指令行事的模型,只要会话共享后端,就仍会在用户之间发生泄漏;只要工具层能解析外部主机名,就仍会”打电话回家”。把防御止步于模型输出层,等于打错了靶子。

第二,操作系统的既有文献在这里异常慷慨。进程隔离、capability(如 Capsicum、seL4)、强制访问控制(SELinux、AppArmor)、网络命名空间、IPC 中介——这些并非纸面研究,而是经过三十年审计与部署的工程实践。论文给出的建议并不是要智能体团队发明新原语,而是请他们使用已经存在的那些。

第三,MCP 类生态会放大爆炸半径。共享的技能注册中心、多租户的记忆存储、被赋予广泛权限的 MCP 服务器:这些架构的价值恰恰来自”状态共享”,而共享状态本身也成了攻击面。这一观察与 CISA 发布的 Careful Adoption of Agentic AI Services 中的整体趋势一致——智能体的采购与设计选择已经是头等的安全决策。

Defenses

论文的建议可以直接落地为今天就能实施的控制项。

1. 将每个会话运行在独立的进程或容器里。 不要存在共享可写的文件系统路径,不要共享记忆存储,也不要让同一缓存中混合不同用户的内容。在操作系统层面给出的隔离保证,才是真正阻断 PI-1 的那条线;之上的所有努力都只是尽力而为。
2. 对智能体进程默认禁止任何出网。 显式列出智能体合法需要访问的有限主机集合(模型网关、工具后端等),将其他所有 DNS 查询或 HTTP 请求都视为违反策略:记录下来,并在响应回到模型之前切断这条流。配合一道真正的出口防火墙,NF-1 就会消失。
3. 始终把工具输出当作不可信输入。 用对待用户表单数据的同样力度来对待:工具返回值可能携带指令、链接或编码后的载荷,规划用 LLM 在采取任何修改状态的动作之前,必须经过带外确认。
4. 用 capability 限制每一次工具调用。 “列文件”工具不应顺带读取任意路径,“取 URL”工具不应顺带发 POST。每个工具对应自己的 ACL、每个会话对应自己的 token scope、所有技能默认遵循最小权限——这三件事就能堵住论文中绝大多数横向移动路径。
5. 对智能体之间、技能之间的通信进行中介。 将 A → B 的智能体调用和”技能链 → 技能链”视为 IPC:经过 schema 校验、限速、记录、可撤销。论文将其定位为操作系统 IPC 中介在智能体世界的对应物;同时,这也正是上面 微软 RCE 报告 中提到的最容易被利用的提权面。
6. 对自家智能体做一次”四层审计”。 论文 §3 的统一架构是一份好用的模板:依次走过规划层、工具层、记忆层与会话边界层,为每一层确认它是否拥有明确负责人、书面的策略,以及一项真正能强制执行该策略的控制。任何留作隐含约定的部分,都将成为下一次事故复盘的开端。

Status

项目	来源	日期	备注
论文发布	arXiv:2605.14932v1	2026-05-14	cs.CR,17 页,CC-BY 4.0
所属机构	CISPA 亥姆霍兹中心、柏林工业大学	2026-05-14	Holz 与 Rieck 团队
评测系统	4 个 OpenClaw 类智能体	2026-05-14	厂商在论文中匿名化
普遍失守的两类弱点	PI-1(跨用户外泄)、NF-1(未授权出网)	2026-05-14	所测系统 100% 命中
同期相关公告	微软 “Prompts become shells”	2026-05-07	AI 智能体框架中的 RCE
同期事件汇编	OWASP GenAI Exploit Round-up Q1 2026	2026-04-14	身份、编排、供应链
同期政策指引	CISA Careful Adoption of Agentic AI Services	2026	从采购侧入手的控制

没有任何单一措施能彻底消除 PI-1 或 NF-1。CISPA 这篇论文真正的贡献,是给出一个明确的名字——我们正在运行多用户系统,却没有装上多用户系统所需要的隔离原语——并把那一整架经过岁月打磨的工具摆在面前。在作者的框架里,2026 年还把威胁模型停留在 prompt-injection 扫描器与输出过滤器上的智能体部署,等同于一台没有进程隔离的操作系统:也许它对模型行为本身的假设还谈不上错,但在系统设计上,它已经错了。