Attribute
tf.why
Terraform tells you what drifted. This tells you who changed it, when, and from where — by correlating the plan against CloudTrail.
What is actually interesting about it
- Pipe a terraform plan JSON in; it queries CloudTrail in parallel and attributes each drifted resource to a specific IAM identity, API call and timestamp.
- Distinguishes a change made in the Console from one made by the CLI, an SDK, or an automation role — which is usually the actual question during an incident.
- A strict mapper relates each Terraform resource type to the CloudTrail event sources that can change it, then narrows using the plan before/after state. Generic CloudTrail searching produces false positives; this does not.
- Covers 27+ AWS resource types: VPC, security groups, S3, RDS, EKS, Lambda, IAM, DynamoDB.
- Read-only by design: needs cloudtrail:LookupEvents and nothing else. Plans are parsed locally, no state leaves the machine, no database.
The repository is packaged and ready to publish — pyproject.toml,
tests and docs are in place — but it is not on PyPI yet, so
pip install tf-why will not work today. Install from source until
it is. An earlier version of this site claimed otherwise; that was wrong, and I would rather
you find the correction here than find the 404 yourself.
Scope — what this is not
Packaged (pyproject.toml, tests, docs) and installable from source. Not yet on PyPI — see the note on the project page.
Elsewhere in the system
Replaces the shared API key an AI agent uses with a scoped, attenuable token bound to its workload identity — verified offline, with no network hop on the authorization path.
An agentic incident-response pipeline: it detects a live service failure, investigates it with a three-tool orchestrator, and proposes a root cause — but cannot touch anything until a human approves.
A Kubernetes benchmark that measures whether an LLM actually read the cluster evidence before diagnosing an incident — or just guessed confidently from metadata.