iamlive: generating IAM policies from real AWS, Azure and GCP calls

The problem iamlive solves for least-privilege work

Writing an IAM policy by hand usually goes one of two ways. You start from a managed policy or a wildcard and never narrow it, or you read the source of an application and try to guess which API calls it makes at runtime. Both leave you with a document you cannot defend. iamlive takes a third route: it observes the calls a workload actually makes and emits policy statements from them. The audience is engineers who already have working code or CLI commands and want the policy to describe that behaviour, not a hypothetical version of it. The project covers AWS, Azure and Google Cloud, with AWS as the mature path. The README is explicit that the Azure and GCP providers are in preview and may produce incorrect outputs, so treat the multi-cloud framing as aspirational rather than uniform.

How client-side monitoring and proxy mode differ

iamlive has two capture mechanisms and they produce different documents. CSM mode is the default for AWS and relies on the SDK metrics stream that AWS SDKs send over UDP to a local port. The README states that CSM captures statements with the Action key only, because Resource is not available that way. Proxy mode runs a local HTTP(S) server, by default on 127.0.0.1:10080, inspects requests bound for the cloud endpoints, and forwards them on. Because it sees the full request, it can populate Resource as well. That distinction drives most real decisions: if you need a policy with specific ARNs, CSM is the wrong mode. Proxy mode needs a CA key and certificate, generated and stored in ~/.iamlive/ by default, plus proxy environment variables in the shell that runs your tooling. The README warns that other software in subprocesses may also honour HTTP_PROXY and HTTPS_PROXY, which can surface untrusted certificate errors; NO_PROXY or importing the CA bundle elsewhere is the suggested workaround.

Installing iamlive and capturing a first AWS policy

The README lists pre-built binaries for Windows, macOS and Linux in the project releases, a Homebrew tap, and a Go build. The Go route requires Go 1.16 or later, although the module file in the repository targets a newer toolchain. The Homebrew command is the shortest path on macOS:

brew install iann0036/iamlive/iamlive

With the binary on your PATH, start the listener in its own window. The --set-ini flag writes the CSM or CA bundle settings into .aws/config for the selected profile and removes them when the process exits, which saves you from editing config by hand:

iamlive --set-ini

Then run your normal AWS CLI commands in a second window. The documentation's example is `iamlive --set-ini` for CSM mode and `iamlive --set-ini --mode proxy` when you want Resource entries. Policy statements appear in the iamlive window as calls arrive; Ctrl+C exits. If you would rather not touch .aws/config, the README gives the environment variable route instead:

export AWS_CSM_ENABLED=true
export AWS_CSM_PORT=31000
export AWS_CSM_HOST=127.0.0.1

For proxy mode the equivalents are the CA bundle and proxy variables:

export HTTP_PROXY=http://127.0.0.1:10080
export HTTPS_PROXY=http://127.0.0.1:10080
export AWS_CA_BUNDLE=~/.iamlive/ca.pem

To keep the output rather than copy it from the terminal, add --output-file policy.json, which the README says is written on SIGHUP or on exit. A comprehensive invocation from the documentation combines the flags:

iamlive --set-ini --mode proxy --profile myprofile --output-file policy.json --refresh-rate 1 --sort-alphabetical --bind-addr 127.0.0.1:10080 --ca-bundle ~/.iamlive/ca.pem --ca-key ~/.iamlive/ca.key --account-id 123456789012 --background --force-wildcard-resource

Arguments can also live in an INI file at ~/.iamlive/config, which is easier to keep in a repository than a long command line.

Where iamlive gives you a policy that is too narrow or too broad

The generated document describes the calls that were observed, and nothing else. That cuts both ways. A workload with conditional code paths, retries that fall back to a different API, or an admin screen nobody opened during the capture will produce a policy that omits those actions, and the failure appears later in production rather than during capture. The --fails-only flag exists for the opposite instinct: it adds only failed AWS calls to the policy, which is useful when you are reconstructing what an application attempted and were denied, but it is a CSM-only option. Resource handling is the other sharp edge. CSM cannot see Resource at all, so a CSM policy is action-only. Proxy mode can see it, but the README exposes --account-id precisely because the account in the ARN sometimes has to be supplied, defaulting to 123456789012 unless detected, and --force-wildcard-resource exists to flatten Resource back to a wildcard when the captured ARNs are not what you want. If your traffic does not pass through the instrumented process, neither mode sees it: a workload that reaches AWS through a sidecar, a managed service or a different SDK configuration than the one you set variables for is invisible.

How iamlive compares with CloudTrail-based policy generation

The obvious alternative is to derive policies from CloudTrail events, either by querying the event history or by using a tool built on top of it. The approaches differ in where the data comes from and what that implies. CloudTrail records calls after they reach AWS, so it captures everything in the account regardless of which SDK, language or process made the call, and it works for workloads you cannot instrument. iamlive captures on the client side, so it sees the call before it is sent and can read request parameters that never appear in an audit event, which is how proxy mode builds Resource entries. The trade-off is coverage against fidelity. CloudTrail sees more callers; iamlive sees more of each call. For a single service or a script you control, iamlive gives you a tighter document with less query work. For an account-wide audit where you do not know every caller, CloudTrail is the safer source. The README also points to a Lambda Extension for AWS and a LocalStack integration, which suggests the intended pattern is running iamlive alongside the thing you are testing rather than as a standing account-level collector.

Maintenance, licensing and what a version bump costs you

The repository is not archived, and the last push was on 2026-04-19, which is when v1.1.28 was released. The two releases before it landed on 2025-11-07 and 2025-07-12, so the cadence over the past year has been roughly one release every few months rather than continuous churn. That matters for planning: the AWS action mapping is embedded in the binary and can be replaced with --override-aws-map pointing at your own JSON file, which is the escape hatch when a new AWS service appears between releases. The project is MIT licensed, so you can vendor, modify and redistribute it, subject to the usual requirement to keep the copyright notice; the repository carries a separate NOTICE file alongside LICENSE, and if you redistribute the binary you should read both rather than assume MIT covers everything in the tree. Upgrading is a binary swap or a brew upgrade, and the config surface is stable enough that the flags documented in the README have stayed in place across the recent releases. Nothing in the README describes a migration path for the ~/.iamlive/config file format, so treat that file as something to re-check after a jump across several versions.

Editorial conclusion

Adopt iamlive if you are tightening an AWS policy and want the actions your tooling actually calls rather than a guess, and run it in proxy mode when Resource-level detail matters. Do not adopt it as a policy generator for Azure or GCP: the README marks both providers as preview and warns they may produce incorrect outputs. Before relying on the output, check whether your workload talks to AWS through something other than the SDK or CLI you instrumented, since CSM only sees calls from processes configured to emit it, and verify that the Resource ARNs in the generated document match the account you expect.

Frequently asked questions

Official sources

1. iann0036/iamlive on GitHub
2. Issues
3. License: MIT
4. README
5. Releases