The message you sent three years ago is still there
Most people treat a chat message like a spoken word — say it, move on, forget it. But chat platforms don't work that way. Slack retains messages on its own servers according to your workspace plan. Microsoft Teams syncs everything to Exchange Online. Google Chat logs land in Vault if your organisation has it enabled. The secret you pasted to onboard a contractor in 2021 is almost certainly still retrievable by an admin, a legal hold, or an attacker who compromises the right account.
That's not a hypothetical. The 2022 Slack breach at Uber exposed private code repositories after an attacker pivoted from a single compromised VPN credential. The blast radius was amplified precisely because sensitive context — environment variables, internal URLs, access tokens — had been shared in channels over months and never cleaned up.
Why chat feels safe but isn't
Chat has three properties that make it genuinely useful for secrets: it's fast, it's familiar, and it delivers to exactly the person you want. The problem is that none of those properties say anything about what happens to the data afterward.
A secret pasted into Slack is:
- Stored on Slack's servers, subject to their retention policy and your admin's settings
- Searchable — by you, your colleagues, and anyone who inherits workspace admin rights
- Synced to mobile apps, which means it may also live on personal devices outside your MDM
- Potentially indexed by integrations (bots, third-party search tools, compliance exporters)
- Discoverable in ediscovery or a data breach, years after you've forgotten you ever sent it
Compare that to an end-to-end encrypted one-time note, where the ciphertext lives on a server but the key never does, and the note is deleted the moment it's read. There's simply nothing left to find.
The specific risks, ranked by how often they actually bite people
1. Credential reuse after an employee offboards
Someone leaves the company. IT disables their account. But their Slack messages — including the database password a colleague sent them six months ago — are archived in the workspace. If the same credential is still active, an attacker who later compromises the archive has it. Rotating credentials after someone offboards is necessary, but most teams don't do it consistently. Not leaving the credential in chat in the first place is a better starting position.
2. Over-privileged workspace admins
Slack workspace admins can export message history. In most free and paid plans, that's a single person with a lot of trust. If that account is compromised — or if the admin is an IT contractor who has since left — every secret ever pasted in a channel is exposed. You probably don't know who currently holds admin rights in every tool your team uses.
3. The wrong channel
It's easier than it sounds to paste a password into a public channel instead of a DM, or into the wrong DM entirely. Chat interfaces are designed for speed. Autocomplete fills in channel names and recipients. The confirmation loop before you hit send is essentially zero. Sharing the secret out-of-band — in a link that's useless to anyone who intercepts it without the context — removes this failure mode entirely.
4. Legal holds and ediscovery
If your company is ever sued, or if a regulator issues a data request, your chat history may be produced in discovery. Sensitive credentials, client details, and internal security configurations that lived in chat become part of the record. For teams in healthcare, finance, or legal services this is a genuine compliance exposure — one that's addressed in more detail in how financial advisors can securely share client information and how healthcare professionals handle patient confidentiality.
The threat model chat wasn't built for
Chat is optimised for collaboration. It's a persistent, searchable, multi-device record of what your team discussed. Those are features, not bugs — except when what you're communicating is a secret that should stop existing once delivered.
The right mental model is: does this information need to outlive the moment of transfer? A password for a new hire's first login does not. A recovery code sent to a client does not. An API key handed to a freelancer does not. If you answered no, a tool that retains the message is the wrong tool.
One-time encrypted notes solve this directly. You create a note, the encryption key lives only in the URL fragment (so the server never sees it — see how zero-knowledge architecture works in SecureNotes), and the note self-destructs on first read. The chat you send the link through still has a record, but the record is a dead link. That's a meaningful security improvement over leaving the plaintext credential in the thread.
It's worth being honest about where this breaks down too. If the recipient's device is compromised at the moment they open the note, the plaintext is visible. One-time links don't protect against malware on the endpoint. What they do protect against is the long tail of risk: archived logs, compromised admin accounts, accidental shares, and legal discovery months or years later. For most teams, that tail is where the actual exposure lives.
A practical swap you can make today
Next time you're about to paste a credential into Slack or Teams, take fifteen seconds and create a note instead. Send the link in chat. The recipient clicks it once, reads the secret, and the note is gone. Your chat history has a dead URL. If you're sharing something with an external contractor, the workflow is exactly the same — and sharing API keys with contractors covers how to build this into a repeatable handoff process.
No accounts to set up. No browser extensions to install. The habit is the hard part; the tool is not.
Try it before you next paste a password into Slack
The next credential your team needs to share doesn't have to live in a chat log forever. Compose an encrypted, self-destructing note on SecureNotes — it takes less time than typing the secret directly into a message, and it leaves nothing behind once it's read.
