Tamnoon Amazon Bedrock Remediation Moves AI From Alerts to Cloud Fixes

Tamnoon says its Amazon Bedrock remediation system helped customers reduce critical cloud exposure by more than 90% within 90 days, without production incidents. That claim moves agentic AI into a far less forgiving arena than chatbots or ticket summaries. Tami, the company’s cloud remediation orchestrator, can investigate security findings and prepare or execute guarded changes against live infrastructure.

The important change is not another artificial intelligence layer for detecting misconfigurations. Cloud-native application protection platforms, or CNAPPs, already generate extensive findings across workloads, identities, networks, and data. Tamnoon is trying to automate the harder work that follows detection: gathering context, identifying root causes, judging safety, and closing exposures.

That puts the company against a familiar security operating model. Tools from Wiz, CrowdStrike, Palo Alto Networks, Orca Security, SentinelOne, and cloud providers identify problems. Human engineers then determine which findings matter and whether a proposed fix might break production. Tamnoon’s bet is that constrained agents can safely compress that manual gap without replacing the detection platforms underneath them.

Tamnoon Amazon Bedrock Remediation Targets the Closure Gap

Tamnoon is positioning Tami as an execution layer between security findings and verified fixes, not as another alert generator.

AWS and Tamnoon detailed the architecture in an October 14, 2026 technical account. Tami ingests findings from CNAPP products, cloud posture tools, Amazon GuardDuty, and AWS Security Hub. It converts those records into a common internal format before enriching them with asset, ownership, dependency, and exposure context.

This normalization matters because every detection product describes risk differently. A public storage resource, excessive permission, or exposed service can arrive with different fields and severity labels. Tami needs a consistent representation before its agents can compare findings, group related issues, or reason about remediation.

The system then prioritizes findings and looks for shared root causes. One configuration error can generate many downstream alerts across multiple resources. Addressing that cause can therefore close more risk than processing each alert independently.

Tamnoon calls the result a remediation confidence indicator. Each finding receives one of three classifications: SAFE, RISKY, or AWAITING DATA. The label determines whether automation can proceed or whether a human must investigate further.

This is a consequential distinction. Tami does not treat an uncertain answer as permission to act. Tamnoon says its safety process deliberately downgrades remediation when evidence is incomplete.

The company reports that Tami has analyzed more than 14 million cloud alerts. Its 2026 remediation study specifies 14.86 million detections across hundreds of enterprise environments and ten scanners. The study also says 53% of all detected issues remained open, compared with 41% in the previous study.

Those figures come from Tamnoon’s own dataset rather than independent industry measurement. They still explain the product’s target. The problem is no longer just finding exposures. It is converting detection into a change that operators can safely make.

Tamnoon says a typical engagement can reduce critical exposure by up to 90% in 90 days. It also reports as much as a 100-fold efficiency improvement through root-cause clustering. Across its customer base, the company attributes more than 13,000 saved engineering hours each week to the approach.

These results should be read as vendor-reported outcomes. AWS’s article was co-authored by two Tamnoon executives, and no independent auditor is identified for the operational claims. The figures describe observed customer results, not a guaranteed benchmark for every cloud environment.

Nevertheless, the architecture shows a significant shift in security automation. Earlier systems commonly opened tickets, suggested commands, or ran predefined playbooks. Tami uses multiple agents to assemble evidence, decide whether automation is appropriate, construct a plan, and review generated remediation code.

That progression creates the central tension. Greater autonomy can shorten exposure windows, but every additional action creates another path toward an unintended production change. Tamnoon’s design therefore depends less on unconstrained intelligence than on strict limits around what each component can do.

Four Agents Divide Investigation, Safety, Planning, and Code

Tami’s core mechanism is separation of duties, with four agents performing distinct jobs instead of one model controlling the entire remediation process.

The investigation agent starts with read-only work. It gathers the context needed to understand the resource, the remediation objective, and cloud-specific validation requirements. Tamnoon says this agent draws on patterns from millions of customer environments.

A large language model acting as a judge then filters the gathered context. This review produces a structured investigation plan rather than an immediate infrastructure change. Keeping this stage read-only limits the consequences of incorrect reasoning.

The safety-scoring agent builds an evidence chain for each affected asset. It combines automated checks with findings from analysts and the investigation process. It then assigns the SAFE, RISKY, or AWAITING DATA classification.

Only findings classified as SAFE can reach the remediation agent. That agent reasons about dependencies, ordering, and conditions surrounding the proposed change. Every planned step follows a backup, remediate, and verify sequence, with rollback guidance attached.

A fourth agent converts approved plan steps into executable code. Before generation, an input guardrail checks relevance and screens for prompt injection. A separate reviewing agent must then approve each generated artifact.

This division does not eliminate model errors. It reduces the chance that one incorrect output immediately becomes a privileged action. A failure must pass several controls before it can affect a customer environment.

The process also uses reflection loops. Generation steps receive a separate critique, and that feedback can trigger regeneration. Tamnoon validates recommendations against automation results, user feedback, and previously fixed alerts.

Human intervention remains part of the design. When a model cannot reach a sufficiently confident result, the workflow routes the case to an operator. RISKY and AWAITING DATA findings therefore represent controlled refusals, not incomplete automation.

That behavior is important because security agents encounter ambiguous evidence. A resource can appear unused while supporting an infrequent process. A permission can look excessive while serving an emergency workflow. A network rule can seem redundant until a regional failover occurs.

A safe system must distinguish uncertainty from low risk. Tamnoon’s architecture tries to encode that distinction through confidence states, evidence requirements, and escalation. Its most meaningful output may sometimes be a documented decision not to act.

This design resembles traditional separation of duties in security engineering. The agent proposing a change is not the only component evaluating that change. Planning, review, and execution occupy different stages, each with its own controls.

The model layer runs through Amazon Bedrock, which lets Tamnoon assign different models to different tasks through one service interface. More capable models can handle complex investigation. Smaller models can process repetitive validation or review tasks with lower operational overhead.

Model flexibility matters because cloud remediation includes several workloads with different accuracy and latency requirements. A single model might be unnecessary for routine checks and insufficient for a complicated dependency graph. Bedrock lets the company change those assignments without rebuilding every integration.

Tamnoon also pins models to dated identifiers. A model change becomes an explicit infrastructure update rather than an unannounced behavioral shift. That practice can support testing, rollback, and auditability when model providers release revisions.

The company sets decoding temperature to zero for scoring and planning. That setting aims to make outputs more consistent, although deterministic decoding does not guarantee factual correctness. Repeated inputs can become more predictable while still producing an incorrect decision.

For engineering teams considering similar agents, the transferable lesson is architectural. Reliable automation depends on traceable context, constrained roles, and explicit state transitions. Maintaining a searchable technical knowledge base can also help teams preserve the evidence behind operational decisions.

The Real Contest Is Autonomous Action Versus Controlled Refusal

Tamnoon’s primary challenge is proving that an agent can refuse unsafe work as reliably as it completes routine remediation.

Cloud security platforms have spent years improving visibility. Their dashboards correlate vulnerabilities, excessive permissions, exposed services, attack paths, and sensitive data. Better prioritization helps analysts find serious issues, but it does not automatically remove them.

Tamnoon sits downstream from that detection layer. Wiz, CrowdStrike, Palo Alto Cortex, Upwind, SentinelOne, Orca, Cyera, GuardDuty, and Security Hub remain sources of truth. Tami consumes their findings and attempts to carry remediation through completion.

That makes the relationship partly complementary and partly competitive. Tamnoon does not need to replace a CNAPP to create value. However, successful remediation can shift customer attention from alert quality toward closure rates, evidence, and time-to-resolution.

Cloud providers are also moving closer to that workflow. AWS Security Hub now describes remediation plans that group exposures sharing a root cause. Those plans can include affected scope, reversibility, risk, automation level, and human-review requirements.

The overlap reveals where the market is heading. Security buyers increasingly expect more than prioritized findings. They want a defensible path from detection to a verified change, including evidence that the change did not create another problem.

Tamnoon’s differentiation rests on orchestration across scanners and clouds. Its platform can connect customer environments in AWS, Azure, and Google Cloud while using a common remediation workflow. That cross-platform position could appeal to enterprises running several security products.

Yet the hardest comparison is not Tamnoon against a named vendor. It is autonomous action against controlled refusal. A system that executes every plausible fix would look productive until one change causes an outage or weakens another control.

Conversely, an agent that escalates nearly everything remains a ticket-enrichment tool. It can reduce investigation time, but it does not meaningfully close the operational backlog. The commercial value depends on how many findings reach safe automation without loosening approval standards.

Tamnoon says it moved from a human-led model toward greater autonomy during 2025. The company reported that its platform eventually handled all prioritization and investigation. Humans remained responsible for validating remediation actions, resolving edge cases, and training the system on new patterns.

The next stage involves more execution with less intervention for known and repeatable scenarios. This does not mean every finding should become autonomous. It means the system must recognize cases matching previously validated patterns while isolating novel situations.

That recognition problem is harder than generating a command. Cloud environments drift, dependencies change, and identical resource types can serve very different business functions. Historical success provides useful evidence, but it cannot fully describe the consequences of the next change.

Tamnoon therefore needs credible refusal behavior. An AWAITING DATA decision should state what evidence is missing. A RISKY decision should explain which dependency or blast radius prevents automation. Operators must be able to challenge those conclusions.

Audit trails become part of the product, not merely compliance records. Security teams need to know which evidence informed an action, which model version participated, and which approval allowed execution. They also need records of proposed changes that the system rejected.

This requirement makes explainability operational. A polished natural-language explanation is insufficient if it cannot connect to observed resources and deterministic checks. The evidence chain must survive review by engineers who understand the affected environment.

If Tamnoon can maintain that standard, it can make existing detection investments more useful. If refusal quality weakens as automation expands, the platform risks recreating alert fatigue in another form. Operators would need to review agent decisions as carefully as they once reviewed scanner findings.

Amazon Bedrock Supplies Boundaries Around Model Reasoning

Amazon Bedrock matters because Tamnoon needs governed model access and infrastructure controls, not simply text generation.

Tamnoon invokes Anthropic Claude models through Bedrock’s Converse interface. The company says inference occurs within its AWS environment in United States commercial Regions. Cross-Region inference can route requests within that geographic boundary when capacity changes.

AWS states that Bedrock does not store or log prompts and completions, use them for model training, or distribute them to model providers. Its AI security architecture also describes tenant isolation and encryption for content at rest and in transit.

That boundary matters because Tami processes alert payloads, resource identifiers, configuration details, and remediation context. These records can reveal defensive controls or sensitive architecture. Sending them through an unmanaged external workflow would add material data exposure.

Tamnoon applies Amazon Bedrock Guardrails to requests and responses. Guardrails are policy controls that can filter sensitive information, prohibited topics, harmful content, and prompt attacks. They operate around the foundation model rather than relying only on instructions inside a prompt.

Prompt injection deserves specific attention. Tami ingests findings from external systems, and those payloads should be treated as untrusted data. An attacker who influences a resource name or alert field might attempt to insert instructions that manipulate an agent.

AWS documents prompt attack filters for jailbreaks, instruction overrides, and attempts to expose confidential prompts. However, the documentation also notes an important limitation: tool results are not automatically evaluated by that filter.

This qualification matters for any claim that guardrails solve prompt injection. Protection depends on correctly identifying and tagging untrusted content. Every path that carries scanner output, retrieved context, tool results, or inter-agent messages needs deliberate validation.

Tamnoon says guardrails screen inputs before its code-generation agent runs. Generated artifacts also pass a review loop. Those controls strengthen the design, but their effectiveness depends on configuration, testing, and continuous adaptation to new attack patterns.

The broader AWS architecture adds conventional security boundaries. API Gateway provides the external entry point, Certificate Manager handles transport encryption, and Cognito manages authentication. Core components run in private networks across multiple Availability Zones.

Amazon EKS operates the persistent services supporting the dashboard. AWS Lambda runs event-driven tasks for collecting findings, analyzing them, and executing remediation workflows. EventBridge, SQS, and Step Functions coordinate work across independently scaling components.

Queues help contain failures. Tamnoon assigns services their own input queues, redrive behavior, error handlers, and dead-letter queues. CloudWatch alarms monitor timeouts and dead-letter queue depth, allowing failed records to remain visible.

Infrastructure definitions live in version-controlled CloudFormation and AWS Serverless Application Model templates. Permissions, model identifiers, network placement, and alarms therefore pass through source control. This limits configuration drift from manual console changes.

Least-privilege access is another essential control. Each service receives a dedicated IAM execution role. Model-facing functions can invoke specified inference profiles and models, but they cannot manage, train, or export those models.

The AI agents never retain customer cloud credentials. At execution time, a separate broker obtains short-lived, tenant-scoped credentials under customer-controlled trust. Execution occurs in an isolated environment outside the agents that planned the work.

This separation limits credential exposure and reduces persistent access. It also creates a boundary between deciding what to change and possessing the authority to change it. That pattern should be standard for agents operating against production systems.

Tenant context travels with each SQS message, and each invocation processes only one tenant. Service-to-service calls use OAuth2 client credentials scoped per application. CloudTrail records inference activity under the responsible execution role.

None of these components makes model reasoning infallible. Their purpose is to limit the impact of failure and preserve evidence. Tamnoon’s architecture treats the model as one uncertain component inside a larger control system.

The Zero-Incident Claim Needs Independent Pressure Testing

Tamnoon’s reported results are notable, but the available evidence does not establish how the system performs across every customer, exposure class, or autonomy level.

AWS says the approach produced zero production issues across millions of workloads. Tamnoon has separately reported zero incidents across thousands of remediations. The company also says customers reduced critical and high alerts by 66% to 92%.

Those numbers describe an encouraging operating history. They do not reveal the denominator for fully autonomous executions, the distribution of change types, or the number of cases escalated to humans. Those details determine how broadly the result applies.

A system can preserve an excellent safety record by automating only simple, reversible cases. That would still provide value, especially at high volume. It would not establish that agents can safely handle complex identity, network, or data-layer changes.

The phrase “zero production issues” also requires a precise definition. It might exclude near misses, reverted changes, delayed failures, or security regressions discovered later. Public materials do not provide enough detail to evaluate those categories.

Root-cause clustering presents another measurement challenge. Collapsing related alerts can produce major efficiency gains, but the resulting ratio depends on scanner behavior and counting methods. A hundred findings resolved through one change do not equal a hundred independent remediation decisions.

The 90-day exposure reduction likewise depends on starting conditions. Customers with large inherited backlogs may experience rapid early gains. Mature programs with fewer repetitive issues might show smaller percentage changes despite strong performance.

Tamnoon acknowledges that its impact figures come from its own research. Buyers should therefore request customer-specific evidence. Useful validation would include the share of findings in each confidence state, approval rates, rollback frequency, and post-change verification failures.

Teams should also test indirect prompt injection. Findings can contain attacker-controlled labels, metadata, repository content, or logs. Security evaluators should verify that malicious text cannot redirect the investigation agent or influence generated remediation.

Credential controls need their own assessment. Short-lived access reduces persistence, but scope remains critical. Reviewers should inspect which actions execution roles permit, how tenant identity is enforced, and whether emergency revocation works.

Model updates introduce another risk. Tamnoon’s pinned identifiers make changes reviewable, which is better than silent upgrades. Still, every upgrade needs regression testing against historical edge cases, refusal decisions, and adversarial payloads.

Human oversight can also become a bottleneck. If analysts automatically approve recommendations because the queue is large, a formal approval step offers limited protection. Interfaces should expose evidence clearly enough to support meaningful review.

Amazon Bedrock Guardrails should not be treated as a complete security boundary. AWS advises layered controls because prompt defenses remain probabilistic. Tamnoon’s read-only investigation, independent review, isolated execution, and rollback requirements are therefore more important together.

Third-party assessment would strengthen the story. Independent measurement could define incidents, classify autonomous actions, and compare remediation quality against experienced engineers. It could also evaluate whether closed findings remain closed after environment changes.

The central claim is credible as a reported customer outcome, not as a universal guarantee. Tamnoon has published a detailed architecture and measurable results. The next burden is showing that those results persist as autonomy and workload complexity increase.

Three Signals Will Show Whether Agentic Remediation Can Scale

The next test is whether Tamnoon can expand autonomous execution while preserving refusal quality, independent evidence, and durable fixes.

The first signal is the distribution of SAFE, RISKY, and AWAITING DATA decisions. A rising SAFE share would suggest Tami is recognizing more repeatable patterns. That result only strengthens the case if rollback rates and post-change incidents remain low.

A falling escalation rate without transparent safety metrics would weaken confidence. Buyers need both productivity and restraint. Tamnoon should disclose how frequently humans override classifications and which exposure classes remain outside autonomous execution.

The second signal is independent validation of remediation outcomes. Customer studies, external assessments, or clearly documented methodologies could test the reported exposure reductions. The strongest evidence would separate autonomous fixes from human-approved and human-executed changes.

Durability should be part of that validation. A finding that reappears after deployment was not fully resolved. Measurements should distinguish permanent root-cause correction from temporary suppression, exception handling, or scanner-state changes.

The third signal is competitive movement from CNAPP vendors and cloud providers. Security Hub’s remediation plans already show AWS moving beyond isolated findings. Detection vendors can add deeper planning, execution, and verification to their existing platforms.

If those vendors standardize evidence-backed remediation, Tamnoon’s market will grow while becoming more contested. Its cross-tool position could remain valuable because customers rarely use one scanner. However, integrations alone will not protect its differentiation.

Tamnoon will need to show that its evidence chain produces safer decisions across heterogeneous environments. It must also prove that customers can change scanners without rebuilding remediation knowledge. Persistent operational learning could become more defensible than model access.

Amazon Bedrock gives Tami governed access to models and AWS-native controls. It does not decide whether an infrastructure change is correct. That judgment emerges from context gathering, deterministic checks, conservative classification, approval, and verification.

For security leaders, the immediate question is practical: which remediation classes are repetitive, reversible, and observable enough for guarded automation? Those cases provide the best starting point. They also produce the evidence needed before expanding authority.

Teams evaluating Tamnoon Amazon Bedrock remediation should request decision records, refusal examples, credential scopes, and rollback data. They should test the system against their own findings rather than generalized demonstrations. Most importantly, they should measure exposures that remain closed after the automation runs.

Agentic cloud security will not be judged by how convincingly an AI explains a fix. It will be judged by whether the exposure disappears, production stays healthy, and every decision remains auditable. Tamnoon has presented a serious architecture for that test. Its next results must show that safety continues scaling with autonomy.