Coworkers share sensitive text all day: the Wi-Fi password for the new office, a customer's phone number for a callback, the admin login for a tool, a salary figure for an offer letter. It goes into Slack or Teams or email because that is where the conversation already is, and then it stays there, searchable, synced and backed up.
Encrypted sharing of sensitive text between coworkers is about changing one habit: the sensitive part of a message travels as a link that opens once, while the conversation around it stays where it was. This guide covers what counts as sensitive, why the usual channels keep copies, what encryption does and does not protect, and the routine that makes the safer habit easy enough to keep.
What makes workplace text sensitive
Sort text by what happens if it is forwarded to the wrong person.
| Category | Examples | Harm if exposed | | --- | --- | --- | | Access | Passwords, access codes, API keys, MFA backup codes | Someone else can act as you or your company | | Personal data | Customer contact details, ID numbers, health or payroll data | Privacy breach, regulatory exposure | | Confidential business | Unreleased numbers, deal terms, legal matters | Competitive or legal damage | | About people | Performance notes, HR issues, references | Harm to a colleague, liability |
Routine chat is none of these. The point is not to encrypt every message; it is to recognise the one in twenty that should not live in history.
Why chat and email keep copies
Every message you send in Slack, Teams or email is stored by the service, synced to each device on both sides, included in exports and backups, and often quoted in notifications that land on lock screens. Deleting it removes the view, not the copies. A password pasted into a channel in 2024 is still in the export someone downloads in 2027.
Encryption in transit, which these services all have, protects the message between your device and their servers. It does nothing about the stored copies, because the service holds them readable. That is fine for conversation. It is the wrong property for a secret.
What encryption protects, and what it does not
Three kinds of encryption come up, and only one is the right fit for sensitive text.
- In transit (TLS): protects against someone on the network. Every reputable service has it.
- At rest: protects the stored data against someone with the disk. The service can still read it, and so can anyone with access to the account.
- Browser-side, recipient-only: the text is encrypted on your device before it is sent, and only the holder of the link can decrypt it. The service stores ciphertext it cannot read. This is the property that matters for a password or a personal detail.
None of them protect against a compromised device at either end, a screenshot, or sending to the wrong person. Encryption limits who can read the text in transit and in storage. The recipient check and the device are still yours to manage.
The routine: text in a link, link in the chat
A one-time secret link gives you recipient-only encryption without changing where the conversation happens.
- Paste the sensitive text into the one-time secret link tool. It is encrypted in your browser before it is stored, the stored copy is destroyed the first time the link is opened, and the link expires after an hour, a day or a week if nobody opens it. No account is needed for text up to 10,000 characters.
- Send the link in the chat where you were already talking, with one line of context: what it is and when it expires.
- Keep the identifying details out of the same message when the text is a credential: username in the chat, password in the link.
- Add a passphrase on a Pro account for anything that would be serious if the link were forwarded, and pass the passphrase on by a different route.
- Check the reveal. If the link reports it was already opened and your coworker says they did not open it, treat the text as exposed.
For teams on Slack, the LinkPilot Slack app removes the
tab switch. /secret creates the link from the message box and
replies only to you, and the Send as secret link shortcut rescues a
password someone has already pasted by replacing it with a link. The
text passes through Slack and LinkPilot's Slack service, which
encrypts it in memory before storage, so for the strictest cases use
the web tool, where encryption happens in your browser.
Compare the options
| Method | Copies left behind | Who can read it | Fits | | --- | --- | --- | --- | | Plain chat or email | Everywhere | The service, admins, anyone in the thread | Routine conversation | | Disappearing messages | Fewer, but screenshots and backups | The app provider in some cases | Casual, low stakes | | Password manager share | In the vault, by design | Named vault members | Credentials the team keeps using | | One-time secret link | None after one open | The link holder only | One-off sensitive text to a coworker |
A credential the whole team uses for months belongs in the password manager. A one-off, such as a reset code, a customer's details for a callback or an offer figure for HR, belongs in a one-time link. The secret links vs password managers guide covers the boundary.
After sharing
- Revoke a link that was never opened once it is no longer needed, rather than waiting for expiry.
- Clean the surroundings. Drafts, notification previews and exported threads can hold a copy of text pasted before you decided to use a link. Keep the sensitive part out of the message from the start.
- Record the handoff, not the content. Who received what and when is an audit trail. The text itself should exist only where it is needed.
When it goes wrong
Autofill picks the wrong name and the message is sent. Say so immediately, ask the recipient to delete it and not open the link, revoke the link if it is unopened, and treat anything revealed as exposed: rotate the credential, tell the data owner if it was personal data, follow your company's reporting process. Then make the mistake harder to repeat by moving the sensitive text into a link every time, so a misaddressed message carries a dead link instead of the secret.