iiinova — where your digital self keeps evolving

3. Public API. The full archive is published as static JSON under /api/v1: the policy list, 1618 policy documents, the change timeline, the action index and the discoveries. No key, no signup. Free and unofficial. Link below.

000

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).

100

1. Today every change says what really happened: how many actions added, how many removed instead of reading git diff. Same wording everywhere, on the site, in the RSS feeds, in the emails, on Bluesky, Telegram.

120

zoph @zoph.me · 18/08/2026

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:

IAMTrail displays recent changes to AWS Managed IAM Policies, highlighting added actions and updates with a focus on readability.

121

This is what you get when you are subscribing to IAMTrail instant alerts.

IAM policy change alert showing updates to the AWS Elastic Disaster Recovery ReadOnlyAccess policy with new actions and statements.

000

- 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.

100

A first-ever sighting no longer reads like a routine version bump. It gets flagged the moment it lands: - iamtrail.com/discoveries for the full list, newest first - Email, as its own "discoveries" topic if version bumps are noise to you - A new read-only Telegram channel: t.me/iamtrail

100

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.

100

IAMTrail has been archiving every AWS-managed IAM policy change since February 2019. This week I've added the capacity to notice novelty rather than just diff versions. Every action and service prefix in the archive now carries a first-seen date,

100

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.

100

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.

100

Side note: the analytics above come from Fathom. Privacy-first, no cookies, no personal data. A refreshing way to understand traffic without tracking people.

000

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.

100

Rebuilt the release notes. Every release now groups changes into new, updated, and removed policies, with the exact IAM actions that were added or removed, and a link straight to the diff. Less noise, more signal.

100

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.

100

Sped up the build. A full site deploy dropped from about 34 minutes to 5 minutes by shipping only what actually changed.

100

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:

100

AWS updates these policies constantly, and usually very quietly. IAMTrail records every change in git, so you can see the full history of any managed policy and spot when one grows a new permission.

100

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

Analytics dashboard displays real-time visitor stats: 4.6k visitors, 4.7k pageviews, 99% bounce rate, and historical data trends.

100

And you, how do you handle clickops operations in your context? What is your balance?

000

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.

100

As an Engineering Manager, you should find that making manual changes via the console is risky, and production should be treated as sacred. Only versioned, auditable, replicable infrastructure as code should be used.

100

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).

A notification alerting that a manual console change was detected for an EC2 instance, including cost impact and recommended actions.

100

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.

100

Then an AI agent, built on Amazon Bedrock with Claude and persistent memory, investigates: it retraces the full user session, checks adjacent CloudTrail events, and evaluates the purpose and reasoning behind the change.

100

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.

100

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.

Alert about a suspicious AWS action allowing SSH access from the internet, highlighting high security risks and the need for immediate action.

101

AI-Augmented Home Assistant

The same engineering habits I use at work now quietly run my home. Versioned, repeatable, easy to roll back. The interface is natural language; the complexity stays in the repo. If you are curious, I wrote about the full setup on the blog. zoph.me/posts/2026-...

zoph.me

How I run my Home Assistant config like production: an AI coding agent edits the live YAML, I review the diff, and everything is versioned in Git.

010

- 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.

110

Everything lives in Git, with custom LLM rules and context that teach the agent how my house actually works and what our living habits are. Claude Opus is the main driver. I describe the idea, I read the change, it commits and reloads HA. - 0 YAML files edited by hand in 3 months

210

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.

100

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.

A smart home tablet mounted on a wall displays a camera feed and weather information amidst a kitchen setting with plants.

100

the kit itself, so an attacker cannot quietly delete your alarms first. It is free and open source. Link ↓

000

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

100

It is two CloudFormation stacks. No agents, no extra accounts, no SaaS, no lock-in. Just plain AWS services (EventBridge, CW, SNS). Cost is usually a few cents a month. It also enables a bunch of Secure-by-Default Accounts and Regional-Level Configurations. About 30 detections now.

100

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

100

For non-specialists: AWS logs almost everything in your account but alerts you on almost nothing. So if someone disables your logging, opens a database to the internet, or creates a backdoor user, you usually find out too late. The Survival Kit fixes that.

100

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

Flowchart outlines AWS account security process, detailing suspicious activities, notifications via email or chat, and required actions.

210

If IAMTrail watches what AWS does to managed policies, Trustline watches who has access to your own resources. Companion tools, same conviction: AWS security should be observable. Free (FOSS), MIT, no signup.

000

What you get: a free, all-resource external-access audit for your account or whole AWS Organization, in any region, on a schedule, with a shareable HTML report. No SaaS, no agent, no AWS bill (the external-access analyzer is $0).

100

2. A self-contained HTML report in the iamtrail(.)com design system, plus SAM IaC to run the scan as a daily scheduled Lambda. Reports land in S3 with timestamped keys, optional SNS alerts fire when findings need review.

110

now consumes AA findings (the free external-access tier). Provable reasoning. Account or organization scope. Coverage for IAM, S3, KMS, Lambda, SNS, SQS, Secrets Manager, EFS, EBS/RDS snapshots, ECR, and DynamoDB. Public access and missing-ExternalId in dedicated sections.

100

Yesterday: same idea, more polish. ExternalId checks for confused-deputy risk. AWS Organizations integration. Custom trusted-accounts YAML. A Markdown report. Still just a CLI. Today, two upgrades land together: 1. An IAM Access Analyzer backend. Instead of regex over policies, Trustline

100