AI Agent在企业裸奔半年后,Red Hat用周末做了个容器笼子

你的公司可能已经跑着AI Agent了——但你知道它有多危险吗？

上周，Red Hat发布了一款叫Tank OS的开源工具，做的事情看似简单：把AI Agent关进容器。但如果你了解过去半年AI Agent安全领域的惊心动魄，就会明白这件事为什么值得上头条。

AI Agent的安全债，已经还不完了

2025年底到2026年初，OpenClaw——全球增长最快的开源AI Agent框架——经历了一场教科书级的安全危机。

CVE-2026-25253（CVSS 8.8）：一个一键RCE漏洞。攻击者只需要让用户访问一个恶意网页，就能通过WebSocket劫持拿到OpenClaw的完整控制权——包括你的登录凭据和系统权限。更可怕的是，这个漏洞连只绑定localhost的实例也无法幸免。修复前，超过17500个暴露在公网上的实例全部处于风险中。

ClawHavoc供应链攻击：ClawHub技能市场中发现341个恶意技能包（占注册量的12%），主要投递Atomic macOS Stealer（AMOS）恶意软件。后续扫描发现恶意包已增长到800+个，约占整个市场的20%。

42000+公网暴露实例：Censys、Bitsight、Hunt.io等多个扫描团队发现数万个无认证的OpenClaw实例直接暴露在互联网上。Bitdefender的企业遥测数据确认，OpenClaw已经出现在企业终端上——构成了一个新的”影子AI”威胁，且拥有高系统权限。

这还只是冰山一角。明文存储凭据、无WebSocket来源校验、技能市场几乎无审核——OpenClaw的架构本身就为安全事件提供了温床。

业内都试了哪些路？

AI Agent的安全问题不是今天才有的。过去一年，业界至少走了四条路：

路线一：策略治理层——OWASP Agentic AI Top 10 + NIST AI RMF

2025年12月，OWASP发布了首个Agentic AI Top 10风险分类，覆盖目标劫持、工具滥用、提示注入等十类威胁。NIST也在2026年初启动了AI Agent标准倡议，重点关注互操作性和身份管理。

优势：建立共识、指导合规。局限：框架是纸面上的，不阻止一行恶意代码执行。企业拿到框架后，还是得自己想办法落地。

路线二：沙箱运行时——MicroVM + gVisor

以Firecracker、gVisor为代表，为Agent提供内核级隔离。每个Agent运行在独立的轻量虚拟机中，即使被攻破也无法逃逸到宿主机。

优势：隔离强度最高，接近硬件级。局限：资源开销大，冷启动慢（秒级），不适合高频调用的生产场景。而且，MicroVM解决不了供应链投毒——恶意技能包照样能在沙箱里偷数据。

路线三：K8s原生沙箱——Agent Sandbox on Kubernetes

开源的Kubernetes控制器，提供声明式API管理有状态Pod，支持持久存储和稳定身份。适合在K8s集群中批量部署隔离的Agent环境。

优势：与现有云原生基础设施无缝集成。局限：只覆盖K8s场景，对个人开发者和小团队门槛极高。而且它管的是”部署隔离”，不是”行为约束”——被投毒的Agent在隔离环境里照样能做坏事。

路线四：运行时安全引擎——Agent Governance Toolkit

在Agent执行层插桩，实现语义意图分类、工具调用权限控制、策略引擎等。OWASP的Agentic AI Top 10中的每一类风险，都能映射到工具包的具体防护能力。

优势：最精细的行为级控制。局限：实现复杂，性能开销显著，且依赖对Agent行为的准确建模——而Agent的行为本质上不可预测。过度约束又会扼杀Agent的实用性。

Tank OS走了第五条路

Tank OS的思路既不是最重的（不用MicroVM），也不是最复杂的（不搞运行时插桩），而是做了一件看似简单但极其务实的事：把Agent装进rootless容器，打成一个可引导的系统镜像。

具体来说：

– 容器隔离：基于Red Hat的Podman，每个OpenClaw实例运行在独立的rootless容器中。没有root权限，即使Agent被攻破也无法访问宿主机。

– 凭据分离：每个实例的API密钥独立存储，一个Agent看不到另一个的凭据。

– 镜像化部署：整个系统打包为一个bootable image——推送到任何机器即可启动，更新只需换镜像重启。不用手动配置，不用逐台打补丁。

– 批量管理：面向企业IT管理Agent舰队，统一镜像、统一策略。

Tank OS的作者Sally O’Malley本身就是OpenClaw的核心维护者。这意味着她不是从外部给Agent加笼子，而是从项目内部理解了企业场景的安全缺口后，给出的工程解法。

五条路的对比

Tank OS的局限也很明显：它做的是”边界隔离”，不是”行为约束”。被投毒的Agent在容器里依然能调用API、发送邮件——只是无法逃逸到宿主机。它也解决不了供应链投毒本身，只是限制了投毒后的爆炸半径。

为什么这条”不够完美”的路可能最该走

安全领域有一个反直觉的规律：最有效的安全方案往往不是最强的，而是最可能被采用的。

OWASP框架很全面，但企业拿到后不知道怎么落地；MicroVM隔离最强，但大多数团队没有能力部署；运行时引擎最精细，但Agent行为的不可预测性让规则总是落后一步。

Tank OS做了一件所有人都懂、大多数团队都能做的事：把Agent放进容器。隔离强度够用（rootless Podman），部署成本极低（bootable image），资源开销可控。

当你的安全方案需要CTO批准预算、需要SRE团队排期、需要三个月落地时，那个”周末就能搭出来”的方案，可能才是真正救命的。

过去半年，42000个暴露的OpenClaw实例在互联网上裸奔。它们不是没有更好的安全方案可选，而是没有人在用。

来源：[TechCrunch](https://techcrunch.com/2026/04/28/red-hats-openclaw-maintainer-just-made-enterprise-claw-deployments-a-lot-safer/) | [Decrypt](https://decrypt.co/365888/red-hat-tank-os-openclaw-enterprise-security) | [Conscia安全分析](https://www.conscia.com/blog/the-openclaw-security-crisis/) | [NVD CVE-2026-25253](https://nvd.nist.gov/vuln/detail/CVE-2026-25253)

你怎么看？ 你的团队在用AI Agent吗？有没有做安全隔离？评论区聊聊你的经验👇

———

关注「AI 每日参」

极速同步硅谷前沿，深度拆解主流大厂进展。