zoph

A few updates on IAMTrail, my archive of AWS Managed IAM Policy changes since 2019. For non-specialists: AWS changes its managed IAM policies almost every day, silently. No changelog, no announcement. IAMTrail watches them and tells you what moved. What is new:

2. Discoveries. When an IAM action appears for the first time in the whole archive, or when a new AWS service shows up in IAM, it is flagged (SPOILER ALERT).

A few updates on IAMTrail, my archive of AWS Managed IAM Policy changes since 2019. For non-specialists: AWS changes its managed IAM policies almost every day, silently. No changelog, no announcement. IAMTrail watches them and tells you what moved. What is new:

On June 3rd, a policy called FinOpsAgentOperatorPolicy appeared in the AWS managed policy archive carrying 31 actions under a service prefix nobody had ever seen before: finops-agent. AWS announced the public preview of AWS FinOps Agent on June 9th.

- Bluesky: @iamtrail.bsky.social Honest caveat: not every new prefix is a scoop. Plenty show up well after launch, when a service finally lands in some managed policy. But when AWS wires up permissions for something that does not exist yet, the archive catches it.

On June 3rd, a policy called FinOpsAgentOperatorPolicy appeared in the AWS managed policy archive carrying 31 actions under a service prefix nobody had ever seen before: finops-agent. AWS announced the public preview of AWS FinOps Agent on June 9th.

replayed from seven years of git history: 1,613 policies, 14,928 distinct IAM actions, 427 service prefixes. 281 of those prefixes appeared after tracking began, each one a moment AWS started building in public without saying so.

On June 3rd, a policy called FinOpsAgentOperatorPolicy appeared in the AWS managed policy archive carrying 31 actions under a service prefix nobody had ever seen before: finops-agent. AWS announced the public preview of AWS FinOps Agent on June 9th.

Six days. That gap exists because IAM is where a service becomes real first. The permissions ship before the docs, the SDK, and the launch blog post.

Back in 2019, I started MAMIP, then → IAMTrail to answer one nagging question: what exactly changed in an AWS-managed IAM policy, and when?

IAMTrail is still a free, unofficial archive. If you care about least privilege, or just want to know when a managed policy quietly changed under you, take a look. It's also pretty good to catch new or upcoming AWS services or features.

Back in 2019, I started MAMIP, then → IAMTrail to answer one nagging question: what exactly changed in an AWS-managed IAM policy, and when?

Fixed the homepage stats. "Most Volatile" and "Brand New" were reading from capped history and showing the wrong numbers. They now count from the real commit history, so what you see is what actually happened.

Back in 2019, I started MAMIP, then → IAMTrail to answer one nagging question: what exactly changed in an AWS-managed IAM policy, and when?

This month, something shifted. Visitors went from around 700 to 4,600 in 30 days, more than 6x the month before. People clearly care about IAM drift right now. So I spent a few hours making IAMTrail better:

Back in 2019, I started MAMIP, then → IAMTrail to answer one nagging question: what exactly changed in an AWS-managed IAM policy, and when?

Since my last post on clickops-notifier, I’ve renamed it to clickops-sentinel, which I found more appropriate, and updated the code to support richer emails (with session path).

Now you should decide how to handle human access and mutable changes in your production AWS account: guardrails/preventive measures with a ReadOnly Role for humans, SCP, or detective notifications when unattended changes occur, but still giving SSO Roles with mutable permissions.

Since my last post on clickops-notifier, I’ve renamed it to clickops-sentinel, which I found more appropriate, and updated the code to support richer emails (with session path).

I don't know where this is going, but this weekend I decided to put my generous Claude Fable access (until July 7th) to work on something that has been on my mind for months. The idea: bring visibility to manual actions made by humans on your AWS account, and supercharge those alerts with AI.

Instead of a raw "someone touched something" alert, you get context, a verdict, and a critical look at the Security and FinOps implications of that change. The agent even remembers past investigations, so it knows if this is the third time the same person opens port 22 to the world.

I don't know where this is going, but this weekend I decided to put my generous Claude Fable access (until July 7th) to work on something that has been on my mind for months. The idea: bring visibility to manual actions made by humans on your AWS account, and supercharge those alerts with AI.

Here is how it works. When someone makes a change directly in the AWS Console (good old ClickOps), the tool detects it in real time.

I have been automating my home for close to 10 years. It started with Jeedom in 2017, then, three years ago, I moved everything to Home Assistant (HA). House got smarter, but the config got heavier: YAML, templates, integrations, and a long list of small rules to remember.

- 47 automations, 2,276 lines of code, all in Git - Under 5-minute lead time from idea to deployed automation - 0 open ports, tunnel-only remote access - Wife Acceptance Factor (WAF): high. She is the one requesting the next automation now.

I have been automating my home for close to 10 years. It started with Jeedom in 2017, then, three years ago, I moved everything to Home Assistant (HA). House got smarter, but the config got heavier: YAML, templates, integrations, and a long list of small rules to remember.

Then the way I work changed. Today, I no longer open the HA web app or write YAML by hand for the setup. I just tell an agent what I want, and it writes the config for me. Spec-driven development, applied to home automation.

I just shipped a new release of the AWS Security Survival Kit.

New ones include: Public Lambda URLs without auth, S3 replication to elsewhere, Public RDS databases, KMS key policy changes, Backdoor IAM console access, AWS Org account changes, Stronger secure defaults, Dashboards that cover every detection, Documented Service Control Policies (SCP) to lock down

I just shipped a new release of the AWS Security Survival Kit.

It emails you (or pings Slack/Teams) when something bad happens.

I just shipped a new release of the AWS Security Survival Kit.