Tamnoon 如何借助 Amazon Bedrock 构建 AI 驱动的云安全修复能力

关键云暴露问题的累积速度，往往快于安全团队的关闭速度。云原生应用保护平台（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 Agent 在 AWS 上基于事件驱动、无服务器架构运行，因此每一个阶段都可以独立扩缩容，并能够安全地发生故障。

Amazon Bedrock 上的智能体架构

该平台将工作委派给四类专用 Agent，每类 Agent 负责修复流水线中的不同阶段：

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

为什么选择 Amazon Bedrock

当 Tamnoon 团队着手构建 Tami 时，基础模型（FM）平台的选择将塑造后续的一切。Tamnoon 的修复 Agent 并不执行同一种工作。有些 Agent 执行深度调查推理，以理解安全发现的根本原因；另一些 Agent 处理高吞吐量验证，以快速、低成本地检查拟议修复方案；还有一些 Agent 审查生成的代码，在每项任务中权衡质量与成本。在不为每种模型分别拼接不同集成方案的情况下，为这些工作匹配合适的模型，是一项核心要求。

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

大规模运营开销也是作出这一决定的另一个因素。随着请求量增长，Tamnoon 希望避免自行构建和维护将流量分配至各区域容量的逻辑。Amazon Bedrock Cross-Region inference 可以自动完成这项工作。它会在既定地理边界内，将推理请求自动路由至最优 AWS 区域，在无需运行任何自定义路由代码的情况下维持吞吐量。

安全性是最后一项考量，对于一家云安全公司而言，这一点不容妥协。借助 Bedrock，推理在 Tamnoon 自有 AWS 环境内运行，并受 AWS Identity and Access Management（IAM）范围限定权限的控制。敏感客户数据永远不会离开信任边界。这让团队确信，为 Tami 提供基础支撑的平台符合 Tamnoon 对自有服务所坚持的同等标准。

Tamnoon 位于安全团队已经运行的检测工具下游。Wiz、CrowdStrike、Palo Alto Cortex、Upwind、SentinelOne、Orca 和 Cyera 等 CNAPP，以及 AWS Security Hub 和 Amazon GuardDuty 等云原生服务，是环境中问题来源的事实依据。Tamnoon 通过基于 API 的集成进行连接，并将发现标准化为通用格式，因此无论错误配置来自 Wiz 还是 GuardDuty，其表现形式都是一致的。检测工具仍然是基础，Tamnoon 则交付后续端到端的修复能力。

对于处理的每项发现，Tami 都会分配 SAFE、RISKY 或 AWAITING DATA 的修复置信度指标（Remediation Confidence Indicator，RCI）。该评级告诉团队哪些工作可以自动化，哪些工作需要先经过人工审查。

图 1：运行中的 Tamnoon

Tamnoon 的 AWS 架构

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

在这一环境中，Tamnoon 组合了两类计算能力。Amazon Elastic Kubernetes Service（Amazon EKS）运行仪表盘背后的常驻服务，而 AWS Lambda 则为收集发现、分析发现和执行修复的事件驱动工作提供支持。包括 Amazon EventBridge、Amazon Simple Queue Service（Amazon SQS）和 AWS Step Functions 在内的一组 AWS 消息传递与工作流服务负责协调这些步骤，使大量发现可以可靠地并行处理，不会因为一条异常记录而阻塞其他记录。

AI 层运行在 Amazon Bedrock 上。Amazon Bedrock AgentCore 是一个可使用任意框架或模型大规模构建、连接和优化 Agent 的平台，它为 Tamnoon 的 Agent 提供了一种受治理的行动方式，而非开放式访问权限。Amazon Bedrock Guardrails 则会在任何操作推进前审查请求和生成的代码。辅助服务负责平台的其余部分：托管数据库和缓存用于保存状态，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 中的 Supported models by AWS Region。由于 Bedrock 不会保留提示词或补全内容，也不会使用它们进行训练，客户数据从一开始就不会到达外部供应商。

即使工作负载扩展，这一边界仍然成立。Bedrock Cross-Region inference 会在美国地理边界内自动路由请求，从而提高应用程序可用的吞吐量。其底层计算同样保持私有。每项服务均作为连接至虚拟私有云（VPC）的 AWS Lambda 函数运行，部署在私有子网中，配置明确的安全组、无公共入站访问以及严格控制的出站访问。

守护进入模型的内容

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

Critical cloud exposures pile up faster than security teams can close them. Cloud-native application protection platforms (CNAPP), cloud providers, and posture scanners generate more findings than any team can triage, and risk accumulates in the gap between detected and fixed. Most findings sit untouched, not because they’re hard to fix. Someone must investigate context, identify the owner, confirm the fix won’t break production, and then do it at a volume that outpaces headcount.

In this post, we share how Tamnoon built Tami, an agentic cloud remediation orchestrator on Amazon Bedrock, to close that gap. Tami autonomously investigates findings ingested from CNAPP and cloud-native sources and assesses whether remediation is safe. It then generates and orchestrates the fix with guardrails and governance wherever a change touches a customer’s cloud. The approach drove an over 90 percent reduction in critical cloud exposure in 90 days with zero production issues.

About Tamnoon

Tamnoon is an AI-powered cloud security remediation platform that works alongside CNAPPs. Its AI assistant, Tami, helps human cloud security experts investigate, prioritize, and safely remediate misconfigurations and issues across customer environments in AWS, Azure, Google Cloud, and other cloud providers.

Tamnoon integrates with the CNAPPs and cloud-native tools teams already use and turns their findings into validated, production-safe fixes. Most of the work including investigation, prioritization, and remediation planning happens before anything touches a live environment, which is what makes automated remediation trustworthy at scale.

A security engineer can spend hours investigating a single finding. Often, it traces back to the same root cause as dozens of other alerts.

• Alert volume overwhelms headcount: CNAPPs and scanners generate thousands of findings. Teams can’t triage them all, so critical exposures sit unresolved while risk compounds for months.
• Investigation is manual and repetitive: Each finding requires context gathering on who owns the resource, what depends on it, whether the fix is safe. This eats hours of senior engineer time, repeated across every item in the backlog.
• Fear of production impact blocks automation: Teams hesitate to automate remediation because they can’t risk taking down production. Without confidence that a fix is safe, nothing moves.
• Reactive prioritization: Without a way to cluster related findings or score remediation confidence, teams work through alerts linearly rather than addressing root causes that resolve many issues at once.

Tamnoon’s solution addresses the full pipeline from finding ingestion to validated fix. The platform treats these challenges as interconnected rather than isolated problems.

Solution overview

Tamnoon takes you from initial finding to executing the fix. The platform ingests findings from CNAPP, Cloud Security Posture Management (CSPM) providers, and other security tools and normalizes them into a unified schema. It then enriches them with asset and exposure context and prioritizes them. From there, the agentic layer takes over using a set of specialized AI agents, each running in an event-driven, serverless architecture on AWS, so every stage scales independently and fails safely.

Agentic architecture on Amazon Bedrock

The platform delegates work to four specialized agents, each responsible for a distinct phase of the remediation pipeline:

• An investigation agent draws on training from millions of real customer cloud environments to determine context, filters that context through a large language model (LLM)-as-a-judge validation layer. It reasons through the remediation goal, operational scope, and cloud-provider-specific verification, producing read-only investigation steps and a complete investigation plan.
• A safety-scoring agent builds an evidence chain per asset, combining automated verification results with analyst findings. It classifies each finding’s remediation as SAFE, RISKY, or AWAITING DATA with a deliberately conservative bias. When in doubt, it downgrades.
• A remediation agent activates only for findings that the safety agent has deemed safe. It reasons through ordering, dependencies, and conditions, then produces a remediation plan in which every step follows a backup, remediate, and verify structure and includes rollback guidance.
• A code-generation agent turns plan steps into executable remediation, but only after an input guardrail screens for relevance and prompt injection. Every artifact passes an automated generate-and-review loop in which a separate reviewer agent must approve the output.

Why Amazon Bedrock

When the Tamnoon team set out to build Tami, the choice of foundation model (FM) platform was going to shape everything that followed. Tamnoon’s remediation agents don’t all do the same kind of work. Some perform deep investigative reasoning to understand the root cause of a security finding. Others handle high-volume validation, checking proposed fixes quickly and cheaply. Still others review generated code, balancing quality against cost on every task. Matching each of these jobs to the right model, without stitching together a different integration for each one, was a core requirement.

That requirement is what made Amazon Bedrock the natural fit. Through a single API, each agent can call the foundation model best suited to its task. The most capable models handle the hardest reasoning. More efficient models take on the repetitive, high-throughput work. Review-focused models optimize the trade-off between output quality and cost. Because it’s one integration rather than many, models can be swapped or upgraded as the landscape evolves, without re-plumbing the architecture each time.

Operational overhead at scale was another factor in the decision. As request volume grew, Tamnoon wanted to avoid building and maintaining its own logic to distribute traffic across regional capacity. Amazon Bedrock Cross-Region inference handles this automatically. It automatically routes inference requests to the optimal AWS Region within a defined geographic boundary, maintaining throughput without requiring any custom routing code to operate.

Security was the final consideration, and for a cloud security company it was non-negotiable. With Bedrock, inference runs inside Tamnoon’s own AWS environment under AWS Identity and Access Management (IAM)-scoped permissions. Sensitive customer data never leaves the trust boundary. That gave the team confidence that the platform underpinning Tami met the same standard Tamnoon holds its own service to.

Tamnoon sits downstream of the detection tools security teams already run. CNAPPs like Wiz, CrowdStrike, Palo Alto Cortex, Upwind, SentinelOne, Orca, and Cyera along with cloud-native services like AWS Security Hub and Amazon GuardDuty are the source of truth for what’s wrong in the environment. Tamnoon connects through API-based integrations and normalizes findings into a common format, so a misconfiguration looks the same whether it came from Wiz or GuardDuty. The detection tools remain the foundation. Tamnoon delivers the end-to-end remediation that follows.

For every finding it works, Tami assigns a Remediation Confidence Indicator (RCI) of SAFE, RISKY, or AWAITING DATA. That rating tells teams what can be automated and what needs human review first.

Figure 1: Tamnoon in action

Tamnoon AWS architecture

Tamnoon runs entirely within its own AWS accounts, isolated per environment. Users access the platform through a single secure entry point built on Amazon API Gateway, with encryption managed by AWS Certificate Manager and sign-in handled by Amazon Cognito. Everything behind that entry point runs in private networks across multiple Availability Zones, so the core platform is never directly exposed to the internet.

Inside that environment, Tamnoon combines two kinds of compute. Amazon Elastic Kubernetes Service (Amazon EKS) runs the always-on services behind the dashboard, while AWS Lambda powers the event-driven work of collecting findings, analyzing them, and executing remediations. A set of AWS messaging and workflow services, including Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), and AWS Step Functions, coordinate these steps so large volumes of findings are processed reliably and in parallel, with no single bad record stalling the rest.

The AI layer runs on Amazon Bedrock. Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale with any framework or model, gives Tamnoon’s agents a governed way to take action instead of open-ended access. Amazon Bedrock Guardrails then review both the request and the generated code before anything moves forward. Supporting services handle the rest of the platform: managed databases and caching for state, Amazon Simple Storage Service (Amazon S3) for playbooks and artifacts, and AWS Secrets Manager for credentials, so sensitive keys never live in application code.

On the customer side, everything to the left of the AWS Cloud boundary is what customers connect into Tamnoon. They can link their own AWS, Azure, and Google Cloud accounts, plug in the security tools their findings come from, and connect the destinations where they want outcomes delivered, such as Slack, Jira, ServiceNow, and GitHub.

Figure 2: Tamnoon AWS architecture

How Tamnoon maintains zero production issues

Zero production issues is a reality for Tamnoon’s customers, and it is no accident. Autonomy at Tamnoon sits inside a defense-in-depth safety architecture, where each layer assumes the one before it might miss something.

It starts before any fix is even drafted. No remediation is written until an independent safety assessment, focused on scope and deliberately biased toward caution, concludes that the change is safe to make. From there, the platform draws a hard line between reading and writing. Investigation steps are validated as strictly read-only, so the work of understanding a problem can never alter it. Only the remediation path is allowed to change anything, and every change it makes carries its own backup, verification, and rollback steps.

That discipline is reinforced by constant self-critique. Each generation step is paired with a reflection step that checks the output and feeds its critique back into regeneration, so the system is always reviewing its own work rather than trusting it outright. Those recommendations are also kept grounded in reality. Agent output is validated against automation results, user feedback, and training data drawn from real fixed alerts, and when the model cannot reach an accurate result on its own, a human is brought into the loop.

The final safeguard is at the moment of execution. The AI never holds cloud credentials. Instead, execution is brokered through short-lived, tenant-scoped credentials under customer-controlled trust, running in an isolated environment kept separate from the agents that plan the work. Wrapping all of this is human governance: remediations flow through an approval workflow with a full audit trail, and every AI capability is proven internally before it ever reaches a customer.

Data security and compliance

Tami reasons over sensitive customer data: alert payloads, resource identifiers, misconfigurations, and remediation context. That data must stay inside the AWS trust boundary, run with least privilege, and stay auditable. Standardizing on Amazon Bedrock makes that possible.

Sensitive content stays inside AWS

Every Tami workload invokes Anthropic Claude on Amazon Bedrock through the ChatBedrockConverse interface, rather than calling a third-party LLM endpoint. That single choice puts the full AI supply chain under one AWS native service, which has real consequences for how customer data is handled. Inference runs entirely within Tamnoon’s own AWS account in US commercial Regions, so data never leaves AWS. For information about model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock. Because Bedrock doesn’t retain or train on prompts or completions, customer data never reaches an external vendor in the first place.

That boundary holds even as workloads scale. Bedrock Cross-Region inference automatically routes requests to Regions within the US geographic boundary, increasing the throughput available to the application. The compute behind it stays private as well. Each service runs as an AWS Lambda function attached to a virtual private cloud (VPC), in private subnets with an explicit security group, no public ingress, and tightly controlled egress.

Guarding what reaches the model

Payloads can carry sensitive detail, so Tami applies Amazon Bedrock Guardrails to every request and response. The policy is enforced at the Bedrock layer, which means it covers all three services uniformly and no individual function’s prompt logic can bypass it. That single enforcement point does several things at once.

First, it protects sensitive data. PII and secret-like content is masked before it is ever persisted or surfaced, so nothing sensitive lingers where it doesn’t belong. It also guards against prompt injection, which matters because Tami reasons over untrusted findings that an unauthorized user could influence. Filtering at the guardrail layer stops a crafted payload from hijacking the model or exfiltrating context. Finally, denied topics and content filters keep the model’s output scoped to security remediation and nothing else. Every intervention is logged alongside AWS CloudTrail, giving enterprise customers a clear trail of governance evidence.

Least-privilege access

Access across the platform runs through a dedicated per-service IAM execution role, so each function can reach only what it needs and nothing more. That principle is easiest to see in how Tami touches Amazon Bedrock. Its only Bedrock permission is bedrock:InvokeModel, scoped to specific inference-profile and foundation-model ARNs. It has no ability to manage, train, or export models.

The same discipline extends to every other dependency. Access to AWS Secrets Manager is limited to the two secrets a function actually uses, SQS access is confined to its own input queue, and Amazon CloudWatch writes are restricted by namespace. There are no broad, catch-all roles anywhere in the design. Functions attach only to the managed AWSLambdaBasicExecutionRole and AWSLambdaVPCAccessExecutionRole policies, and nothing wider than that.

Multi-tenant isolation and governance

Keeping tenants separated is a foundational requirement, and it is enforced from the very first call. Service-to-service calls use OAuth2 client credentials through Cognito, scoped per application, and work is processed one SQS message at a time with its tenant context attached. As a result, a single invocation only ever touches one tenant’s data.

Much of this assurance comes from treating the entire platform as code. IAM policies, network placement, model IDs, and alarms all live in versioned AWS CloudFormation and SAM templates, so every permission and model version is reviewable in source control with no manual console changes to drift out of sync. Model versions in particular are pinned to dated identifiers, for example claude-sonnet-4-5-20250929, which means a model change is always an explicit, reviewed code change rather than a silent upgrade.

That transparency carries through to runtime. Every inference call lands in AWS CloudTrail, attributable to the invoking role, and deterministic decoding with temperature set to zero keeps scoring and planning consistent from one run to the next. Failure handling is governed with the same rigor. Each service has an input queue with redrive, an error-handler function, a dead-letter queue, and CloudWatch alarms on timeouts and DLQ depth wired to on-call. Failures are contained and observable, and never silently dropped.

Results and impact

Tami has analyzed more than 14 million cloud alerts across Tamnoon’s customer base, a number tracked in Tamnoon’s 2026 State of Cloud Remediation report. The decisions Tami makes reflect patterns learned from these real-world environments.

For a typical customer, the results show up fast, usually within 90 days.

Metric	Before	After
Critical cloud exposure	Compounds for months as alerts outpace headcount	Up to 90% reduction in 90 days (source)
Remediation efficiency	Thousands of raw alerts, no clear prioritization	Up to 100x efficiency through root-cause clustering (source)
Production issues	Teams avoid automation because of risk	Zero production issues across millions of workloads
Engineer time	Hours per finding, repeated across backlog	13,000+ hours saved per week across customer base (source)

The compression and zero-issue figures come from Tamnoon’s research. The pattern is consistent, showing fewer open exposures, far less manual work, and no downtime from the fixes themselves.

Conclusion

Building an agent that can reason about a cloud finding is the straightforward part. Building one you’d trust to act on production is the hard part. Amazon Bedrock is a fully managed service that provides access to high-performing foundation models along with the tooling to build agentic applications: orchestration, tool use, and guardrails, through a single API. That combination matters here for a specific reason: acting on production cloud infrastructure demands both strong reasoning and hard safety boundaries.

Four things make that possible:

• Your exposures actually close: Tamnoon operates on live cloud infrastructure, not on tickets or workflow automation. The backlog goes down instead of sideways.
• Autonomy scales without production risk: Every proposed action carries a confidence rating. SAFE actions can auto-execute while AWAITING DATA or RISKY actions pull in Tamnoon’s embedded cloud engineers.
• Runs on the stack you already bought: Tamnoon works on top of popular CNAPPs and cloud security tooling. Every detection tool you already pay for starts paying off because its findings finally get closed.
• Team capacity scales without growing: Fast, safe adoption of frontier AI means more exposures closed per analyst, with no added headcount.

Next steps

To get started with a similar architecture, consider the following:

---

About the authors

Ishara Premadasa

Ishara is a Solutions Architect on the AWS Startups team, where she helps startup customers build and scale with the right architecture on AWS. She specializes in AI/ML, Data Intelligence, and Analytics, helping startups build strong data foundations and bring generative AI solutions into production. Outside of work, Ishara enjoys the outdoors and loves travel, reading, and baking.

Adi Milner

Adi is Head of Engineering at Tamnoon, where he leads engineering and product teams building AI-powered cloud security and remediation solutions. With more than 20 years of experience in software engineering and technology leadership, his work spans cloud infrastructure, distributed systems, developer platforms, and agentic AI. He is passionate about applying AI to complex engineering and security problems and building products that deliver measurable value to customers.

Maya Levine

Maya is Head of Product and Technical Product Marketing at Tamnoon. Maya previously led product management at Sysdig, and before that held security engineering, cloud technical marketing, and cybersecurity evangelist roles at Check Point Software Technologies. A frequent speaker at conferences such as AWS re:Invent and RSAC, she is passionate about building AI products that security teams trust to act on their behalf.