As few people as possible. Decide who may create, read and update live keys, supply them to services through a secrets vault rather than people, audit access periodically, and let everyone else work with sandbox keys. A key nobody can read is a key nobody can leak.
Why a people policy matters
Most key advice is technical: use a vault, rotate, restrict. Leaks often start with people, though. A key pasted in chat for a quick test, kept in a notes file, emailed to a contractor. One payment provider's best practices guide says to follow least privilege and define a clear policy about which team members have permission to create, update or read secret API keys, limit access to those who need it, audit permissions periodically, and keep documentation current. It also suggests regular training to reinforce the practices.
What the vendor guidance adds
From the same guide:
- When you create a secret key in the dashboard, you see it once. Store it immediately in a vault and nowhere else.
- Share keys through the platform's secret management tools, not email, chat or support messages.
- The vendor never asks you for your secret key.
- Make sure developers are not using live keys when a sandbox key would do.
- Use restricted keys with limited permissions instead of unrestricted secret keys.
- Audit API request logs to spot misuse.
A simple role model
| Role | Live key access | Sandbox access |
|---|---|---|
| Developer | None directly | Full |
| Release pipeline | Reads secret at deploy time through the vault | Full |
| Platform or security owner | Creates and rotates, with approval | Full |
| Finance or support | Dashboard roles, not keys | As needed |
| Contractor | None | Separate sandbox where possible |
Two or three owners is typical for a small company. More owners means more copies and more chances for error. Fewer than two means a single point of failure when someone is away.
Steps to put it in place
- Inventory live keys across payment, messaging and identity vendors.
- Name an owner for each key.
- Move values into a vault and remove them from wikis, tickets and chat. If you find one, treat it as exposed and rotate it. See how to rotate leaked API keys.
- Restrict vault access to the services that need each key.
- Require approval for creating a new live key.
- Review quarterly. Remove departed staff and unused keys.
- Alert on use from unexpected places, and watch for spikes.
Offboarding
When a person with key access leaves, rotate the keys they could read, even if you trust them. This follows the vendor's advice to practice rotation so you can replace a key on short notice. See employee offboarding security checklist.
Where Safeguard fits
Safeguard's policies and gates, agent identity, and compliance evidence automation can help record who may do what and keep proof for audits. A free scan covers your dependencies.
Quick check
Should developers have live keys on their laptops?
No. Use sandbox keys for development and let the deploy pipeline fetch live keys from a vault.
How often should live keys be rotated?
On a schedule you can sustain, and immediately after exposure or staff changes. The vendor guidance recommends periodic rotation so you know where every key is used.
Sources
- Best practices for managing secret API keys, Stripe documentation
Last reviewed: 19 October 2026.
