When a hosting platform says unauthorized access touched its secret store, rotate everything you kept there, newest-risk first, and check logs for use of the old values. Hugging Face's May 2024 Spaces disclosure told users to refresh keys, and the same steps apply to any platform notice.
Step 1: inventory what lived in the store
List every secret placed on the platform: API keys, database passwords, tokens for other services, signing keys. If you cannot list them, search your project settings and deployment configs. The gap between what you think is there and what is there is where the risk sits.
For each secret, note who can use it and what it can do. A read-only key to a public dataset is a different problem from a key that can write to production.
Step 2: rotate in a sensible order
Start with secrets that can move money, change code or read private data. Then credentials that reach other secrets, such as cloud provider keys. Then everything else.
For each one, create the new value first, deploy it, confirm the service works, then revoke the old value. Revoking first creates your own outage. If the platform already revoked some tokens, as Hugging Face said it did, still confirm that nothing else was left behind.
Step 3: look for use of the old values
Check the provider logs for each rotated key. Look for requests from unfamiliar addresses, unusual hours and unusual operations such as listing everything or creating new keys. Keep what you find. Even if nothing appears, record that you looked and when.
Step 4: shrink the blast radius for next time
- Replace broad keys with scoped, short-lived ones.
- Move to fine-grained tokens where the platform offers them.
- Use a separate secret per environment so a leak in staging cannot reach production.
- Store third-party keys in a dedicated secrets manager and inject at deploy time rather than leaving long-lived copies in several platforms.
Step 5: write down what happened
A short note is enough: when you learned of the notice, what you rotated, what you verified and what remains open. If you owe customers or regulators a notice, this record is the start of it. Check your contracts and the rules that apply to you.
When the platform's disclosure is vague
Vague scope means you cannot rule yourself out. Act as if every secret was exposed until you have evidence otherwise. Rotation is cheap compared with explaining a missed rotation later.
Quick check
Should I revoke the old key before deploying the new one?
No. Create and deploy the new value first, test it, then revoke the old one. Revoking first can take your own service down.
What if I cannot tell which secrets were stored there?
Treat all credentials your deployed app can read as in scope, and rotate them. Then build the inventory so the next notice is faster.
Sources
- Hugging Face, Space secrets security update, 31 May 2024.
Last reviewed: 19 October 2026.
