- AWS published Tamnoon's account of Tami, an AI agent that investigates cloud security findings and plans fixes, while a separate isolated step carries them out.
- Tamnoon reports a more than 90 percent cut in critical cloud exposure in 90 days with zero production issues. These are the vendor's own figures.
- Before trusting an agent that changes live systems, ask what credentials it holds, how each change is rolled back, and how untrusted input is filtered.
The gap between finding and fixing
Security tools now find problems faster than teams can fix them. The AWS post describes the result as risk that builds up "in the gap between detected and fixed." It says most findings sit untouched, and not because the fixes are hard. Someone must work out the context, find the owner, and confirm the change will not break production.
That work is slow. A security engineer can spend hours on one finding, the post says, and it often shares a root cause with dozens of other alerts. This is the job Tamnoon built its AI assistant, Tami, to do on Amazon Bedrock. Tamnoon describes Tami as an assistant that helps human cloud security experts.
The idea: give the agent a plan, not the keys
Most debate about AI agents asks how smart they are. A better question for anyone who signs the budget is what the agent is allowed to touch.
Tamnoon's answer is separation of duties. The AI investigates and plans. A different, isolated step acts. Finance teams have long worked this way: the person who prepares a payment is not the person who releases it. The lesson here is that autonomy is easier to defend when it is built from small, limited permissions, not from trust in the model.
How the system works
Tamnoon sits downstream of the detection tools teams already run. It collects findings from cloud security platforms and posture scanners and converts them to one shared format. Results from tools such as Wiz and Amazon GuardDuty then look alike to every later step. The system adds context about the asset and its exposure, and ranks the findings.
Four specialized AI agents take over from there. Each runs in an event-driven, serverless setup on AWS, so each stage can scale independently and fail safely. Tamnoon also matches the model to the job. Hard root-cause reasoning goes to the most capable models. High-volume checking goes to cheaper ones.
For every finding, Tami assigns a Remediation Confidence Indicator: SAFE, RISKY or AWAITING DATA. The rating tells a team what can be automated and what needs a human first.
Layers built to cover for each other
AWS says each safety layer "assumes the one before it might miss something." The layers it describes are concrete.
First, no fix is drafted until an independent safety check, deliberately biased toward caution, judges the change safe. Second, the steps that investigate are validated as read-only. The step that writes changes is kept apart from them. Every edit it makes comes with a way to back up the system, check the result and undo the change.
Third, each generation step is paired with a review step that critiques the output. When the model cannot reach an accurate answer, a human is brought in. Finally, the post says the AI does not hold cloud credentials. Execution uses short-lived, tenant-scoped credentials in an isolated environment, apart from the agents that plan the work. Humans stay in the loop as well: changes go through sign-off, and a full record of the approvals is kept.
Protecting the model from its own inputs
There is a risk specific to AI here. Tami reads findings that, in AWS's words, an unauthorized user could influence. A malicious alert could try to steer the model. To limit that, Amazon Bedrock Guardrails screens each prompt going in and each answer coming out. Because the check runs inside Bedrock, an individual function cannot skip it by changing its own prompt.
The guardrails mask personal data and secret-like content, filter prompt injection, and keep output to security remediation. Permissions are narrow too. Tami's only Bedrock permission is bedrock:InvokeModel, limited to named models. Model versions are pinned to dated identifiers such as claude-sonnet-4-5-20250929, so a model change becomes a reviewed code change. Temperature is set to zero to keep scoring and planning consistent between runs.
What the numbers do not show
This is a vendor case study published on a cloud provider's blog. The 90 percent and zero-issue figures come from Tamnoon's own research. The material reviewed does not state how many customers are included, what the starting exposure was, or how "critical exposure" was counted.
It is one company's design and one set of results. It shows a pattern worth examining, not proof that the approach works everywhere.
Questions to put to your team
If a vendor or internal team proposes an agent that changes production systems, ask five things. Does the agent hold credentials, or does a separate, isolated step act for it? Does every change carry its own backup and rollback? What filters the untrusted text, such as alert payloads, that reaches the model? Are model versions pinned and changes reviewed? And what baseline sits behind any claimed reduction in risk?
Trust in an agent comes from what it cannot reach, not from what it promises.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS.
