Great question on the IAM scoping — neither SecurityAudit nor ReadOnlyAccess. Custom policy with exactly the 18 read actions the scanner needs
(e.g. s3:GetBucketPublicAccessBlock, ec2:DescribeSecurityGroups, cloudtrail:GetTrailStatus).
No broader managed policies.
On the diff-vs-SDK pattern: valid tradeoff, and strictly safer. The reason Remedi calls the SDK directly is the target user a solo founder or small team with no existing Terraform who just got a misconfigured S3 bucket flagged and needs it fixed tonight. The IaC diff pattern requires you already have IaC. If you do, your point stands completely.
Blast radius mitigations in place: (1) write permissions are exact verbs only no iam:, no s3:, no wildcard writes, (2) human approval gate before any write touches
the account, (3) the IAM user is deployed via CloudFormation delete the stack and
all access is gone in 30 seconds.
Two patterns for two different customer segments, not the same one.
Archit Mittal
I Automate Chaos — AI workflows, n8n, Claude, and open-source automation for businesses. Turning repetitive work into one-click systems.
The "safe" part is where most agentic cloud tools die — giving an LLM write access to AWS is a blast radius conversation most people skip. A pattern that's worked for us on similar client engagements: the agent only ever generates Terraform/CDK diffs, never calls the SDK directly, and a human or a policy check (OPA) gates the apply. You get the remediation speed without the "agent drops a bucket at 3am" risk. How are you scoping IAM for the agent's read path — SecurityAudit + ReadOnlyAccess, or something tighter?