Cloud security tools generate thousands of findings. Most require manual investigation, impact analysis, and careful remediation. Tamnoon built Tami, an agentic orchestrator on Amazon Bedrock, to close that loop autonomously. The result: 90%+ reduction in critical cloud exposure in 90 days with zero production issues.
This is not a detection agent. Tami writes infrastructure changes to live cloud resources. The plumbing required to do that safely reveals the orchestration, validation, and rollback boundaries that separate research demos from production-grade auto-remediation.
The Remediation Gap
Security scanners surface misconfigurations, exposed secrets, overprivileged roles, and unpatched vulnerabilities. Human operators must then:
- Investigate context (is this resource in use? what depends on it?)
- Generate a fix (IAM policy change, firewall rule, secret rotation)
- Validate impact (will this break production?)
- Apply the change
- Monitor for cascading failures
- Roll back if necessary
Each step introduces delay. Critical findings sit in backlogs for weeks. Tami automates the entire chain.
Architecture: Orchestration Flow
Tami operates as a multi-stage pipeline with explicit safety gates:
- Ingestion: Consumes findings from CNAPP platforms (Wiz, Orca, Prisma Cloud) and cloud-native sources (AWS Security Hub, GuardDuty).
- Investigation: Queries cloud APIs to gather resource metadata, dependencies, tags, and usage patterns.
- Fix Generation: Uses Amazon Bedrock (Claude 3.5 Sonnet) to propose remediation steps in Terraform, CloudFormation, or SDK calls.
- Validation: Runs proposed changes through a dry-run sandbox that simulates the change against a shadow copy of the resource graph.
- Impact Analysis: Checks for downstream dependencies using service mesh telemetry and IAM policy simulation.
- Application: Applies the change via infrastructure-as-code pipelines with version control and audit logging.
- Monitoring: Watches CloudWatch metrics and application logs for 15 minutes post-change.
- Rollback: Reverts automatically if error rates spike or dependent services fail health checks.
Each stage emits structured logs to S3 and sends telemetry to CloudWatch for observability.
Validation: Dry-Run Sandbox
Before touching production, Tami runs every proposed change through a validation layer:
def validate_remediation(finding, proposed_fix):
# Clone resource state into ephemeral sandbox
sandbox = create_shadow_environment(finding.resource_id)
# Apply fix to shadow copy
result = sandbox.apply(proposed_fix)
# Check for dependency failures
dependency_graph = build_dependency_graph(finding.resource_id)
for dep in dependency_graph.downstream:
health = sandbox.check_health(dep)
if not health.ok:
return ValidationResult(
approved=False,
reason=f"Dependency {dep} would fail health check",
rollback_plan=generate_rollback(proposed_fix)
)
# Simulate IAM policy changes
if proposed_fix.type == "IAM_POLICY":
policy_sim = simulate_policy_change(proposed_fix)
if policy_sim.breaks_existing_access:
return ValidationResult(
approved=False,
reason="Policy change would revoke active permissions",
affected_principals=policy_sim.affected
)
return ValidationResult(approved=True)The shadow environment uses AWS CloudFormation StackSets to create isolated copies of resources. IAM policy simulation runs through the AWS Policy Simulator API. Dependency graphs are built from VPC flow logs, X-Ray traces, and service mesh telemetry.
Safety Boundaries
Tami enforces hard limits to prevent cascading failures:
| Boundary | Mechanism | Failure Mode |
|---|---|---|
| Blast radius | Only remediates resources with tami:auto-fix=enabled tag | Prevents accidental changes to critical infrastructure |
| Concurrency | Max 5 simultaneous remediations per AWS account | Avoids overwhelming cloud APIs and triggering rate limits |
| Rollback window | 15-minute monitoring period with automatic revert | Catches delayed failures in dependent services |
| Human approval | Requires manual sign-off for changes affecting >10 resources | Escalates large-scale changes to operators |
| Audit trail | Every change logged to immutable S3 bucket with SHA-256 hash | Enables forensic analysis and compliance reporting |
The tami:auto-fix=enabled tag acts as an opt-in mechanism. Resources without this tag are flagged for human review but never modified autonomously.
State Management: Versioned Changes
Every remediation is tracked as a versioned state transition:
- Pre-change snapshot: Terraform state file or CloudFormation template stored in S3 with timestamp.
- Change manifest: JSON document describing the proposed modification, validation results, and approval chain.
- Post-change snapshot: Updated state file after successful application.
- Rollback plan: Pre-computed revert steps stored alongside the change manifest.
This allows point-in-time recovery. If a change causes issues hours later, operators can inspect the exact state before and after, then trigger a rollback that restores the original configuration.
Observability: Agent Decision Logs
Tami emits structured logs for every decision:
{
"timestamp": "2026-10-14T13:45:22Z",
"finding_id": "WSCN-12345",
"resource_arn": "arn:aws:s3:::prod-data-bucket",
"investigation": {
"dependencies": ["arn:aws:lambda:us-east-1:123456789012:function:data-processor"],
"usage_last_7d": 1247,
"tags": {"environment": "production", "tami:auto-fix": "enabled"}
},
"proposed_fix": {
"type": "S3_BUCKET_POLICY",
"action": "add_encryption_requirement",
"terraform_diff": "..."
},
"validation": {
"sandbox_result": "PASS",
"dependency_health": "OK",
"policy_simulation": "NO_REVOKED_ACCESS"
},
"application": {
"applied_at": "2026-10-14T13:46:10Z",
"change_id": "chg-abc123",
"rollback_plan_stored": true
},
"monitoring": {
"error_rate_baseline": 0.02,
"error_rate_post_change": 0.019,
"health_check_status": "PASS"
}
}These logs feed into CloudWatch Insights dashboards that track remediation velocity, validation pass rates, and rollback frequency.
Deployment Shape
Tami runs as a set of Lambda functions orchestrated by Step Functions:
- Ingestion Lambda: Polls CNAPP APIs every 5 minutes, writes findings to DynamoDB.
- Investigation Lambda: Queries AWS APIs to gather resource context.
- Fix Generation Lambda: Calls Amazon Bedrock with finding details and resource metadata.
- Validation Lambda: Spins up CloudFormation StackSets for dry-run testing.
- Application Lambda: Applies changes via Terraform Cloud or AWS Service Catalog.
- Monitoring Lambda: Watches CloudWatch metrics for 15 minutes post-change.
Step Functions handles retries, timeouts, and error propagation. Each Lambda has a dedicated IAM role with least-privilege permissions scoped to specific resource types.
Failure Modes
Auto-remediation introduces new failure surfaces:
Validation false positives: Sandbox passes but production fails due to environment differences (network latency, external API dependencies). Mitigation: canary deployments that apply changes to 1% of resources first.
Rollback failures: Revert plan fails because the original state is no longer valid (resource deleted, IAM role removed). Mitigation: store multiple rollback strategies (restore from snapshot, recreate from template, manual intervention).
Cascading changes: Fixing one misconfiguration triggers additional findings in dependent resources. Mitigation: rate-limit remediations per dependency graph and batch related changes.
Audit log tampering: Attacker modifies S3 logs to hide malicious changes. Mitigation: enable S3 Object Lock and CloudTrail log file validation.
Technical Verdict
Use Tami-style auto-remediation when:
- You have high-volume, low-risk findings (open S3 buckets, overprivileged IAM roles, missing encryption).
- Your infrastructure is tagged and dependency graphs are well-mapped.
- You can enforce opt-in boundaries with resource tags.
- You need to close the gap between detection and fix without scaling headcount.
Avoid when:
- Your infrastructure lacks tagging discipline or dependency visibility.
- Changes require business logic validation (is this S3 bucket intentionally public?).
- You operate in highly regulated environments where every change needs human attestation.
- Your cloud APIs have inconsistent behavior or poor dry-run support.
The 90% reduction in critical exposure demonstrates that auto-remediation agents can operate safely at scale. The key is not smarter LLMs but better orchestration: validation sandboxes, dependency analysis, rollback plans, and audit trails. Those are the primitives that separate a research demo from a production system that writes infrastructure changes autonomously.