Tamnoon’s AI Cloud Remediation on Bedrock

An AWS Machine Learning Blog case study published on October 14, 2026 describes Tamnoon’s Tami as an agentic cloud-security remediation orchestrator built on Amazon Bedrock. AWS reports that the customer solution reduced critical cloud exposure by more than 90% in 90 days with no production issues. That is a reported case-study result, not an independently verified benchmark or a promise that another environment will achieve the same outcome. The broader lesson is how to move from a security finding to a reviewed, bounded and verifiable fix.

Why cloud remediation is difficult

Cloud security tools can produce many findings, but a finding is not always a complete instruction for what to change. One misconfiguration may affect several resources, a resource may support a production service, and an apparently simple fix can break access or traffic if the surrounding dependencies are unknown. Teams often spend more time collecting context, finding the owner and validating a proposed change than they spend applying the change itself.

Automating the investigation and preparation steps can reduce repetitive work. Automatically changing production resources without controls can create a different problem: an agent may act on incomplete evidence, choose the wrong resource or make a change whose side effects are not obvious from the finding alone.

What the AWS case study reports

AWS describes Tami as an orchestration layer that uses AI to investigate cloud security findings, assess remediation safety and help generate and coordinate fixes. The case study connects this approach with cloud-native and cloud-security findings. The reported reduction in critical exposure is an outcome attributed to the customer solution; the article does not establish that the same workflow, controls or results will apply to every organization.

For teams designing a similar system, separate what the model recommends from what the remediation engine is allowed to execute. The model can summarize evidence, identify likely root causes and propose a plan. A deterministic policy layer should decide whether the plan is permitted, whether approval is required and which exact API operations can run.

The case study describes four specialized agents rather than one unrestricted model. It also says Amazon Bedrock AgentCore provides a governed way for the agents to use tools, while Bedrock Guardrails reviews requests and generated code before the next stage. An investigation agent gathers context and produces read-only steps. A safety-scoring agent classifies each finding as SAFE, RISKY or AWAITING DATA. The remediation agent activates only for findings marked SAFE and creates a plan with backup, remediation, verification and rollback guidance. A code-generation agent turns approved plan steps into executable changes, with an independent reviewer checking the generated artifact.

This separation matters because an agent that can explain a fix should not automatically be allowed to execute it. Investigation remains read-only; a conservative safety score gates the write path; generated code receives a separate review; and the final operation is checked against the approved plan. AWS reports this as Tamnoon’s design, not a universal guarantee for every agentic remediation product.

Build a remediation flow with clear stages

1. Collect and normalize findings. Bring findings from approved cloud-security tools into a common record with the resource identifier, account, region, severity, evidence, timestamp and source. Preserve the original finding so the system can trace every later decision back to its source.
2. Enrich the context. Identify the resource owner, dependencies, environment and related findings. Group findings that share a root cause where possible. AWS Security Hub documentation describes remediation plans that group related exposures affecting a single resource, which can help teams avoid treating every symptom as a separate fix.
3. Propose a specific change. Require the agent to name the exact resource, current state, intended state, evidence and expected effect. Reject a proposal that uses vague targets such as “all buckets” or cannot explain which finding it resolves.
4. Validate the plan. Check the proposed change against policy, permissions, known dependencies and a pre-approved set of operations. Run a dry run or a non-production test when the cloud API supports it. A model-generated explanation is not a substitute for a policy decision.
5. Request approval when risk is high. Require a human to approve changes that affect production access, networking, identity, encryption or other critical controls. Low-risk, reversible actions can be automated only after the team defines the conditions and tests them.
6. Apply and verify. Execute the approved operation with a scoped identity, then read the resource state again and rerun the relevant security check. Close the finding only when the expected state is confirmed; otherwise report the failure and route it for review.

Use guardrails, but do not treat them as authorization

Amazon Bedrock Guardrails provides configurable filters for harmful content, denied topics and sensitive information, along with contextual grounding checks and automated reasoning checks. These controls can help evaluate model inputs and outputs in supported use cases. They do not decide whether an IAM principal is authorized to modify a particular cloud resource, and they do not replace an approval gate or a transaction policy.

Keep tool execution behind a separate permission boundary. The agent should not be able to invent a target resource or widen its own role. Use short-lived credentials where possible, restrict actions to the resources in the approved plan, and record the exact request and response. If the system cannot prove that a change matches the approved plan, it should stop rather than improvise.

AWS also says Tami uses Claude through Amazon Bedrock rather than calling a separate third-party model endpoint. The case study describes IAM-scoped permissions, private workloads, CloudTrail records and Bedrock Guardrails applied to requests and generated code. It says inference stays within Tamnoon’s AWS trust boundary and uses cross-Region inference within a defined US boundary. These are details of the reported implementation; teams should confirm the same settings, model availability and data terms for their own account and Region.

Measure verified risk reduction

Counting generated remediation plans is not enough. Track findings opened and closed, time from detection to verified fix, the number of plans rejected by policy, approval wait time, failed changes, rollbacks, repeat findings and production incidents. Break the results down by severity and resource type so a drop in total findings does not hide a backlog of high-impact exposures.

Define “resolved” before the automation goes live. A ticket marked closed is not the same as a resource that is actually secure. Keep the original finding, approved plan, identity used, operation result and post-change evidence together so an auditor can reconstruct what happened.

Use a controlled baseline when reporting improvement. Record the initial finding set, the time window, which resource types were included and whether the number represents unique exposures or repeated alerts. Attribute any percentage reduction to the published case study unless you have measured the same result in your own environment.

The AWS post also attributes additional results to Tamnoon: more than 14 million cloud alerts analyzed, up to 100 times higher remediation efficiency through root-cause clustering, and more than 13,000 engineer hours saved per week across its customer base. Treat these as vendor-reported figures. Before using them as a benchmark, ask for the measurement period, customer coverage, definition of an alert or exposure, and how the baseline was calculated.

Common failure modes to plan for

• Wrong resource: A finding points to an identifier that has changed or exists in more than one account. Resolve account, region and resource identity before acting.
• Unsafe side effects: A network or identity change can block legitimate users. Check dependencies and require approval when impact is uncertain.
• Stale evidence: The resource changes between investigation and execution. Re-read the current state immediately before applying the plan.
• Repeated remediation: A retry applies the same change twice or overwrites a manual fix. Make operations idempotent and check the current state before retrying.
• Weak audit trail: A model summary does not show which API call ran. Store the proposed plan, approval, tool call, response and verification result.

For agent architecture, see our article on how Postman scales Agent Mode on Amazon Bedrock. Our AI agent evaluation workflow covers repeatable testing, while the agent audit-log guide explains what to record. If the remediation agent uses external tools, also review the MCP permission testing guide.

Sources

• AWS Machine Learning Blog: How Tamnoon built AI-powered cloud security remediation with Amazon Bedrock.
• AWS Docs: Remediation plans in Security Hub.
• AWS Docs: Amazon Bedrock Guardrails.