Blast radius
How much an attacker gets if one credential, service, or account is compromised. The honest answer to 'how bad if this leaks'.
See it
What it is
Blast radius is the honest answer to 'if this one thing gets compromised, what else goes with it'. A read-only key scoped to one table has a small blast radius. A root service key sitting in a frontend bundle has a blast radius the size of your company. The term comes from ops (what breaks when this server dies) and got borrowed by security, where the thing that dies is a credential, a service account, or a single user session.
Use it as a design question, not a postmortem question. Ask it before you mint a key: which rows, which buckets, which environments, which customers. The shrinking moves are all boring and all work: per-service credentials instead of one shared one, scopes instead of admin, short expiries and rotation, separate prod and staging accounts, and tenant isolation so one leaked token cannot walk across customers.
The trap is measuring blast radius by intended use rather than actual permissions. The analytics job only reads three tables, so people call it low risk, while its credential technically has full write on the database. Attackers use the permission, not the intention. Read the policy, not the job description.
Ask AI for it
Map the blast radius of every credential in this project. For each API key, service account, database role, and token: list exactly what it can read, write, and delete, which environment it reaches, and whether it crosses tenants. Flag any credential whose actual permissions exceed what its code path uses. Then propose the smallest scoped replacement for each one, plus expiry and rotation, and give me the concrete policy or IAM changes as a diff.