How Tamnoon built AI-powered cloud security remediation with Amazon Bedrock

extract

Artificial Intelligence How Tamnoon built AI-powered cloud security remediation with Amazon 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. Cloud security remediation challenges 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. How Tamnoon integrates with CNAPPs and cloud security tools 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. 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. 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. 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: - Explore Amazon Bedrock and the models available through it. - Review the Amazon Bedrock documentation to plan your architecture. - Book a demo with Tamnoon to find out how much of your critical cloud exposure you can close in the next 90 days.