Can you send me the Stripe key?
Someone needs to log into the hosting account, so a colleague pastes the password into Slack. A developer needs the production database credentials, so they get emailed. The payments API key sits in a WhatsApp group from two years ago, alongside photos from the office party. There is a spreadsheet called passwords, shared with more people than anyone remembers.
Nobody thinks this is ideal. But the work needs doing, and chat is where the team is.
Why it keeps happening
- There is no approved place to store shared credentials, so people use the nearest tool.
- Many services only allow one login per account, so it gets shared.
- Developers put keys in code or configuration files because it is the fastest way to get something working.
- Nobody owns access, so nobody is asked before a credential is handed on.
- When people leave, nobody knows which passwords they saw, so nothing is changed.
The fix is not asking people to be more careful. It is giving them a route that is easier than pasting into chat.
Where those secrets end up
| Where the secret sits | What can go wrong |
|---|---|
| Chat history | Anyone who can read the channel, now or in future, has it |
| Forwarded, synced to phones, and kept indefinitely | |
| Source code | Copied to every laptop and possibly to public repositories |
| Shared spreadsheet | Shared links spread further than intended |
| Former staff | They may still have the credential and it may still work |
Then there is the leaver problem. When a person leaves, the right thing is to change every credential they had access to. If nobody knows which ones those were, nothing gets changed, and a former employee or contractor can still log in months later. Most of the time they never would. You just cannot tell.
Keys in code deserve special mention. Automated tools scan public repositories for keys constantly. A cloud or AI API key pushed by mistake can be found and used quickly, and the first sign is often an unexpected bill.
How we clean it up
- Find what is out there. We search code repositories (including history) with secret-scanning tools and work with your team to list the credentials known to be shared in chat, email and documents.
- Rotate anything exposed. Keys and passwords that have been in chat, email or code are changed, starting with the most powerful ones: cloud, payments, email sending and databases.
- Set up a team password manager such as 1Password, Bitwarden or Keeper, with shared vaults for each team and access granted per person.
- Use single sign-on where services allow it, through Microsoft Entra ID or Google Workspace, so people log in as themselves and access can be removed in one place.
- Move application secrets out of code into a secrets manager, such as AWS Secrets Manager, Azure Key Vault or your CI tool's secret store, with the application reading them at runtime.
- Add secret scanning to the repository and pipeline, so a key committed by mistake is blocked or flagged straight away.
- Write a short leaver checklist so access is removed and shared credentials are rotated when someone leaves.
Sharing access without the chat thread
When someone needs a login, they get access to it in the password manager, not a copy in a message. Developers work with keys that never appear in the code. You can see who has access to what, and remove it cleanly. And if a key does leak, rotating it is a known, quick procedure rather than a hunt.
Is this you?
- Passwords or API keys have been sent in Slack, Teams, WhatsApp or email.
- There is a shared document or spreadsheet of logins.
- API keys are written directly into your application code.
- Passwords were not changed when the last person left.
- You could not say who currently knows the production database password.