Skip to main content
Back to all posts

Why Sending API Keys Over Slack Is Dangerous (And What to Do Instead)

•SnapSend Team

Last quarter, a Series B startup discovered that an AWS access key shared in a Slack DM eight months earlier had been used to spin up a Bitcoin miner. The original message was "deleted" the same day. The attacker found it anyway.

That's the thing about Slack: when you paste an API key into a chat, you've handed it to at least four systems besides the recipient. Slack's storage, its search index, every integration installed on the workspace, and whatever local caches your teammates have on their devices. Pressing Delete removes it from one place. The other copies stay.

Sending API keys over Slack is part of most engineering teams' daily workflow — and most of those teams treat it as a minor cleanliness issue rather than the security exposure it actually is.

The four places your "deleted" Slack message still lives

When you press Delete, here's what's actually deleted: nothing, immediately. The message is marked tombstoned in the UI. The underlying record persists in several places.

1. Slack's server-side retention. Paid workspaces retain messages indefinitely by default. Free tier limits accessibility to 90 days, but the underlying data is retained under Slack's compliance and legal-hold policies.

2. Slack's search index. Even on tiers that clear old messages, indexed copies live in Slack's search infrastructure. Breach disclosures have shown attackers querying for aws_access_key_id, BEGIN RSA, and password= to find leaked credentials at scale.

3. Third-party integrations. The average production workspace has 20+ integrations with message:read scope. If you Slack a key, you've also handed it to whatever third-party SaaS those integrations point to.

4. Push notifications and device caches. Your teammate's mobile OS cached the notification text. It synced to their personal devices. None of those copies are deleted when you delete the message.

Deletion in Slack is a UI affordance, not a deletion guarantee.

The attack path

Here's the canonical kill chain:

  1. Developer A pastes a fresh AWS key into a Slack DM at 3:47 PM.
  2. The message is indexed by Slack's search.
  3. Four integrations with message:read ingest the message.
  4. One integration is breached six months later. The attacker dumps the data.
  5. The attacker greps for AKIA[A-Z0-9]{16} and finds the key.
  6. The key is still active because Developer A "deleted" the message and never rotated.
  7. The attacker enumerates IAM, finds an over-permissioned role, exfiltrates customer data.

The vulnerability isn't a bug in Slack. It's the assumption that chat is ephemeral. It isn't.

Why "I'll just delete it after they read it" doesn't work

Engineers know they shouldn't paste keys in chat, but the social workaround becomes "send then delete." This breaks for three reasons:

  • Deletion is a UI affordance, not a guarantee. Slack's API documentation is explicit that deleted messages may be retained per workspace policy.
  • The send-to-delete window is enough. Mobile push notifications mirror the message to Apple/Google's notification servers seconds after send.
  • You can't delete from third parties. If an integration that ingested the message is breached, the message is in their dataset, not Slack's.

What "safe enough" actually requires

A channel for sharing API keys safely needs to satisfy:

  • End-to-end encrypted — the hosting service can't read it under any circumstance.
  • One-time access — readable once, then provably destroyed.
  • Time-bounded — hard expiry, even unread.
  • No recipient account — friction kills adoption.
  • Auditable — read receipts so you know if it was opened.

Secret managers (Vault, AWS Secrets Manager) solve permanent storage but are poorly suited to one-off human transfers, especially with non-technical recipients.

How modern teams handle this

The teams I see getting this right adopt a two-layer pattern:

Layer 1 — Permanent storage. Vault, AWS Secrets Manager, Doppler. Canonical copy lives here.

Layer 2 — Ephemeral transfer. A self-destructing, end-to-end encrypted share tool for human-to-human handoffs.

This is the gap SnapSend was built for. The encryption key lives in the URL fragment — the part after # that browsers never send to servers — so the backend can't decrypt your shares. Each link self-destructs on first read or hard expiry. No account required. The Slack message becomes a one-time pointer to an already-destroyed payload.

A 30-second flow:

  1. Open snapsend.site, paste the key, set expiry to 1 hour.
  2. The browser encrypts with AES-256-GCM before any request leaves your machine.
  3. Copy the link, paste in Slack.
  4. Recipient clicks once, sees the key, link is incinerated.
  5. Even if the Slack message is exfiltrated tomorrow, the link is dead.

Stop sending API keys over Slack

If you've Slacked a key in the last week, rotate it. The cost of rotation is minutes; the cost of a leaked production credential is sometimes the company. Then build the habit — pin a guideline in your handbook, demo a self-destructing link to new hires, set up a Slack bot that flags messages matching common secret patterns.

Try SnapSend free at snapsend.site — no account needed.