"This key is sensitive" is not a plan. When a credential leaks at 2am, the questions are concrete: does someone get woken up, how fast must it be revoked, and what has to be checked afterwards. This tool turns the properties of a credential into those answers before you need them.
What drives the score
Each factor is weighted by what it actually enables, not by how it sounds:
| Factor | Weight | Why |
|---|---|---|
| Admin / IAM | 6 | Privilege escalation and persistence — the attacker grants themselves more |
| Deploy code | 6 | Supply-chain compromise; owns everything the pipeline touches |
| Read other secrets | 6 | One leak becomes every leak |
| Production | 5 | Real data, real money |
| Billing / payments | 5 | Direct financial loss and chargeback liability |
| Personal data | 5 | Statutory notification obligations |
| Write access | 4 | Destruction, not just disclosure |
| No audit logging | 4 | You cannot scope the damage, so you must assume the worst |
| No expiry | 3 | Stays valid in every backup and log it ever reached |
| Shared between services | 3 | Rotation needs coordination, so rotation gets postponed |
| Can send email or SMS | 3 | Phishing from your domain, passing SPF and DKIM |
| No IP restriction | 2 | Usable from anywhere, immediately |
Two of these deserve emphasis. No audit logging scores high because without it you cannot bound the incident — every question becomes "we must assume yes". And read other secrets is a multiplier: a credential that reads your secrets manager is not one incident, it is all of them.
Revoke before you investigate
The response procedure puts revocation first, and the ordering is deliberate. Investigation takes hours. Revocation takes seconds. Every minute spent working out what happened is a minute the attacker still has access. Revoke, replace, deploy — then investigate with the bleeding stopped.
Reducing the radius
The recommendations are ranked by how much they actually remove:
- IP allowlisting is usually the single largest reduction available, and the most often skipped. A key that only works from your egress addresses is worthless in a paste on the internet.
- Splitting administrative capability into a separate, short-lived, human-approved credential removes the highest-weight factor from your always-on key.
- Read-only keys for read-only consumers. Most consumers only read. Issuing them a write-capable key is a habit, not a requirement.
- One key per consumer. Sharing means you cannot revoke one without breaking all of them, which is why shared keys never get rotated.
The 72-hour clock
If the credential could reach personal data, a leak may start a statutory notification deadline — 72 hours under GDPR from becoming aware. That clock starts at awareness, not at confirmation, which is another reason to have this assessment written down before the incident rather than during it.
Frequently asked questions
How is this different from the provider's own permission list?
A permission list tells you what the key can call. This tells you what that means when someone else holds it: how fast to respond, what to check, and which single change would reduce the damage most.
Should every key be assessed?
Assess the ones in production and anything with write access. The exercise usually reveals that several keys are far more powerful than the job they do, which is the useful output even without an incident.
What is a reasonable target score?
Lower than it is now. In practice, most keys can shed the "no expiry", "no IP restriction" and "shared" factors without any change to what they do — which typically drops a critical key to moderate.
Where do I get the revocation commands?
The key revocation generator produces provider-specific commands, verification steps and an incident checklist.