A cloud security team's day looks like this.

CNAPPs and scanners dump thousands of findings
→ Investigate: who owns this resource? what depends on it?
→ Verify: will fixing this break production?
→ Prioritize: the urgent ones first... by what standard?
→ Meanwhile critical exposures sit open for months

Detection is not the problem. Wiz, CrowdStrike, Palo Alto Cortex, Upwind, SentinelOne, Orca, and Cyera work fine, as do AWS Security Hub and GuardDuty. The problem is the gap between detection and remediation.

An October 14 AWS post describes how Tamnoon narrows that gap with agents. Their cloud remediation orchestrator, Tami, runs on Amazon Bedrock — and the architecture is the interesting part.

Four agents, four jobs

Tami splits remediation into stages, each owned by a dedicated agent.

1. Investigation
   Gathers asset and exposure context; produces strictly read-only
   investigation steps and a plan, passing an LLM-as-a-judge validation layer

2. Safety scoring
   Builds an evidence chain per asset, classifies as
   SAFE / RISKY / AWAITING DATA — with a conservative bias:
   when in doubt, downgrade

3. Remediation
   Only for SAFE findings. Reasons through ordering, dependencies,
   and conditions; every step follows backup → remediate → verify
   and carries rollback guidance

4. Code generation
   Turns plan steps into executable artifacts — but only after an input
   guardrail screens relevance and prompt injection, and only after a
   separate reviewer agent approves the output in a generate-and-review loop

The core idea: before anything is fixed, a separate step decides whether fixing is allowed. Between investigation and remediation sits a safety gate, and that gate errs toward AWAITING DATA, not action. Work that needs human eyes gets routed out automatically.

Safety is the structure, not a feature

This is the most transferable part. Take apart the "zero production issues" claim and you find less magic, more layers.

Defense in depth
  1. Independent safety assessment — no fix draft until a separate
     assessment concludes the change is safe
  2. Read/write boundary — investigation steps are verified strictly
     read-only; understanding a problem can never alter it
  3. Backup, verify, rollback — every change carries its own recovery path
  4. Self-critique — each generation step pairs with a reflection step
     whose critique feeds regeneration
  5. Credential separation — the AI never holds cloud credentials.
     Execution is brokered with short-lived, tenant-scoped credentials
     under customer-controlled trust, isolated from planning agents
  6. Human governance — approval workflow with a full audit trail

The details hold up too:

- Amazon Bedrock Guardrails on every request and response:
  PII/secret masking, prompt-injection defense, denied topics and filters
  → critical when reasoning over untrusted finding payloads
- Least privilege: per-service execution roles; the only Bedrock permission is
  bedrock:InvokeModel scoped to specific ARNs (no manage/train/export)
- Pinned model versions: dated IDs like claude-sonnet-4-5-20250929,
  so model changes are reviewed code changes
- Determinism: temperature 0 for consistent scoring and planning
- Failure isolation: queue redrive, error handlers, dead-letter queues,
  and CloudWatch alarms wired to on-call

For a cloud security company, the way the AI runs is part of the product's security. That shows here.

Results: 90% exposure reduction in 90 days — read with care

AWS cites Tamnoon's numbers:

Critical cloud exposure : up to 90% reduction in 90 days (Tamnoon-reported)
Remediation efficiency  : up to 100x via root-cause clustering
Production issues       : zero across millions of workloads
Engineer time           : 13,000+ hours saved per week across customers
Alerts analyzed         : 14 million+ (2026 State of Cloud Remediation)

Keep the caveat attached: these are vendor-reported results from Tamnoon's own customer base, not an independent benchmark. Read them as "this is what's possible with this approach," not "you will get 90%."

The direction still matters. Group findings by shared root cause — one fix closes many alerts — and auto-execute only what is confidently safe. Those two choices are what make efficiency and zero production issues coexist.

The real bottleneck for production agents

The post leaves one question standing.

"Can our agent do this task?"    ← a capability question
"May our agent do this task?"    ← a boundary question

Most teams focus on the first. What actually blocks deployment is the second. Tami's answer is concrete:

- Put a separate, independent step between "understand" and "act"
- Separate reading from writing (readers can never mutate)
- The execution broker holds credentials, not the agent (short-lived, scoped)
- Every change has a rollback; every decision leaves an audit trail

The "helped by leaking" incidents from our PixelLeak piece and the "try it in a fake environment first" practice from our test sandbox guide are the same problem wearing different clothes. Tami implements those principles at product scale.

CodeBridge mini lab: audit your agent's boundaries

If an agent touches production systems, check these:

[ ] Are read and write permissions separated?
[ ] Do risky actions pass an approval gate (human or independent assessment)?
[ ] Do executions carry backup, verification, and rollback?
[ ] Are credentials short-lived and scoped (no long-lived keys in the agent)?
[ ] Does every run leave an audit trail?
[ ] When judgment is ambiguous, does the system hold rather than act?

That last one matters most. Automation safety is not about how often it judges correctly — it is about what happens when it is wrong. A system that stops when unsure cannot be catastrophically wrong.

Conclusion: the last step is trust, not capability

The bottleneck for production agents is not
"can it?" but "may it, and can we prove it?"

Tami's lesson is not a model choice or a prompt trick. Independent assessment, read/write separation, rollback, short-lived credentials, human approval — the sum of boring boundaries produced the zero. If you plan to automate one more stage, make this checklist before you make the feature list. That order is what ships.

Further reading

References

Go deeper with a course

Deciding when to auto-execute and when to hand off to a human is the exact question behind SAFE / RISKY / AWAITING DATA gates. Practice designing decision models and human-in-the-loop structures hands-on.