The Key Ring in the Shared Drive: A Calm Audit for Stray API Credentials

Every small UK team has a version of the same drawer. It is not literally a drawer, although it might be. It is a shared spreadsheet called something like Integrations - working copy, last touched before a bank holiday, with a tab named API stuff. In one cell there is a long string that starts with sk_ and ends with a feeling of mild dread. Nearby, in a chat pin, someone has pasted a webhook URL. In the wiki, under Deployment notes (old), there is a config block with a client secret and a note saying TODO: move this later.

None of this makes your team reckless. It makes your team normal. Credentials get left in plain sight because projects move quickly, contractors come and go, and the person who knew where the key lived left before anyone wrote it down. The fix is not a lecture. It is an inventory.

Start where the keys actually live

Before you search, accept that API keys and integration secrets rarely live only in the places you would expect. In small teams they turn up in shared drives, Microsoft 365 or Google Workspace folders, old wiki pages, Notion databases, Confluence spaces, chat pins, ticket comments, deployment notes, Postman collections, browser bookmarks and the occasional email thread with the subject line quick question.

A useful first pass is a plain text search across the tools you can access. Try terms such as api_key, apikey, token, secret, client_secret, bearer, authorization, x-api-key, webhook, smtp, password, sk_live and pk_. Search filenames as well as contents. Look for .env, config, credentials, deploy and integration. Do not open every hit and start copying things into a new document. The aim is to build a list of locations, not to create a second mess.

Make the hunt boring and blame-free

Announce it as a tidy-up, not an incident. A short message works better than a security seminar: we are checking where integration keys are stored, please flag anything you know about, please do not paste keys into chat. Give people a simple way to report a location, such as a form or a named person in the IT channel.

This matters because the instinct when people feel blamed is to delete first and mention it later. Deletion is not the same as rotation. A key removed from a spreadsheet is still live until the service that issued it says otherwise. You want people to tell you where the spare keys are, not quietly sweep them under the rug.

Classify before you rotate

Once you have a list of candidate locations, sort each finding into three buckets: live production, test or sandbox, and unknown or probably dead. For each one, record the service, the environment, who owns it, where you found it, what access it appears to have, and how it would be rotated. Do not put the secret itself in the register. Record the location and a non-sensitive identifier, such as the key name or the last few characters, so you can match it later without turning the register into another leak.

The unknown bucket is where most of the value sits. A key nobody can explain is either dead, dangerous, or both. Ask the vendor or check the service dashboard for last-used dates. If a key has not been used since a previous contractor left, that is useful information. If it has been used recently and nobody owns it, that is a priority.

Rotate in the right order

The safe sequence is create, deploy, verify, revoke. Create the replacement key first. Update the systems that need it. Confirm the integration still works. Then revoke the old key. Doing it the other way round turns a tidy-up into an outage.

Some services make this easy. Others only allow one key at a time, which means a short maintenance window and a clear owner. Either way, update the place where the key should live, not the place where it was found. For most small teams that means a password manager or a proper secrets store, with environment variables for applications. A shared spreadsheet is not a secrets store, even if it is password-protected and called restricted.

Webhook URLs deserve the same treatment. Slack, Teams, Zapier, Make and payment providers often issue URLs that act like credentials. Anyone with the URL can post into your channel or trigger a workflow. Rotate them by deleting and recreating the webhook, then check recent activity for anything you do not recognise.

Assign one owner and a review date

A register without owners becomes a museum exhibit. Every credential should have one named person, not a team name and not IT. That person does not have to do the rotation personally, but they should know why the key exists and when it was last reviewed. Add a next review date and tie it to something that already happens, such as a quarterly tool review or a renewal check.

When a contractor leaves, rotate the keys they touched. When a tool is swapped out, add credential cleanup to the offboarding checklist. When a new integration goes live, add it to the register on the same day. These small habits are much more effective than an annual panic.

A register you will actually keep

Keep it lightweight. A table with service, environment, owner, storage location, created date, last rotated, next review, scopes and rotation notes is enough for most small UK teams. Store it somewhere restricted, and do not fill it with secrets. The point is to know what exists and who is responsible, not to recreate the problem in a neater font.

This week, pick one shared drive and search five terms. Collect the locations. Rotate the most obviously live key. Add five rows to the register. You do not need to boil the ocean. You just need to make the next contractor inherit a list rather than a drawer full of live keys.