Tamnoon 如何基于 Amazon Bedrock 构建 AI 云安全修复编排器 Tami

关键云暴露的累积速度超过了安全团队修复的速度。云原生应用保护平台（CNAPP）、云服务提供商和态势扫描器生成的发现结果之多，任何团队都无法逐一分诊，风险就在“已检测”与“已修复”之间的空隙中不断累积。大多数发现结果被搁置不理，并不是因为它们难以修复。而是必须有人去调查上下文、确定责任人、确认修复不会破坏生产环境，然后以超过人力规模的工作量去完成这些事。

在这篇文章中，我们将分享 Tamnoon 如何在 Amazon Bedrock 上构建了 Tami——一个智能体化的云修复编排器，来弥合这一空隙。Tami 自主调查从 CNAPP 和云原生来源摄取的发现结果，并评估修复是否安全。随后，只要变更涉及客户的云环境，它就会在护栏和治理机制下生成并编排修复。该方法在 90 天内将关键云暴露减少了 90% 以上，且未出现任何生产问题。

关于 Tamnoon

Tamnoon 是一个与 CNAPP 协同工作的 AI 驱动的云安全修复平台。其 AI 助手 Tami 帮助人类云安全专家在 AWS、Azure、Google Cloud 及其他云服务提供商的客户环境中调查、排列优先级并安全修复错误配置和问题。

Tamnoon 与团队已在使用的 CNAPP 和云原生工具集成，并将它们的发现结果转化为经过验证的、生产环境安全的修复方案。大部分工作——包括调查、优先级排序和修复规划——都在触及线上环境之前完成，这正是让自动化修复能够大规模可信应用的关键。

一名安全工程师可能要花数小时调查单个发现结果。而它往往与其他数十条警报追溯到同一个根本原因。

警报数量超出人力承载：CNAPP 和扫描器生成数千条发现结果。团队无法全部分诊，导致关键暴露长期未解决，风险持续累积数月。
调查工作手动且重复：每个发现结果都需要收集上下文——资源归谁所有、什么依赖它、修复是否安全。这消耗了资深工程师数小时的时间，并在积压清单的每一项上反复发生。
对生产环境影响的担忧阻碍了自动化：团队不敢自动化修复，因为他们承受不起搞垮生产环境的风险。如果没有修复安全性的信心，一切都无法推进。
被动的优先级排序：由于无法聚类相关发现结果或为修复置信度评分，团队只能线性地处理警报，而不是通过解决根本原因一次性解决多个问题。

Tamnoon 的解决方案覆盖了从发现结果摄取到经过验证的修复的完整流水线。该平台将这些挑战视为相互关联的问题，而非孤立的问题。

解决方案概述

Tamnoon 带你从初始发现走到执行修复。该平台从 CNAPP、云安全态势管理（CSPM）提供商和其他安全工具摄取发现结果，并将其规范化为统一模式。随后通过资产和暴露上下文对其进行丰富，并排列优先级。接下来，智能体层接手工作，使用一组专门的 AI 智能体，每个智能体都运行在 AWS 上事件驱动的无服务器架构中，因此每个阶段都可以独立扩展并安全失败。

基于 Amazon Bedrock 的智能体架构

该平台将工作委派给四个专门的智能体，每个智能体负责修复流水线中一个独特的阶段：

调查智能体（investigation agent）利用对数百万个真实客户云环境的训练来确定上下文，并将该上下文通过一个大型语言模型（LLM）作为裁判（LLM-as-a-judge）的验证层进行过滤。它会围绕修复目标、操作范围以及云服务商特定的验证方式进行推理，生成只读的调查步骤和完整的调查计划。
安全评分智能体（safety-scoring agent）为每个资产构建证据链，将自动化验证结果与分析人员的发现相结合。它以刻意保守的倾向，将每项发现的修复措施分类为 SAFE、RISKY 或 AWAITING DATA。一旦存疑，它就会降低评级。
修复智能体（remediation agent）只对安全智能体判定为安全的发现启用。它会就顺序、依赖关系和条件进行推理，然后生成一个修复计划，其中每个步骤都遵循备份、修复和验证的结构，并包含回滚指引。
代码生成智能体（code-generation agent）将计划步骤转化为可执行的修复操作，但前提是输入防护栏（guardrail）已筛选相关性和提示注入。每个产物都要经过一个自动化的生成与审查循环，由一个独立的审查者智能体批准输出。

为什么选择 Amazon Bedrock

当 Tamnoon 团队着手构建 Tami 时，基础模型（FM）平台的选择将决定后续的一切。Tamnoon 的修复智能体并非都做同一种工作。有些执行深度调查推理，以了解安全发现的根本原因。有些处理高容量验证，快速且低成本地检查拟议的修复方案。还有一些审查生成的代码，在每个任务中权衡质量与成本。将每项工作匹配到合适的模型，而无需为每个模型分别搭建不同的集成，这是一项核心要求。

正是这一要求使 Amazon Bedrock 成为自然之选。通过单一 API，每个智能体都可以调用最适合其任务的基础模型。能力最强的模型处理最困难的推理。更高效的模型承担重复性、高吞吐量的工作。以审查为重点的模型则优化输出质量与成本之间的权衡。由于只需一次集成而非多次，随着技术格局的演变，模型可以被替换或升级，而无需每次都重新改造架构。

大规模运营开销是决策的另一个因素。随着请求量的增长，Tamnoon 希望避免构建和维护自己的逻辑来跨区域容量分配流量。Amazon Bedrock 跨区域推理（Cross-Region inference）自动处理了这一点。它会自动将推理请求路由到定义的地理边界内的最佳 AWS 区域，在无需任何自定义路由代码的情况下保持吞吐量。

安全性是最后的考虑因素，对于一家云安全公司来说，这是不容妥协的。借助 Bedrock，推理在 Tamnoon 自己的 AWS 环境中运行，并受 AWS Identity and Access Management (IAM) 范围权限的约束。敏感的客户数据绝不会离开信任边界。这让团队确信，支撑 Tami 的平台达到了 Tamnoon 对自身服务所要求的同等标准。

Tamnoon 如何与 CNAPP 及云安全工具集成

Tamnoon 位于安全团队已在运行的检测工具的下游。Wiz、CrowdStrike、Palo Alto Cortex、Upwind、SentinelOne、Orca、Cyera 等 CNAPP，以及 AWS Security Hub 和 Amazon GuardDuty 等云原生服务，是环境中存在问题的真实来源。Tamnoon 通过基于 API 的集成进行连接，并将发现结果规范为统一格式，因此无论来自 Wiz 还是 GuardDuty，配置错误看起来都是一样的。检测工具仍是基础，Tamnoon 则提供后续的端到端修复。

对于它处理的每个发现，Tami 会分配一个修复置信度指标（RCI），等级为 SAFE、RISKY 或 AWAITING DATA。该评级告诉团队哪些可以自动化，哪些需要先进行人工审查。

图 1：Tamnoon 实际运行

Tamnoon AWS 架构

Tamnoon 完全运行在自己的 AWS 账户内，并按环境隔离。用户通过基于 Amazon API Gateway 构建的唯一安全入口访问该平台，加密由 AWS Certificate Manager 管理，登录由 Amazon Cognito 处理。该入口之后的一切都运行在跨多个可用区的私有网络中，因此核心平台从不会直接暴露在互联网上。

在该环境中，Tamnoon 结合了两种计算方式。Amazon Elastic Kubernetes Service（Amazon EKS）运行仪表板背后的常驻服务，而 AWS Lambda 支持事件驱动的工作：收集发现、分析发现并执行修复。一组 AWS 消息传递和工作流服务，包括 Amazon EventBridge、Amazon Simple Queue Service（Amazon SQS）和 AWS Step Functions，协调这些步骤，从而可靠地并行处理大量发现，且任何一条坏记录都不会阻塞其余工作。

AI 层运行在 Amazon Bedrock 上。Amazon Bedrock AgentCore 是一个可使用任何框架或模型大规模构建、连接和优化智能体的平台，为 Tamnoon 的智能体提供了受治理的行动方式，而非无限制的访问。Amazon Bedrock Guardrails 随后会在任何操作推进之前审查请求和生成的代码。其余平台由配套服务支撑：托管数据库和缓存用于状态管理，Amazon Simple Storage Service（Amazon S3）用于 playbook 和制品，AWS Secrets Manager 用于凭据，这样敏感密钥绝不会存在于应用代码中。

在客户侧，AWS Cloud 边界左侧的一切都是客户接入 Tamnoon 的内容。他们可以关联自己的 AWS、Azure 和 Google Cloud 账户，接入产生发现的安全工具，并连接希望交付结果的目的地，例如 Slack、Jira、ServiceNow 和 GitHub。

图 2：Tamnoon AWS 架构

Tamnoon 如何保持零生产事故

零生产事故对 Tamnoon 的客户来说是现实，而这并非偶然。Tamnoon 的自主性位于一个纵深防御的安全架构之内，其中每一层都假设前一层可能有所疏漏。

修复方案的起草甚至还未开始，这套流程就已经启动。只有在一次专注于范围、并刻意偏向谨慎的独立安全评估认定该变更可以安全进行之后，才会编写修复措施。在此基础上，平台在读与写之间划出一条硬性界线。调查步骤会被验证为严格只读，因此理解问题的工作绝不可能改变问题本身。只有修复路径才被允许进行更改，并且它所做的每一项更改都附带各自的备份、验证和回滚步骤。

这种纪律还通过持续的自我审视得到强化。每个生成步骤都配有一个反思步骤，用于检查输出并将其批评意见反馈给重新生成过程，因此系统始终在审视自己的工作，而不是一味信任。这些建议也始终立足于现实。智能体的输出会根据自动化结果、用户反馈以及来自真实已修复警报的训练数据进行验证，而当模型无法独立得出准确结果时，会有真人加入流程。

最后一道保障在执行时刻。AI 从不持有云凭证。相反，执行通过短生命周期、租户范围内的凭证进行代理，这些凭证处于客户控制的信任之下，并在与规划工作的智能体相隔离的环境中运行。贯穿这一切的是人类治理：修复措施需要经过带完整审计追踪的审批工作流，而且每项 AI 能力在到达客户之前都要先经过内部验证。

数据安全与合规

Tami 需要对敏感的客户数据进行推理：警报负载、资源标识符、错误配置以及修复上下文。这些数据必须留在 AWS 信任边界之内、以最小权限运行并保持可审计。标准化使用 Amazon Bedrock 使这一切成为可能。

敏感内容留在 AWS 内部

每个 Tami 工作负载都通过 ChatBedrockConverse 接口调用 Amazon Bedrock 上的 Anthropic Claude，而不是调用第三方 LLM 端点。仅这一项选择就将完整的 AI 供应链置于同一个 AWS 原生服务之下，这对客户数据的处理方式有着实际影响。推理完全在 Tamnoon 自己的 AWS 账户内的美国商业区域中运行，因此数据永远不会离开 AWS。有关各区域模型可用性的信息，请参阅 Amazon Bedrock 各 AWS 区域支持的模型。由于 Bedrock 不会保留提示词或补全内容，也不会基于其进行训练，客户数据从一开始就不会到达外部供应商。

即使工作负载扩展，这一边界依然稳固。Bedrock 跨区域推理会自动将请求路由到美国地理边界内的区域，从而提高应用程序可用的吞吐量。其背后的计算资源也保持私密。每个服务都作为一个 AWS Lambda 函数运行，附加到虚拟私有云（VPC）中的私有子网，配有显式的安全组，没有公共入口，出口也受到严格控制。

守护送达模型的内容

负载可能包含敏感细节，因此 Tami 对每个请求和响应都应用 Amazon Bedrock Guardrails。该策略在 Bedrock 层强制执行，这意味着它统一覆盖所有三个服务，任何单个函数的提示词逻辑都无法绕过它。这个单一执行点同时发挥着多重作用。

首先，它保护敏感数据。PII 和机密类内容在持久化或呈现之前就会被掩码，因此不会让敏感信息留在不该存在的地方。它还能防范提示词注入，这一点很重要，因为 Tami 需要对不可信的发现结果进行推理，而这些结果可能被未授权用户影响。在护栏层进行过滤可以阻止精心构造的载荷劫持模型或外泄上下文。最后，拒绝主题和内容过滤器让模型的输出始终限定在安全修复范围内，不涉及其他内容。每一次干预都会与 AWS CloudTrail 一并记录，为企业客户提供清晰的治理证据链。

最小权限访问

整个平台的访问都通过专用的按服务划分的 IAM 执行角色进行，因此每个函数只能访问它所需的内容，而不能访问更多。这一原则在 Tami 访问 Amazon Bedrock 的方式上体现得最为明显。它唯一的 Bedrock 权限是 bedrock:InvokeModel，且仅限于特定的推理配置文件和基础模型 ARN。它没有任何管理、训练或导出模型的能力。

同样的规范也延伸到其他所有依赖项。对 AWS Secrets Manager 的访问仅限于某个函数实际使用的两个密钥，SQS 访问仅限于其自身的输入队列，Amazon CloudWatch 的写入则按命名空间加以限制。整个设计中没有任何宽泛的万能角色。函数只附加到托管的 AWSLambdaBasicExecutionRole 和 AWSLambdaVPCAccessExecutionRole 策略上，再无更多权限。

多租户隔离与治理

保持租户相互隔离是一项基本要求，并且从第一次调用起就被强制执行。服务间调用通过 Cognito 使用 OAuth2 客户端凭证，并按应用程序划分作用域；工作按一次处理一条 SQS 消息的方式进行，并附带其租户上下文。因此，单次调用只会触及一个租户的数据。

这种保障很大程度上来自将整个平台视为代码的做法。IAM 策略、网络位置、模型 ID 和告警全部保存在带版本控制的 AWS CloudFormation 和 SAM 模板中，因此每项权限和模型版本都可以在源码控制中审查，不会出现手动更改控制台导致的配置漂移。模型版本尤其被固定到带日期的标识符上，例如 claude-sonnet-4-5-20250929，这意味着模型的更改始终是经过明确审查的代码变更，而不是静默升级。

这种透明性也延续到运行时。每次推理调用都会记录在 AWS CloudTrail 中，可归因于发起调用的角色；将 temperature 设为零的确定性解码则确保评分和规划在多次运行之间保持一致。故障处理同样受到严格管控。每个服务都有一个带重驱动的输入队列、一个错误处理函数、一个死信队列，以及针对超时和 DLQ 深度并接入值班告警的 CloudWatch 告警。故障会被隔离且可观察，绝不会悄无声息地被丢弃。

成果与影响

Tami 已在 Tamnoon 的客户群中分析了超过 1400 万条云安全警报，这一数字记录在 Tamnoon 的 2026 年云修复现状报告中。Tami 所做的决策反映了从这些真实环境中学习到的模式。

对于典型客户，成果显现得很快，通常在 90 天内即可看到。

指标	之前	之后
关键云暴露	随着警报数量超过人力承载，风险持续累积数月	90 天内最多减少 90%（来源）
修复效率	数千条原始警报，缺乏清晰的优先级排序	通过根因聚类实现高达 100 倍的效率提升（来源）
生产环境问题	团队因风险而回避自动化	在数百万工作负载中实现零生产环境问题
工程师时间	每个发现需要数小时，且在积压任务中反复出现	每周为客户群节省 13,000+ 小时（来源）

压缩比和零问题数据来自 Tamnoon 的研究。其模式是一致的：未处理的暴露面更少，人工工作大幅减少，且修复本身没有造成停机。

结论

构建一个能够对云安全发现进行推理的智能体并不难，难的是构建一个你能放心让它在生产环境中执行操作的智能体。Amazon Bedrock 是一项完全托管的服务，可通过单一 API 提供对高性能基础模型的访问，以及构建智能体应用所需的工具：编排、工具使用和防护栏。这种组合在这里之所以重要，有一个特定原因：对生产云基础设施执行操作，既需要强大的推理能力，也需要严格的安全边界。

四点使之成为可能：

你的暴露面真正得到关闭：Tamnoon 直接作用于真实的云基础设施，而不是工单或工作流自动化。积压任务在减少，而不是横向扩张。
自主性扩展且无生产风险：每个拟执行的操作都带有置信度评级。SAFE 操作可以自动执行，而 AWAITING DATA 或 RISKY 操作则会交由 Tamnoon 的嵌入式云工程师处理。
运行在你已有的技术栈之上：Tamnoon 可在主流 CNAPP 和云安全工具之上运行。你已付费的每一个检测工具都开始产生回报，因为其发现终于能被关闭了。
团队产能扩展而无需扩张：快速、安全地采用前沿 AI 意味着每位分析师能关闭更多暴露面，且无需增加人手。

后续步骤

要开始构建类似的架构，请考虑以下几点：

探索 Amazon Bedrock 及其提供的可用模型。
查阅 Amazon Bedrock 文档以规划你的架构。
与 Tamnoon 预约演示，了解在未来 90 天内你能关闭多少关键云暴露面。