Skip to main content
Skip to content

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

  1. Rotate it

    This is the whole remedy and it takes seconds. A rotated key's old secret stops working immediately.

  2. Check totalRequests

    /auth reports the key's lifetime request count. A number far above what your integration should have made tells you it was used.

  3. 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.

  4. 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.