Handling keys safely
What a leaked key can and cannot do, and what to do in the first ten minutes.
What a leaked key can do
Read the one workspace it is bound to, at the scopes it was issued with, until it expires. That is the whole blast radius, and it is small by construction: there is no write scope, no scope that returns a provider credential, and no key that spans workspaces.
What it cannot do
- Create, change or delete anything. Both scopes are reads.
- Read another workspace. Any other identifier returns 404 rather than data.
- Retrieve a provider credential. No scope exposes one and no endpoint returns one.
- Read file contents. The file endpoint returns metadata only.
The first ten minutes
Rotate it
This is the whole remedy and it takes seconds. A rotated key's old secret stops working immediately.
Check totalRequests
/authreports the key's lifetime request count. A number far above what your integration should have made tells you it was used.Work out where it went
A log, a screenshot, a repository, a support ticket, a shared password manager entry. The route matters more than the key, because the route will happen again.
Shorten the expiry on the replacement
If a key leaked once, thirty days is a better default than ninety until you have fixed the route.