A SaaS vendor says the API keys you stored with it may be exposed: rotate and verify
A short path for when a vendor that holds your third-party keys, tokens or OAuth grants discloses a breach (this week: Studio on Oct 16, OpenCode Console on Oct 17). Built from the vendors' own guidance.
1. List what the vendor held2. Rotate at the source3. Look for use before rotation4. Handle downstream data duties5. Reduce the next blast radius
List what the vendor held
Work from what you gave it, not from what the vendor says was taken.
- API keys and tokens pasted into integrations
- OAuth apps you authorized (Google, Microsoft, GitHub, Slack)
- Webhook URLs, proxy keys, shared passwords
- Personal data your users submitted through it
Rotate at the source
Changing the value inside the vendor does nothing if the old key still works at the provider.
- Regenerate each key in the issuing service's console and revoke the old one
- Remove the vendor under the provider's linked or authorized apps, then re-link if you still need it
- Rotate webhook secrets or move endpoints that trust the URL alone
Look for use before rotation
The exposure window usually starts before disclosure.
- Pull provider usage and audit logs from the start of the vendor's stated window
- Flag new source IPs, regions, models or unusual spend
- Set spend limits and alerts on AI provider keys
Handle downstream data duties
If the vendor held personal data your users submitted, you may be the one who must notify.
- Check regulator guidance (in Japan the PPC asked Studio form users to hold reports pending a joint filing)
- Prepare notices for affected users
Reduce the next blast radius
Make the next vendor breach cheaper.
- One scoped key per tool, with spend and permission limits
- Prefer short-lived tokens or OAuth with narrow scopes over long-lived keys
- Keep an inventory of which vendor holds which secret