Trail KMS key disabled or scheduled for deletion

Rule

V-002

Account

234567890123

Where

us-west-2

First seen

2026-08-05

Last seen

2026-09-12 (37 days)

Verdict

not rated

Runbook

R-03 in the runbooks

What Firekeeper saw

on generated-workload-31 in us-west-2 (account 234567890123): first seen 37 days ago and still present on the run that wrote this board; the weak set grew from 3 to 5 between the two runs, and none of the new members is covered by an allowlist entry.

Resources

• iam_role: ‹arn:aws:iam::234567890123:role/service-role/generated…(65 chars)› (res-1031)
• ec2_instance: ‹i-0000000000000001f› (res-2031)
• s3_bucket: ‹logs-archive-31[.]example-org[.]invalid› (res-3031)
• iam_policy: ‹arn:aws:iam::234567890123:policy/generated/workload-3…(70 chars)› (res-4031)

Evidence

e/YZabcdefghij e/fghijkmnopqr e/6789ABCDEFGH t/4b1c9e0a-1234-4abc-8def-0123456789ab

Guidance

What this is. Disabling the key makes the existing log files unreadable now. A deletion that runs its course makes them unreadable permanently, without a single log file being touched.

Why it matters. Every detection in the account, this one included, reads those logs. Turning them off is the first move of someone who does not want to be seen, and it also blinds the investigation that comes after.

How to fix it. Restore the trail or detector to the state the account baseline defines, in the infrastructure code that owns it.

Fix it with an agent

A brief for a coding agent on your own machine: what was measured, how this kind of finding goes wrong, and the rules it works under. It investigates first and proposes a pull request; nothing here changes your estate.

Across the last 30 runs

Decisions on this finding

No decision names this finding.

See every decision

Not a problem?

This finding is one Firekeeper never quiets: fix what it reports instead.