Developer security
The Right Way to Share API Keys With Your Team
7 min read
API keys, database credentials, and SSH keys get passed around development teams constantly — onboarding a new engineer, rotating a compromised key, or giving a contractor temporary access to a staging environment. The methods teams default to are often the same ones responsible for the most common and preventable credential leaks.
The most common mistakes
- Pasting keys into Slack or Teams. Chat history is searchable and often retained indefinitely, meaning a key shared "temporarily" two years ago may still be discoverable by anyone who joins the channel later.
- Committing keys to a repository, even briefly. Git history retains every commit forever by default. A key pushed and then "removed" in a follow-up commit is still sitting in the repo's history unless the history itself is rewritten — and by then, automated scanners may have already found it.
- Emailing credentials directly. Same problem as with passwords: the key ends up duplicated across sent folders, inboxes, and backup systems indefinitely.
- Using shared documents. A "team credentials" spreadsheet or doc often outlives the employees who should have access, since removing access retroactively is easy to forget.
A better handoff process
- Generate the key with the narrowest scope possible. Most API providers let you restrict a key to specific permissions or IP ranges — do this before sharing, not after.
- Share it through a one-time link, not a permanent message. The recipient gets the key once; after that, the link is dead, so it can't resurface later from chat history or backups.
- Set a short expiry if the key won't be used immediately. If onboarding happens later in the week, there's no reason for the link to stay valid for days.
- Have the recipient store it in a secrets manager or environment variable immediately. The one-time link is for the handoff, not for the key's permanent home.
- Rotate the key if you ever suspect it was shared insecurely. If a key was ever pasted into a permanent channel before you started using one-time links, rotating it is the only way to be sure it's no longer valid anywhere it shouldn't be.
What about CI/CD secrets?
For keys that need to live in a build pipeline long-term, use your CI provider's built-in secrets storage (encrypted environment variables) rather than hardcoding them into config files. One-time links are best suited to the human handoff moment — getting a credential from one person to another — not for long-term automated storage, which dedicated secrets managers handle better.
A simple example
Say you're rotating a third-party API key after a contractor's engagement ends. You'd generate the new key with the provider's minimum required scope, paste it into a one-time secret tool, set it to expire after a single view, and send the link to the engineer who needs it. They open it, drop it straight into their .env file, and the link is gone — no copy lingering in Slack, no commit history to scrub.
Related reading