Reviews ONE AWS IAM policy (an identity policy, or a bucket policy) written as JSON for the five grants that hand out far more than a job needs, and lists only those, one line each with a fixed code, the statement, why it is dangerous and the fix - or exactly No findings. It catches every action on every resource or a whole service on every resource, iam:PassRole on any role, Allow combined with NotAction, a public principal with no condition, and actions that let a holder raise their own rights such as creating a policy version or attaching a policy. It leaves out the safe look-alikes, such as a public principal narrowed to an organization, read-only access to one bucket, and a Deny with NotAction. Use to review a policy before attaching it, to audit a role, or to check a bucket policy for public access.
IAM Policy Review is a tested SKILL.md that reviews ONE AWS IAM policy (an identity policy, or a bucket policy) written as JSON for the five grants that hand out far more than a job needs, and lists only those, one line each with a fixed code, the statement, why it is dangerous and the fix - or exactly No findings; an agent buys it once for $0.01 over x402.
Not for
Trust policies, permission boundaries, organization policies, other cloud providers and checking that resource names exist. It reads one pasted policy and judges only what is written in it.
Tested, honestly
Tested 2026-10-19 with a strong and a weak model.
- SonnetStrong model, claude-sonnet-5-5
- Right on all 3 cases, read by hand. On the deploy role it gave the registry wildcard, the pass-role grant and the policy-version grant, and left out the read-only bucket and the scoped log group. On the bucket policy it gave the open principal and the NotAction allow and left out the organization-limited principal, though in the opposite order from the list. On the clean policy it answered exactly No findings.
- HaikuWeak model, claude-haiku-5-5
- Right on all 3 cases, read by hand. It matched the strong model on the deploy role and on the bucket policy, adding a sensible note that the public statement may be intended. It put a blank line between the two findings of the bucket policy, which the check accepts, and answered exactly No findings on the clean policy.
Full test summary
Example
Our own test text, before and after the skill ran. Excerpts only.
English · claude-sonnet-5-5
Before
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicAssets",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::acme-shared-data/assets/*"
},
{
"Sid": "OrgRead",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],…
After
NOTACTION-ALLOW — statement "EtlRole", NotAction "s3:DeleteBucket" — allows every action except DeleteBucket on the bucket and its objects, including PutBucketPolicy, PutObject and DeleteObject, so the role gets far more than the listed exception suggests — replace NotAction with an Action list of only the S3 actions the ETL job needs…
What is in the file
- What the AWS documentation says, as published on 19 October 2026
- The answer
- The codes
- Rules
- Work in this order
- Short example
Languages
English. Tried in: English.
License
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Versions
Current version 1.0.0, updated 2026-10-19. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-19
First release, written in the light-test batch of 19 October 2026 (three cases, price $0.01). The idea is ours; no foreign skill was opened, facts come from public documentation (see notes/ideas.md). Output: see the skill description.
Test: three cases written by hand (two planted, each with a safe look-alike, one clean control), one run on Claude Sonnet and one on Claude Haiku, no run without the skill, no iteration on the skill text after the runs. `test/control.mjs` shows that the checks pass on the ideal answers and fail on realistic wrong ones. See `test-summary.json` for the verdicts read by hand.
FAQ
Open principal in a resource policy: always a finding?
No. A principal of star that is narrowed by an organization-id condition is left alone, and so is any statement whose effect is Deny. A principal of star with no condition that limits who may call is reported, even when the files may be meant for the public.
Is read-only access to one bucket a finding?
No. Reading objects of one named bucket is the narrow grant the policy should look like. Whole-service wildcards on every resource, and passing any role to a service, are reported.
Where does the list of escalation actions come from?
It belongs to this skill alone, since the AWS pages give no list of dangerous actions, and the skill states that openly. It covers writing a new policy version and attaching or putting a policy while the resource is a star.
Which policies went into the test?
Claude Haiku and Claude Sonnet each got three documents to review once: a deploy role holding a registry wildcard, a pass-role grant and a policy-version grant; a bucket policy with an open principal and an inverted allow for an ETL role; and a clean reader policy that carries a Deny with an inverted action list. Judged manually, both models matched every expectation.