作者：Jed Salazar，Edera Field CTO

最近，Anthropic 宣布，其新模型 Mythos 已经能够自主发现并利用所有主流操作系统和 Web 浏览器中的零日漏洞，其中甚至包括一个存在 27 年、经历过数十年人工审查和数百万次自动化测试仍然幸存下来的漏洞。这个模型不需要专门训练，也不需要人类研究人员引导。

如果一个 AI 模型能够自主串联漏洞，在 Linux 上实现内核权限提升，那么对于一种让成千上万个工作负载共享同一个内核、彼此之间没有结构性隔离的基础设施模型来说，这意味着什么？

Mythos 并没有带来一种全新的威胁。它只是让一个旧设计决策所带来的后果，变得更难再被推迟处理。

末日仪表盘

看看今天市场上的主流安全产品。除少数例外，它们基本上都是被美化过的日志生成器和“末日仪表盘”。运行时检测 Agent、漏洞扫描器、准入控制器，类似工具还有很多。它们都基于同一个假设：阻止入侵，或者足够快地检测到入侵，这样你就赢了。

但它们并不会让系统本身变得更安全。扫描器发现一个严重 CVE，生成一张工单，然后把它丢给开发团队，而开发团队还有自己的优先事项。架构不会自愈，也不会控制爆炸半径。它只是看着自己燃烧，并且非常认真地做笔记。

想象一下，如果 Kubernetes 也是这样工作的：你的 Pod 崩溃了，kubelet 并没有重新调度它，而是打开一张 Jira 工单：“Pod 不健康。建议重启。负责人：平台团队。”这听起来很荒谬。但今天大多数组织的生产安全体系，基本就是这样运行的。

故障前控制也需要一种几乎不可能具备的知识量，才能被正确配置。每一条网络策略、每一个 RBAC 规则、每一个 seccomp profile，都必须根据它所保护的工作负载的具体行为进行调优。

在一个运行着数千个容器的多租户 Kubernetes 集群中，这意味着必须有人清楚地知道每个服务会调用哪些 API、需要哪些端口、会访问哪些文件系统路径，以及什么才算“正常”行为。并且，这是对每一个工作负载都要做到。

这不是工具问题，而是信息问题。正确配置故障前控制所需要的知识，分散在不同团队中，从来没有集中在一个地方。完美配置需要全知全能，而全知全能不是一个可以交付的功能。

于是，行业开始玩一场无限循环的增量加固游戏：修补这个 CVE，收紧那条网络策略，再加一条检测规则。每一次改进，都会把负担永久压在防守方身上。攻击者只需要找到一条可行路径：初始访问、权限提升、横向移动。而防守方必须在成千上万个工作负载上，同时保证每一项配置都正确。

这个数学题本身就不成立。

设计问题

有一个问题，是大多数安全架构无法回答的：

如果你假设某个工作负载已经被攻破，就像你假设 Pod 随时可能崩溃一样，你会如何设计系统？

这正是 SRE 看待可靠性的方式。你不会在设计分布式系统时假设每个节点都永远健康。你会假设节点会不可预测地失败，并通过工程手段确保单点故障不会级联扩散。

断路器会阻止故障传播，故障域会限制爆炸半径。你并不需要让每个节点永远存活，应用才能继续提供服务，因为架构本身就是为了在故障中生存而构建的。

如果我们把同样的思路应用到安全上会怎样？如果单个被攻破的工作负载，也能像 Kubernetes 处理崩溃 Pod 那样，被视为一种预期内的故障，并由系统自动绕过，会怎样？

它不是灾难，不是仪表盘告警，也不是作战室事件。它只是又一个普通的星期二。

Kubernetes 的讽刺

这种讽刺在 Kubernetes 生态中最为尖锐。

Kubernetes 是基础设施领域的 SRE 时刻，是“为故障而设计”这一理念最成功的体现。Pod 会崩溃并被重新调度，节点会宕机而工作负载会迁移。整个系统都假设任何单个组件都可能失败，并由平台自动处理。

但运行在同一个平台上的安全模型，却是一个灾难性的单点故障。

大多数 Kubernetes 集群都会让所有容器运行在共享的 Linux 内核之上。一个节点上的每个工作负载，无论是微服务、Sidecar，还是批处理任务，无论来自哪个团队，都共享同一个内核地址空间。

一个内核漏洞并不只是攻破一个容器，而是会攻破该节点上的每一个容器。更糟糕的是，你部署的那些用于检测入侵的安全控制手段，包括基于 eBPF 的 Agent、LSM 模块、seccomp-bpf 过滤器，也运行在同一个内核之上。

一次内核利用不仅会攻破每个容器，还会同时让所有监控它的工具失明。你的检测层和爆炸半径，实际上是同一个东西。

我们运行着一个能够自动处理任意 Pod、任意节点、任意基础设施组件故障的平台，但在安全上，却以零隔离、零故障域、零预案的方式运行。尤其当那个失败对象是内核，是所有工作负载共享的单一基础设施组件时，整个模型就暴露出了根本性问题。

结构性修复

如果共享内核是单次利用会级联影响一个节点上所有工作负载的原因，那么架构修复方式就和分布式系统工程几十年前解决的问题一样：消除单点故障。

不要再让所有工作负载共享一个内核。应该把故障域分散到彼此独立的内核实例中，就像你会把一个单体数据库分散到多个副本上一样。

这样一来，一个内核实例被攻破，只会被限制在一个工作负载内。不是因为有人记得配置了某条策略，而是因为故障域边界本身就是结构性的。

这种方法并不意味着不再需要安全策略。你仍然需要网络分段、最小权限 IAM 和供应链安全。真正改变的是：当这些策略配置错误时，会造成怎样的后果。

有了结构性隔离，策略失败只会被限制在它影响的工作负载内。故障前控制会变成带有底层安全网的最佳努力加固，而不是最后一道防线。

AI Agent 的证明

让这一刻变得不同的是：AI 行业已经替我们做完了实验。

每一家发布自治 Agent 的主流 AI 实验室，都独立得出了同一个架构决策：优先考虑封闭，建立硬边界，使用沙箱化执行环境，确保策略失败不会越过沙箱边界级联扩散。

它们仍然使用策略，但会把策略作为沙箱内部的一层，而不是把策略本身当作边界。

为什么？因为当你不知道一个系统下一步会做什么时，你不可能为它写出一套完整的安全策略。一个 AI Agent 可能确实需要安装软件包、写入任意路径、发起网络调用。它也可能做出灾难性的事情。它的行为空间太大，无法单靠策略覆盖。

所以，它们建起了墙，然后把规则放在墙里面。

AI 行业重新发现了一个安全行业本应在几十年前就建立起来的原则。问题是，为什么我们今天仍然把那些处理客户数据、金融交易和关键基础设施的生产工作负载，运行在共享内核之上，而且隔离能力甚至还不如一个浏览器标签页？

Chrome 十多年前就已经想明白：一个崩溃或被攻破的标签页，不应该拖垮整个浏览器。而你运行支付处理业务的 Kubernetes 集群，隔离保证却比浏览 Reddit 还弱。

转变

我职业生涯的起点是一名系统管理员。那时我以为，保证一台服务器持续运行，就是这份工作的核心。后来我在 Google 学到，真正的工作，是构建那些不需要我一直维持其运行的系统。

这个认知改变了基础设施工程。它带来了 SRE、Kubernetes，以及今天我们所依赖的每一个自愈型分布式系统。

安全领域仍然在等待同样的转变。我们仍然在构建需要英雄的系统，需要有人注意到入侵、解读仪表盘、分诊告警，并迅速召集响应团队。

我们仍然把入侵视为一种“不该发生的事情”，而不是一种需要围绕其进行工程设计的现实。

在 Edera，我们认为，安全需要经历和运维转向可靠性工程时一样的范式转变：承认失败不可避免，用爆炸半径而不是入侵次数来衡量系统，并通过工程手段确保没有任何一次单点攻破能够跨越其故障域级联扩散。

过去两年里，我们一直在构建让这一点在 Kubernetes 中成为现实的隔离层。它不是又一个仪表盘，也不是又一个检测工具，而是一种架构默认值：让攻破变成一个非事件，就像 Kubernetes 让 Pod 崩溃变成一个非事件一样。