AI模型引发的安全思考
最近，Anthropic宣布，其新模型Mythos已能自主发现并利用主流操作系统和Web浏览器中的零日漏洞，包括一个存在27年、历经数十年人工审查和数百万次自动化测试仍未被发现的漏洞。这个模型无需专门训练，也无需人类研究人员引导。
如果一个AI模型能自主串联漏洞，在Linux上实现内核权限提升，对于让成千上万个工作负载共享同一内核、彼此无结构性隔离的基础设施模型而言，意味着什么？Mythos并非带来全新威胁，只是让旧设计决策的后果更难推迟处理。
主流安全产品的困境
看看如今市场上的主流安全产品，除少数例外，基本都是美化过的日志生成器和“末日仪表盘”。运行时检测Agent、漏洞扫描器、准入控制器等工具，都基于阻止入侵或快速检测入侵就能获胜的假设。
但它们无法让系统本身更安全。扫描器发现严重CVE后生成工单交给开发团队，而开发团队有自己的优先事项。架构不会自愈，也无法控制爆炸半径，只能看着问题发生并做记录。
故障前控制需要大量知识才能正确配置。在多租户Kubernetes集群中，需清楚每个服务调用的API、所需端口、访问的文件系统路径以及正常行为等，且要针对每个工作负载做到。这不是工具问题，而是信息分散在不同团队，难以集中。
于是，行业陷入增量加固的循环，每次改进都增加防守方负担。攻击者只需找到一条可行路径，而防守方要保证成千上万个工作负载的配置都正确，这显然不现实。
安全架构的设计问题
多数安全架构无法回答：假设某个工作负载已被攻破，该如何设计系统？这正是SRE看待可靠性的方式，设计分布式系统时会假设节点可能失败，并通过工程手段防止单点故障扩散。
如果将此思路应用到安全领域，把单个被攻破的工作负载视为预期内的故障，由系统自动绕过，会怎样？它将不再是灾难、告警或事件，只是平常之事。
Kubernetes的讽刺
这种讽刺在Kubernetes生态中尤为明显。Kubernetes是基础设施领域“为故障而设计”理念的成功体现，Pod会崩溃并重新调度，节点会宕机但工作负载会迁移。
然而，运行在同一平台上的安全模型却是单点故障。大多数Kubernetes集群让所有容器运行在共享的Linux内核上，一个内核漏洞会攻破节点上的所有容器。更糟糕的是，用于检测入侵的安全控制手段也运行在同一内核上，一次内核利用会让所有监控工具失效。
我们运行着能自动处理故障的平台，但在安全方面却零隔离、零故障域、零预案，尤其是内核作为所有工作负载共享的单一组件，整个模型暴露出根本性问题。
结构性修复方案
如果共享内核是单次利用影响所有工作负载的原因，那么架构修复应消除单点故障，将故障域分散到独立的内核实例中，就像分散单体数据库一样。
这样，一个内核实例被攻破只会影响一个工作负载，因为故障域边界是结构性的。这并不意味着不需要安全策略，只是策略失败的后果会被限制在受影响的工作负载内，故障前控制会成为有底层安全网的最佳努力加固，而非最后防线。
AI Agent的启示
AI行业已为我们做了实验，主流AI实验室发布自治Agent时都优先考虑封闭，建立硬边界，使用沙箱化执行环境，确保策略失败不会级联扩散。
因为AI Agent行为空间大，无法用策略完全覆盖，所以先建墙再放规则。AI行业重新发现了安全行业早该建立的原则，可我们仍将处理关键业务的生产工作负载运行在共享内核上，隔离能力甚至不如浏览器标签页。
安全领域的转变
作者从系统管理员转变为意识到要构建无需一直维护的系统，这一认知改变了基础设施工程。而安全领域仍在等待类似转变，我们仍将入侵视为不该发生的事，而非需要围绕其设计的现实。
在Edera，认为安全需像运维转向可靠性工程那样范式转变，承认失败不可避免，用爆炸半径衡量系统，通过工程手段防止单点攻破级联扩散。过去两年，一直在构建Kubernetes中的隔离层，让攻破像Pod崩溃一样平常。
极致优化到O(n))
