Tamnoon 如何用 Amazon Bedrock 构建 AI 云安全修复平台 Tami

关键的云暴露问题堆积的速度远超安全团队能够修复的速度。云原生应用保护平台（CNAPP）、云服务提供商和态势扫描器产生的发现项数量，超过任何团队能够逐一排查的能力，风险便在“已检测”与“已修复”之间的缺口里不断累积。大多数发现项无人处理，并非因为它们难以修复。而是需要有人去调查上下文、确定负责人、确认修复不会影响生产环境，然后以超越团队人力的规模去执行。

在本文中，我们分享 Tamnoon 如何基于 Amazon Bedrock 构建 Tami——一个智能体式云修复编排器，来弥合这一缺口。Tami 自主调查从 CNAPP 和云原生来源摄入的发现项，并评估修复是否安全。随后，在变更触及客户云环境的任何环节，它都会在护栏与治理机制的约束下生成并编排修复方案。该方法在 90 天内将关键云暴露减少了 超过 90%，且未出现任何生产问题。

关于 Tamnoon

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

Tamnoon 与团队已在使用的 CNAPP 和云原生工具集成，将其发现项转化为经过验证、对生产安全的修复方案。包括调查、优先级排序和修复规划在内的大部分工作，都在触及任何实时环境之前完成，这正是自动化修复能够在大规模下值得信赖的原因。

云安全修复的挑战

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

• 告警数量压垮人力：CNAPP 和扫描器产生数千条发现项。团队无法全部排查，因此关键暴露问题悬而未决，风险在数月间不断累积。
• 调查是手动且重复的：每个发现项都需要收集上下文——谁拥有该资源、有什么依赖它、修复是否安全。这消耗了资深工程师数小时的时间，并且在积压的每一项上重复发生。
• 对生产影响的担忧阻碍了自动化：团队对自动化修复犹豫不决，因为他们不能冒险让生产宕机。若对修复的安全性没有信心，就什么都不会推进。
• 被动式优先级排序：由于缺乏对相关发现项进行聚类或对修复置信度打分的方法，团队只能线性地处理告警，而不是去解决那些能一次性消除许多问题的根本原因。

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

解决方案概览

Tamnoon 带你从最初的发现项走到执行修复。该平台从 CNAPP、云安全态势管理（CSPM）提供商及其他安全工具摄入发现项，并将其规范化为统一的数据模式。随后，它用资产与暴露上下文对这些发现项进行丰富，并对其进行优先级排序。在此基础上，智能体层借助一组专门的 AI 智能体接管后续工作，每个智能体都运行在 AWS 上事件驱动的无服务器架构中，因此每个阶段都能独立扩展并安全失败。

基于 Amazon Bedrock 的智能体架构

该平台将工作委派给四个专业代理，每个代理负责修复流程中一个不同的阶段：

• 调查代理基于数百万真实客户云环境的训练来确定上下文，并通过大语言模型（LLM）作为评判者的验证层对该上下文进行过滤。它围绕修复目标、操作范围和云服务商特定的验证进行推理，产出只读调查步骤和完整的调查计划。
• 安全评分代理为每项资产构建证据链，将自动化验证结果与分析师发现相结合。它把每项发现的修复分类为 SAFE、RISKY 或 AWAITING DATA，并刻意采用保守倾向。存疑时，它会下调评级。
• 修复代理仅对安全代理判定为安全的发现启用。它会围绕顺序、依赖关系和条件进行推理，然后生成修复计划，其中每一步都遵循备份、修复、验证的结构，并包含回滚指引。
• 代码生成代理将计划步骤转化为可执行的修复操作，但前提是先经过输入护栏筛查相关性和提示注入。每个产物都要通过自动化的生成与审查循环，其中必须由独立的审查代理批准输出。

为什么选择 Amazon Bedrock

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

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

规模化下的运维开销是决策中的另一个因素。随着请求量增长，Tamnoon 希望避免构建和维护自己的逻辑来在区域容量之间分配流量。Amazon Bedrock 跨区域推理会自动处理这一点。它自动将推理请求路由到定义的地理边界内的最优 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 会在任何内容继续推进之前审查请求和生成的代码。配套服务负责平台其余部分：用于状态管理的托管数据库和缓存、用于 playbook 和工件的 Amazon Simple Storage Service（Amazon S3），以及用于凭据的 AWS Secrets Manager，因此敏感密钥永远不会存在于应用程序代码中。

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

图 2：Tamnoon AWS 架构

Tamnoon 如何保持零生产问题

零生产问题对 Tamnoon 的客户而言是现实，而这绝非偶然。Tamnoon 的自主性位于纵深防御安全架构之内，其中每一层都假定前一层可能遗漏某些内容。

它在任何修复方案起草之前就已启动。在独立的安全评估（聚焦于变更范围，并刻意偏向谨慎）得出结论认为该变更可以安全实施之前，不会编写任何修复方案。在此基础上，平台在读取与写入之间划出严格界限。调查步骤被验证为严格只读，因此理解问题的工作永远不会改变问题本身。只有修复路径才被允许更改任何内容，而它所做的每一项更改都自带备份、验证和回滚步骤。

这种纪律由持续的自我批判来强化。每个生成步骤都配有一个反思步骤，用于检查输出并将其批评意见反馈到重新生成中，因此系统始终在审查自己的工作，而不是直接信任它。这些建议也始终扎根于现实。Agent 的输出会对照自动化结果、用户反馈以及来自真实已修复告警的训练数据进行验证，而当模型无法自行得出准确结果时，就会引入人工介入。

最后一道保障在于执行时刻。AI 从不持有云凭证。相反，执行通过短期、租户范围的凭证在客户控制的信任下进行代理，运行在与规划工作的 Agent 相隔离的隔离环境中。包裹这一切的是人工治理：修复通过带有完整审计追踪的审批工作流流转，每一项 AI 能力在到达客户之前都会在内部得到验证。

数据安全与合规

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

敏感内容留在 AWS 内部

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

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

守护到达模型的内容

负载可能携带敏感细节，因此 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，可归因到发起调用的角色，而温度设为零的确定性解码可确保评分和规划在每次运行之间保持一致。故障处理也以同样的严谨性进行治理。每个服务都有一个带重驱动的输入队列、一个错误处理函数、一个死信队列，以及针对超时和 DLQ 深度的 CloudWatch 告警，并接入值班流程。故障被隔离且可观测，绝不会被静默丢弃。

结果与影响

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

对于典型客户，结果会很快显现，通常在 90 天内。

压缩和零问题数据来自 Tamnoon 的研究。这一模式是一致的，显示出更少的未解决暴露、远更少的人工工作，以及修复本身带来的零停机。

结论

构建一个能够对云发现进行推理的 agent 是简单的部分。构建一个你愿意信任其在生产环境中采取行动的 agent 才是困难的部分。Amazon Bedrock 是一项完全托管的服务，提供对高性能基础模型的访问，以及构建 agentic 应用的工具：编排、工具使用和护栏，通过单一 API 实现。这种组合在这里很重要，原因很具体：对生产云基础设施采取行动既需要强大的推理能力，也需要硬性的安全边界。

四件事使之成为可能：

• 你的暴露确实被关闭：Tamnoon 在实时云基础设施上运行，而不是在工单或工作流自动化上。积压会下降，而不是横向增长。
• 自主性可扩展且无生产风险：每个提议的操作都带有置信度评级。SAFE 操作可以自动执行，而 AWAITING DATA 或 RISKY 操作会引入 Tamnoon 的嵌入式云工程师。
• 运行在你已经购买的堆栈上：Tamnoon 在流行的 CNAPP 和云安全工具之上运行。你已付费的每个检测工具都开始产生回报，因为其发现最终被关闭。
• 团队容量可扩展而无需增长：快速、安全地采用前沿 AI 意味着每位分析师关闭更多暴露，而无需增加人员。

后续步骤

要开始使用类似架构，请考虑以下内容：

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

关于作者

Ishara Premadasa

Ishara 是 AWS Startups 团队的解决方案架构师，她帮助初创客户在 AWS 上以正确的架构构建和扩展。她专注于 AI/ML、数据智能和分析，帮助初创企业构建强大的数据基础并将生成式 AI 解决方案投入生产。工作之外，Ishara 喜欢户外活动，热爱旅行、阅读和烘焙。

Adi Milner

Adi 是 Tamnoon 的工程主管，领导工程和产品团队构建 AI 驱动的云安全和修复解决方案。拥有超过 20 年的软件工程和技术领导经验，他的工作涵盖云基础设施、分布式系统、开发者平台和 agentic AI。他热衷于将 AI 应用于复杂的工程和安全问题，并构建为客户带来可衡量价值的产品。

Maya Levine

Maya 是 Tamnoon 的产品和技术产品营销主管。Maya 此前在 Sysdig 领导产品管理，在此之前曾在 Check Point Software Technologies 担任安全工程、云技术营销和网络安全布道师角色。她经常在 AWS re:Invent 和 RSAC 等会议上演讲，热衷于构建安全团队信任其代表自己采取行动的 AI 产品。