What It Actually Means
It is a credential. That is the whole point and it is routinely forgotten, because a key looks like configuration rather than like a password, and gets handled accordingly.
Why They Are Treated Carelessly
Nobody emails a password. People email API keys constantly.
They end up pasted into chat messages during an urgent fix, committed into code repositories, stored in shared documents, and sitting in the environment of servers nobody has logged into for years. Each is a working credential to a system holding your data or able to spend your money.
Repositories are the standard case and the most damaging. A key committed to git remains in the history after being deleted from the current files, and automated tools scan public repositories for exactly this pattern continuously. The interval between an accidental push and an attempt to use the key is frequently minutes.
The important consequence: a key that has been exposed must be rotated, not deleted. Removing it from the file changes nothing.
The Properties To Check
Scope. A key should permit what the integration needs and nothing more. Read-only where reading is all that happens. Most are created with full access because it was quicker, and nobody revisits it.
Separation. Development and production should use different keys. A key leaked from a laptop should not reach live customer data.
Rotation. Changing them periodically limits the damage from a leak nobody noticed. This only happens in practice if you know which systems use each key, which is why an inventory matters more than the policy.
Revocability. You should be able to invalidate one immediately without breaking four other things. Shared keys make that impossible, so nobody revokes them.
Where They Should Live
In environment variables or a secrets manager. Not in the codebase, not in a shared spreadsheet, not in chat history.
For a small business, a password manager holding the authoritative record and the values supplied to the server through its environment is entirely reasonable and better than most arrangements. The essential part is that there is one place that is definitely current.
What To Ask
- Has any key ever been committed to a repository? If yes, rotate it rather than deleting it.
- What can each key actually do? Full-access keys for read-only integrations are the usual finding.
- Do development and production share any?
- Could we rotate one today without breaking things? If nobody knows what uses it, that is the problem.
- Which suppliers hold keys to our systems? Every integration with an active key is standing access into your business, and the list is longer than most people expect.
The Habit Worth Having
Keys accumulate. Every trial, integration, script and supplier adds one, and nothing removes them. Unlike a staff account there is no leaving date to trigger a clear-out.
An annual review of what holds a key, what it can do, and whether it is still in use takes very little time and reliably finds credentials belonging to systems nobody uses any more. It is the same exercise as reviewing tokens and OAuth grants, and the three lists overlap enough to do together.
More terms are in the glossary.
