JSONAISTUDIO

Generating IAM Policies from Plain English

4 min·Jul 15, 2026
AI Summary

You can describe the access you want in plain English and generate the IAM JSON, but you must verify it: check the actions are minimal, the ARNs are specific, and no wildcard slipped in. Start from a template and iterate.

AWS IAM Read-only Policy
A least-privilege IAM policy granting read-only access to S3 and CloudWatch logs — a safe starting point for auditors, dashboards and monitoring roles.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadS3Objects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-data",
        "arn:aws:s3:::my-app-data/*"
      ]
    },
    {
      "Sid": "ReadCloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:GetLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "arn:aws:logs:*:*:log-group:/aws/my-app/*"
    }
  ]
}

Writing IAM by hand is error-prone; generating it from a description is faster — if you verify the result.

Describe the intent precisely

Vague prompts produce vague (over-broad) policies. Compare:

  • ❌ "Give my app S3 access"
  • ✅ "Allow s3:GetObject and s3:ListBucket on the reports-prod bucket only, over HTTPS"

The second names the actions, the resource, and a condition — exactly the three things least privilege needs.

Start from a known-good shape

Rather than a blank page, open the read-only policy template and edit from there. You inherit a correct structure (both bucket and object ARNs, a deny-insecure-transport guardrail) and only change the specifics.

Always verify

After generating, check three things:

  1. No wildcards crept into Action or Resource.
  2. Both ARNs are present where S3 needs them.
  3. The policy denies what it should (HTTP, wrong region).

Iterate with diffs

Ask follow-ups like "restrict this to us-east-1" or "remove write permissions" and review each change as a side-by-side diff before accepting it. That review step is where correctness actually happens.

Open the template, describe your case, and let the workspace generate and diff the policy for you.

FAQ

Can I trust a generated policy as-is?

Treat it as a first draft. Verify the actions are the minimum needed and the ARNs are specific, then test in a non-production account.

What is a good starting prompt?

Be concrete: name the service, the exact operations, and the exact resource, e.g. "allow read-only GetObject on the reports-prod bucket only".

Related templates

Related articles