Administrator-equivalent AWS-managed policy on a service principal

Rule

V-010

Account

sandbox 345678901234

Where

us-west-2

First seen

2026-08-03

Last seen

2026-09-12 (32 days)

Verdict

not rated

Runbook

R-03 in the runbooks

What Firekeeper saw

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

Resources

• iam_role: ‹arn:aws:iam::345678901234:role/service-role/generated…(65 chars)› (res-1056)
• ec2_instance: ‹i-00000000000000038› (res-2056)
• s3_bucket: ‹logs-archive-56[.]example-org[.]invalid› (res-3056)
• iam_policy: ‹arn:aws:iam::345678901234:policy/generated/workload-5…(70 chars)› (res-4056)

Evidence

e/HJKLMNPQRSTU e/QRSTUVWXYZab e/XYZabcdefghi 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?

Signing one of these quiets this finding. Nothing changes until you sign with your passkey, and it ends on its own date unless someone renews it.