Closing findings rather than creating more tickets

Tamnoon and AWS have detailed Tami, an agentic cloud-remediation system built on Amazon Bedrock. The 14 October account says the platform has reduced critical cloud exposure by more than 90 per cent within 90 days for a typical customer, with no production issues across millions of workloads. The system sits downstream of cloud-security scanners and turns their findings into investigated, prioritised and validated fixes.

This targets a familiar security bottleneck. A scanner can identify thousands of misconfigurations, but each fix still needs context about ownership, dependencies and operational risk. Teams often leave findings unresolved because the cost of proving a change safe is greater than the mechanical work of making it. Tami tries to automate that reasoning while preserving explicit gates around production changes.

Four agents divide responsibility

An investigation agent creates read-only steps and a complete investigation plan, drawing on patterns from customer environments and passing its result through a model-as-judge validation layer. A safety-scoring agent builds an evidence chain for each asset and labels remediation SAFE, RISKY or AWAITING DATA. Its stated bias is conservative: uncertainty causes a downgrade instead of an optimistic approval.

Only a SAFE finding can activate the remediation agent. That component orders the work and creates steps following a backup, remediate and verify pattern with rollback guidance. A fourth agent generates executable code after an input guardrail checks relevance and prompt injection. A separate reviewer agent must approve each generated artefact, creating a generate-and-review loop rather than trusting the first output.

Detection tools remain the source of truth

Tamnoon integrates with CNAPP and cloud-native tools including AWS Security Hub and GuardDuty, normalising findings into a common schema. It enriches each record with asset and exposure context, clusters related issues and assigns a Remediation Confidence Indicator. The original detection product remains responsible for identifying what is wrong; Tami concentrates on the investigation and repair that follow.

This division avoids asking a language model to replace deterministic scanners. It also lets a root-cause fix address several related alerts. AWS reports up to 100 times greater remediation efficiency through clustering, and says Tami has analysed more than 14 million cloud alerts. Those figures originate from Tamnoon research and should be evaluated against each customer’s environment and definition of closure.

Credentials stay outside the planning model

The agents do not hold customer cloud credentials. Execution is brokered through short-lived, tenant-scoped credentials under customer-controlled trust, in an isolated environment separate from the agents that plan the work. Investigation is strictly read-only; write authority belongs only to the remediation path. Approval workflows and a full audit trail surround execution, while risky or incomplete cases return to human cloud engineers.

Bedrock Guardrails screens requests and generated code, masks sensitive information and limits the system to remediation topics. Per-service IAM roles restrict model invocation, secrets and queues. EventBridge, SQS and Step Functions coordinate serverless work, with dead-letter queues and alarms containing failures. Model versions are pinned in infrastructure-as-code so an upgrade becomes a reviewed change rather than silent drift.

What zero production issues should mean

A zero-issue claim is encouraging, but it needs a defined denominator, observation period and incident threshold. Customers should still test rollback, simulate partial failure and monitor the downstream effect of apparently safe configuration changes. A technically correct fix can alter cost, latency or application behaviour in ways that a security finding does not capture.

The strongest aspect of Tami is its layered refusal to equate model confidence with permission. Independent safety scoring, read-only investigation, review loops, short-lived credentials and human governance all assume another layer may fail. Organisations building remediation agents can adopt that pattern even if their tools differ: automate evidence gathering and repeatable fixes, but make production authority narrow, observable and reversible.

Operating the confidence boundary

A SAFE label should be attached to a specific asset state and expire when that state changes. Cloud environments are dynamic: a dependency may appear after investigation or a resource owner may deploy a new configuration before the fix runs. Rechecking the evidence immediately before execution can prevent a plan that was safe an hour ago from acting on stale assumptions.

RISKY and AWAITING DATA also need clear routes. A queue that merely accumulates uncertain cases recreates the backlog the system was meant to reduce. Tamnoon’s embedded experts provide one escalation path; internal teams adopting the pattern should define who supplies missing evidence, how quickly a case is revisited and when an unresolved exposure is accepted by an accountable owner.

Post-remediation verification should confirm both that the scanner finding closed and that the service remains healthy. Metrics, logs and synthetic checks can catch operational harm that a security control alone will miss. The rollback instruction must be executable under the same emergency conditions as the change, including when an agent service or external model is unavailable.