Sharing API keys safely without leaving them in Slack or email
Why API keys deserve the same care as passwords
An API key is, functionally, a password. It grants access to a service, an API, or a dataset. In many cases it grants the same level of access as a password — sometimes more, because API keys often have broad programmatic access that exceeds what a web UI would allow.
Yet API keys are routinely treated with far less care than passwords. They end up in Slack messages, email threads, GitHub commits, and plain text files because they look technical rather than sensitive. The result is that many organisations have API keys floating around in unsecured places that they've long forgotten about.
The Slack and email problem
Slack is where development teams communicate. It's convenient, searchable, and persistent. Those last two qualities are exactly what make it a bad place for secrets. A developer who types an API key into a Slack channel to share it with a colleague has:
- Created a permanent record in Slack's message history
- Potentially shared it with every member of that channel
- Made it searchable by anyone with access to the workspace
- Contributed to a workspace that may be exported, archived, or subpoenaed
Email has the same problem with the added dimension of copies in sent folders, inboxes, and mail server logs.
The git commit problem
API keys in source code deserve special mention. Commits are permanent in a way that Slack messages are not — even if you delete the file and commit again, the key remains in the git history. Public repositories on GitHub are scanned by automated tools within seconds of a push. Attackers routinely harvest API keys from public repositories and use them immediately.
Even in private repositories, checking in API keys is a bad practice. It mixes credentials with code, makes rotation difficult, and creates access control problems when developers move on.
Safe practices for sharing API keys
Use environment variables, not hardcoded values API keys belong in environment variables or secrets managers (AWS Secrets Manager, HashiCorp Vault, etc.), not in code files. This is a development best practice independent of sharing.
Use one-time encrypted links for transfer When you need to give an API key to a colleague, contractor, or client, use PassTransfer to create a one-time encrypted link. They retrieve the key once; the link expires. The key never appears in Slack or email.
Use separate keys per environment and per user Most APIs allow you to create multiple keys. Create separate keys for development, staging, and production. If possible, create per-user keys for team members. This way, if one key is compromised or a team member leaves, you can revoke just that key without disrupting everyone else.
Rotate keys regularly Establish a rotation schedule for API keys, especially for production systems. Even if a key was never exposed, regular rotation limits the blast radius of a breach you might not know about yet.
Audit key usage Most API providers offer usage logs. Review them periodically. Unexpected usage patterns — unusual volumes, calls from unexpected IP ranges, calls at unusual times — are early indicators of key compromise.
When a key is already exposed
If you suspect a key has been seen by the wrong person — it was in a public repository, a Slack message to the wrong channel, or a forwarded email — treat it as compromised. Revoke it immediately and generate a new one. Don't wait to investigate first; revoke first, investigate after.
Conclusion
API keys are secrets. Treat them like secrets: store them securely, rotate them regularly, and when you need to share one, use a tool built for secure single-use delivery rather than dropping it into a chat message.
