Tamnoon 基于 Amazon Bedrock 打造 AI 云安全修复智能体

云安全团队长期面临一个尴尬的现实：检测工具越来越强，修复速度却始终跟不上。CNAPP（云原生应用保护平台）每天吐出成百上千条安全发现，但真正被修复的往往只是冰山一角。Tamnoon 试图用 AI 智能体打破这个瓶颈——他们在 Amazon Bedrock 上构建了名为 Tami 的云修复编排器，让 AI 自主调查并安全地修复云安全发现。据官方数据，这一方案在 90 天内将关键云暴露面削减了 90% 以上，且没有引发任何生产环境事故。

云安全修复为何成为瓶颈

传统云安全运营的流程大致是：CNAPP 或云原生工具发现配置错误、权限过大、暴露端口等问题，生成告警，然后由安全工程师逐条排查、确认、手动修复。问题在于，检测端的自动化和修复端的人工操作之间存在巨大落差。

一个典型的中大型云环境可能同时运行数百个 AWS 账户、数千个 IaC 模板和微服务。每一条安全发现都需要理解上下文——这个 S3 桶是否真的对外暴露？这个 IAM 角色是否被其他服务依赖？手动修复不仅慢，而且风险高：改错一个安全组规则可能直接导致服务中断。

Tamnoon 的切入点正是这段"最后一公里"。他们没有再做一层检测，而是把 AI 智能体放到修复环节，让系统自己完成调查、决策和执行。

CNAPP 是 Gartner 提出的一个整合型品类，全称 Cloud-Native Application Protection Platform，即云原生应用保护平台。它把此前分散的多类云安全能力收敛到同一平台：CWPP 负责工作负载运行时防护，CSPM 负责云配置错误与合规基线检测，CIEM 负责云身份与权限分析，部分方案还覆盖容器、Kubernetes 与 IaC 扫描。CNAPP 的价值在于把攻击面、权限、配置和运行时信号放到同一上下文中关联分析，因此能发现单点工具难以识别的组合式风险。但它的输出本质上仍是"发现清单"，告警数量会随云资产规模线性膨胀。当每日发现量达到数百上千条时，修复环节的人力就成为整个安全闭环的实际吞吐上限，这正是文章所描述的瓶颈来源。

Tami 如何工作：智能体编排的修复逻辑

Tami 的定位是"agentic cloud remediation orchestrator"，即智能体驱动的云修复编排器。它的核心能力不是简单地根据规则自动打补丁，而是模拟人类安全工程师的推理过程。

当一条安全发现进入系统后，Tami 会先进行上下文调查：这个资源属于哪个业务单元？它与其他资源存在怎样的依赖关系？修复操作的影响范围有多大？这些信息来自 CNAPP 的发现数据、云原生 API 以及 Tamnoon 自身积累的环境图谱。

完成调查后，Tami 生成修复方案并评估风险等级。对于低风险、高确定性的问题，它可以自主执行修复；对于涉及生产关键路径的变更，则升级给人工审核。整个流程运行在 Amazon Bedrock 之上，利用基础模型进行推理和决策。

这种设计的巧妙之处在于"安全护栏"的嵌入。Tamnoon 强调的不是全自动，而是"安全地自动"——智能体在动手之前必须完成充分的上下文验证，这解释了为什么他们能做到 90% 修复量且零生产事故。

IaC（Infrastructure as Code，基础设施即代码）指用声明式配置文件而非手工控制台操作来定义和管理云资源，典型代表包括 Terraform、CloudFormation 和 Pulumi。它带来的关键变化是：云环境的真实状态同时存在于两处——云端实际运行的资源和代码仓库中的模板。这两者可能不一致，即所谓"配置漂移"。对安全修复而言，这意味着一个发现往往需要同时修正线上资源和 IaC 模板，否则下次部署会把问题带回来。这也是为什么中大型环境中"数千个 IaC 模板"会显著抬高修复复杂度：修复动作不只是改一个云 API 调用，还要回溯到对应的代码路径并保证不破坏流水线。

为什么选择 Amazon Bedrock

Tamnoon 选择 Amazon Bedrock 作为底层平台，有几个现实考量。

Bedrock 提供对多种基础模型的统一访问，这意味着 Tami 可以根据任务类型选择不同模型——调查阶段可能需要更强的推理能力，而修复执行阶段可能更看重速度和成本。Bedrock 的托管特性也让 Tamnoon 团队不必自建模型推理基础设施，可以把精力集中在云安全领域的逻辑编排上。

从架构角度看，Bedrock 与 AWS 原生服务的深度集成也是一个优势。云安全修复本身就需要大量调用 AWS API，在同生态内构建智能体可以减少集成的摩擦。

智能体编排（agentic orchestration）与传统的规则引擎或工作流自动化有本质区别。规则引擎执行的是预先写死的 if-then 逻辑，覆盖范围受限于编写者能预见的情形；而智能体编排由基础模型在运行时进行推理，能够调用工具、查询外部数据源、根据中间结果动态决定下一步动作。在云修复场景中，这种能力体现为：智能体可以自行决定需要查询哪些资源、依赖关系图谱要展开几层、某个变更是否需要进一步验证。代价是行为不完全可预测，因此必须配套约束机制——工具白名单、可执行动作边界、变更前置校验、风险分级与人工审批，以及完整的操作审计轨迹。文中强调的"安全护栏"正是指这类把智能体能力限制在可接受范围内的工程措施。

90 天削减 90% 暴露面的启示

Tamnoon 公布的这组数据值得拆解：90%+ 的关键暴露面削减、90 天周期、零生产问题。三个数字缺一不可。

如果只有修复速度而没有安全性，这个方案对生产环境没有意义；如果只有安全性而没有速度，那它相对于人工流程的优势就不够明显。Tamnoon 的案例说明，当 AI 智能体在修复前完成足够的上下文调查，并且有清晰的风险分级和人工升级机制时，自动化修复可以在激进的目标下仍然保持可控。

这对云安全从业者的启示是：修复瓶颈的突破点可能不在于更好的检测，而在于让 AI 理解环境上下文后自主行动。检测和修复之间的鸿沟，正在成为 AI 智能体落地的最有价值的场景之一。

对于正在评估类似方案的安全团队，Tamnoon 的实践提供了一条可参考的路径——从修复环节切入，用智能体编排替代逐条人工处理，同时把安全护栏作为架构的一等公民而非事后补丁。