关键云暴露的积累速度超出了安全团队的修复能力。云原生应用保护平台（CNAPP）、云提供商和态势扫描器生成的发现数量远超任何团队的分诊能力，风险在“已检测到”和“已修复”之间的空隙中不断累积。大多数发现被搁置，并不是因为难以修复。而是必须有人调查上下文、确定负责人、确认修复不会破坏生产环境，然后以超越人力的规模去执行。
在这篇文章中，我们分享 Tamnoon 如何在 Amazon Bedrock上构建 Tami（一个代理式云修复编排器）来弥合这一空隙。Tami 自主调查从 CNAPP 和云原生来源摄取的发现，并评估修复是否安全。然后，只要变更涉及客户的云环境，它就会在有防护措施和治理的情况下生成并编排修复。该方法 在 90 天内将关键云暴露减少了超过 90% 在90天内减少了关键云暴露，且零生产问题。
关于 Tamnoon
Tamnoon 是一个与 CNAPP 协同工作的 AI 驱动云安全修复平台。其 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的修复代理并非都从事相同类型的工作。有些执行深度调查推理，以了解安全发现（finding）的根本原因。有些处理高容量验证，快速且低成本地检查提议的修复方案。还有些审查生成的代码，在每个任务中权衡质量与成本。将这些工作各自匹配到合适的模型，而无需为每一个拼接不同的集成，这是一项核心需求。
正是这一需求使Amazon Bedrock成为自然之选。通过单一API，每个代理都可以调用最适合其任务的基础模型。能力最强的模型处理最困难的推理。更高效的模型承担重复性、高吞吐量的工作。以审查为重点的模型则优化输出质量与成本之间的权衡。因为这是一个集成而非多个集成，随着格局演变，模型可以被替换或升级，而无需每次都重新调整架构。
大规模运营开销是决策的另一个因素。随着请求量增长，Tamnoon希望避免构建和维护自己的逻辑来在区域容量之间分配流量。Amazon Bedrock Cross-Region推理可自动处理此事。它会自动将推理请求路由到定义的地理边界内的最佳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的自主性被置于纵深防御的安全架构之内，其中每一层都假设前一层可能会遗漏某些东西。
这一切在任何修复方案起草之前就已开始。在一项独立的安全评估得出变更可以安全进行的结论之前，不会编写任何修复方案，该评估专注于范围并刻意偏向谨慎。从那里开始，平台在读取和写入之间划出一条硬性界线。调查步骤被验证为严格只读，因此理解问题的工作绝不会改变问题本身。只有修复路径被允许进行更改，并且它所做的每项更改都带有自己的备份、验证和回滚步骤。
这种纪律通过持续的自我批评得到强化。每一代生成步骤都配有一个反思步骤，用于检查输出并将其批评意见反馈到重新生成中，因此系统始终在审查自己的工作，而不是盲目信任它。这些推荐意见也始终立足现实。智能体的输出会根据自动化结果、用户反馈以及来自真实已修复警报的训练数据进行验证，当模型无法独自得出准确结果时，会引入人工参与。
最后一道保障位于执行时刻。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，范围限定于特定的 inference-profile 和 foundation-model 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 的客户群体中分析了超过 14 million 条云警报，这一数字记录在 Tamnoon 的 2026 State of Cloud Remediation 报告中。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 天内可以消除多少关键云暴露风险。