云原生运行时治理的难点，不在于是否部署了足够多的安全工具，而在于能否明确三层职责：事前检查负责降低风险进入生产的概率，运行时检测负责识别正在发生的异常，持续审计负责回答“谁做了什么、为什么以及结果如何”。三者如果边界模糊，企业就容易把配置扫描当成运行安全，把日志留存当成检测能力，或试图用平台弥补权限模型和业务架构的缺陷。
第一层：事前检查负责“准入”
事前检查发生在代码提交、镜像构建、部署审批和环境发布之前，重点是验证预期状态是否符合基线，例如工作负载是否使用不必要的高权限、编排配置是否暴露敏感信息、身份策略是否超出业务需要。
这一层适合承担发布门禁和基线校验，优势是反馈早、整改成本低。但它看到的是“计划如何运行”，无法证明生产环境始终如此。人工操作、控制器或第三方组件都可能造成配置漂移，因此事前通过并不等于运行安全。
第二层：运行时检测负责“识别”
运行时检测关注实际行为，包括异常进程、可疑网络连接、权限使用变化、容器逃逸风险信号，以及偏离业务基线的操作。它处理的是“现在是否正在发生异常”，核心不是采集越多事件越好，而是结合身份、工作负载和业务上下文判断风险。
这一层必须明确处置责任。高风险动作可以考虑阻断或隔离，需要人工判断的事件则应提供影响范围和行为背景，避免把备份、故障切换或批量发布等正常操作误判为攻击。
第三层：持续审计负责“证明与改进”
持续审计关注身份、资源、操作、时间、来源和结果的完整关联，用于追溯责任、证明审批、发现长期未使用的权限，并检验安全策略是否真正执行。它不等同于检测：日志保存得再完整，如果缺少分类、关联和响应流程，仍可能无法及时发现问题。
因此，三层能力应形成闭环，而不是建设一个所谓“全能平台”。架构和流程应解决服务边界不清、身份共用、配置无统一来源等根本问题；安全平台则更适合承担资产盘点、基线对比、运行检测、事件关联和处置记录。只有先划清职责，再逐步引入自动化，云原生治理才不会陷入告警泛滥和权限失控。