Paste your AWS IAM policy. We'll pull its priors, file the charges, and tell you exactly how bad it is — with jokes.
⚠️ For fun and learning — not a security audit. A real review needs your CloudTrail data and someone who knows your architecture.
How it works
You paste a policy. Our checker reviews it in your browser against a set of IAM security rules and calculates the threat level. The threat level comes from these rules and from AWS's validator findings, never from AI.
AWS checks for errors. Our server sends the policy to AWS's own policy validator (IAM Access Analyzer). Before it's sent, every AWS account ID is replaced with a placeholder. Other details, like bucket and role names, are sent as written, and AWS keeps a record of the validation request in our AWS account's audit log.
An AI model writes the roast. It receives only a short, anonymous summary: the types of issues found — by our rules and by AWS's validator — the threat level, AWS action names (like s3:GetObject), how broad each statement is, how many statements your policy has, and what you told us it's attached to. It never sees your policy, account IDs, resource names, or ARNs.
We don't store your policy. No login, no database, no tracking. Our hosting provider keeps standard request logs, such as IP addresses, for rate limiting and security.
For fun and learning, not a security audit.
SAMPLE CASE FILE
THREAT LEVEL 10/10AKA: The All-You-Can-Eat Buffet
"You gave a Lambda function full account admin. That's not a function, that's a toddler with the nuclear launch codes and a snack."
EXHIBIT A — SUBMITTED POLICY
🔒 No login, no database, no tracking. Your policy is analyzed right here in your browser — the AI sees only issue types, AWS action names and scope shapes, never your account IDs, resource names or ARNs, and your policy text reaches AWS's own validator with every account ID swapped for a placeholder.
This page has no database, no login, and no analytics — we are not building a collection of other people's policies. Here is exactly what happens to yours.
Your policy is parsed and checked entirely in JavaScript running in your browser. That step never leaves your device.
To write the joke, our backend sends Claude five things: a short summary of the issue types found (like "Public Resource Exposure"), including the kind of error AWS's validator reports, the threat score, how many statements the policy has and which one scored worst, the AWS action names your policy grants (public API names like "s3:GetObject" — and only names that are real AWS actions are passed on; a typo or anything else you type there is replaced with a phrase naming just the service, never forwarded), and a shape-only description of how broadly each statement reaches (phrases like "objects inside one bucket", assembled from a fixed list of words this page ships with, including AWS's own published service and action names). Never your raw policy text, and never your account IDs, bucket names, role names, ARNs, or any other resource name.
Your policy text is sent to our backend, for one reason: checking it against AWS's own official IAM Access Analyzer validator, which is the only way to catch invalid action names and condition keys that AWS itself would reject. Before it goes, every 12-digit AWS account ID is replaced with a placeholder — 123456789012 becomes 900000000001 (as does any other 12-digit number in the policy, erring on the side of masking too much). Different accounts get different placeholders, so the validator still works normally, and the real numbers are swapped back into any AWS finding you see on screen. Account IDs are the only thing replaced — your bucket names, role names and every other resource name are sent to AWS exactly as you wrote them.
Being straight with you about one thing: AWS keeps its own record of that validation request in our AWS account's audit log (CloudTrail), and that record contains the policy document we sent. The account IDs in it are the placeholders, not your real ones — but since account IDs are the only thing we replace, your bucket names, role names and every other resource name sit in that record exactly as you wrote them. We can't switch that off; it's AWS logging calls to its own API. Our server itself writes nothing down — no database, no logging of your policy — and your policy exists only in memory for the few seconds your roast takes.
You can verify the browser half yourself: this is a single, unminified HTML file. Right-click → View Page Source, or open your browser's Network tab while you roast something, and confirm exactly what leaves your browser and where it's headed. What happens on our side after that isn't something page-source-viewing can prove — so the two points above are us stating it plainly, written to be literally accurate rather than merely reassuring.
CHARGES FILED
FOR THE RECORD
COUNT-BY-COUNT BREAKDOWN
OFFICER'S RECOMMENDATION
Roast look wrong? Report a bad roast — tell us what it got wrong and we'll fix the rules.
For fun and learning — not a security audit. Your real security tool is still out there doing the actual work (and definitely judging you less). Report a bad roast · How it works