Tamnoon's cloud remediation agents never hold a credential. That is the design decision worth copying

The safest agent that changes production infrastructure is one that cannot change it. That sounds like a contradiction until you separate deciding from doing, which is exactly what Tamnoon’s design does.

AWS published Tamnoon’s architecture on October 14. Tamnoon sells cloud security remediation: it takes findings from cloud security tools and fixes the misconfigurations behind them. Its AI system, which calls Anthropic’s Claude models on Amazon Bedrock, investigates each finding, decides whether a fix is safe and writes the remediation. According to the post, “the AI never holds cloud credentials.” Execution runs in a separate, isolated environment, with short-lived, tenant-scoped credentials under trust the customer controls.

Four agents, one gate after another

The work is split across four specialized agents, and each stage narrows what the next one may do.

1. Investigate: read-only plan, checked by a judge
2. Score safety: SAFE, RISKY or AWAITING DATA
3. Plan: backup, remediate, verify, rollback
4. Generate code, then a separate reviewer approves
5. Execute in isolation with short-lived access

Model reasoning, no cloud credentialsExecution, customer-controlled trust

Investigation gathers context and produces a plan that is validated as strictly read-only, checked by an LLM-as-a-judge layer. Safety scoring builds an evidence chain per asset and rates each finding SAFE, RISKY or AWAITING DATA; the post describes it as deliberately conservative, downgrading when unsure. Planning runs only on findings rated safe, and every step follows backup, remediate and verify, with rollback guidance. Code generation turns plan steps into executable remediation after an input guardrail screens for relevance and prompt injection, and a separate reviewer agent must approve each artifact.

Three choices that carry the design

Credentials live where the model does not. If an attacker manipulates the investigation agent through a poisoned resource tag or a crafted log line, the worst outcome is a bad plan, which the next gates can catch. It is not a deleted bucket. This is the pattern we keep finding in serious deployments: Microsoft’s network agent never holds the execution credential, and the Zenity research on AgentCore showed what happens otherwise: the agent’s cloud role decides the damage.

“I don’t know” is a valid answer. AWAITING DATA is a first-class outcome. Most agent designs force a verdict; this one lets the safety stage refuse to decide, and routes RISKY and AWAITING DATA findings to Tamnoon’s cloud engineers. SAFE actions can execute automatically through an approval workflow with a full audit trail.

Every change carries its own undo. Backup and rollback are part of the plan format, not an afterthought in a runbook.

Model versions are pinned to dated identifiers, which also makes the system testable when a provider retires a model.

Read the results with their source

Tamnoon reports more than a 90% reduction in critical cloud exposure within 90 days, “with zero production issues.” The post’s own results table says “up to 90%,” and other figures in it come from Tamnoon’s research. These are vendor-reported outcomes, not an audit, and they depend on each customer’s configuration and approval settings.

What to ask of any remediation agent

Whether you buy a service like this or build one, the architecture gives you the questions:

1. Which component holds production credentials, and is any model in that component?
2. Can the safety stage say “not enough data,” and what happens then?
3. Who decides which finding classes execute without a person, and where is that written?
4. Does every change ship with its own backup, verification and rollback?
5. Is the reviewer that approves generated code independent of the one that wrote it?

A vendor that answers the first question with “the agent has a least-privilege role” has not separated deciding from doing. It has only made the doing smaller.