You've done it. Everyone has. A coworker needs the staging password, and the fastest thing to do is paste it into a Slack DM.

It takes three seconds. And it creates a problem that can last for years.

What actually happens to that password

When you paste a credential into Slack, it doesn't just reach the other person. It becomes data that Slack stores, indexes, and retains — often long after you've forgotten about it.

Slack retains messages on their servers. On paid plans, workspace admins can configure retention policies, but many leave the default: keep everything, forever. On Enterprise Grid, organizations can export and search the full history of every DM and channel — including messages between individual users.

Slack messages are searchable. Anyone with the right permissions can search for keywords across the workspace. A search for "password" or "API key" in most workspaces will surface results that would make a security auditor flinch.

Third-party apps can read messages. Every Slack app with the right OAuth scopes can access message history. That productivity bot your team installed last year? It might have read access to channels and DMs. You're trusting not just Slack's security, but the security of every integration connected to your workspace.

Messages survive offboarding. When someone leaves the company, their Slack messages stay. That DM with the database password? It's still sitting there, readable by admins, even after the person's account is deactivated.

The compliance problem

If your company is working toward SOC 2, ISO 27001, or HIPAA compliance, sharing credentials in Slack is a finding waiting to happen.

Auditors specifically ask how your team transmits sensitive credentials internally. "We paste them into Slack" is not the answer they're looking for — and it can delay or block your certification.

SOC 2 Trust Services Criteria requires controls around how sensitive data is transmitted. Self-destructing links with view limits and encryption satisfy that control. Slack messages don't.

What to do instead

The fix is straightforward: encrypt the credential before it leaves your device, share a link that self-destructs after viewing.

From your browser

Go to vaulted.fyi
Paste the password or credential
Set it to expire after 1 view
Send the link in Slack (or wherever)

The credential is encrypted with AES-256-GCM in your browser. The decryption key lives only in the URL fragment — it never reaches the server. After your coworker opens the link, the secret is permanently deleted.

Now when someone searches Slack for "password," they'll find a dead link instead of a live credential.

From the terminal

If you live in the command line, the Vaulted CLI does the same thing:

npx vaulted-cli "staging-db-password" --views 1 --expires 1h

Pipe it, script it, alias it. Same encryption, same self-destructing links.

In CI/CD workflows

Sharing credentials between GitHub Actions workflows? The Vaulted GitHub Action handles that too:

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.DEPLOY_KEY }}
    views: 1
    expires: 1h

Quick rules for your team

Never paste credentials directly into any chat app — Slack, Teams, Discord, none of them
Use self-destructing links — One view, short expiration, always
Add a passphrase for sensitive credentials — Share it through a separate channel (phone, in person)
Rotate credentials after sharing — Treat every handoff as a potential exposure
Set a team policy — Make encrypted sharing the default, not the exception

That password in Slack feels harmless in the moment. But it's searchable, permanent, and one misconfigured integration away from being exposed.

Share it securely instead — it takes the same three seconds.