Secrets in chat and tickets: find, revoke and stop credential pastes

API keys, database passwords and tokens pasted into Slack messages, Teams chats, Jira tickets and Confluence pages are among the most common and least monitored secret leaks, because they sit outside the code repositories that secret scanning was built for. An engineer shares a key to unblock a colleague, a support ticket includes a connection string, a runbook page carries an admin password. Anyone who later gets into the workspace, by stolen session, infostealer credentials or an over-permissioned app, can search for them in seconds. This guide covers where these secrets hide, the native detection in Slack, Microsoft Purview for Teams and Atlassian Guard, how to scan history, how to clean up without destroying evidence, and how to change the habit. It is for secrets management, security operations and collaboration platform owners.

Key takeaways

• Revoke first, delete second. A secret that has been in a chat or ticket must be treated as exposed: rotate or revoke it at the source, then redact the copy. Deleting the message alone leaves a working credential in exports, retention archives and other people's notifications.
• All three platforms now detect secrets natively, on premium tiers. Slack DLP (Enterprise) has preconfigured rules for AWS, GitHub and Stripe keys; Microsoft Purview's "All credentials" bundle covers 41 credential types for Teams (E5-class licences); Atlassian Guard Premium scans Confluence and Jira and can bulk redact.
• Native coverage has gaps. Slack DLP does not scan images, channel names or third-party previews; Atlassian does not scan Confluence whiteboards, labels or attachments over 5 MB; Teams DLP depends on how the policy is scoped. Plan for what each misses.
• History matters more than new messages. Years of tickets and chat contain secrets that predate any rule. A one-off historical scan through export or API, followed by rotation, removes most of the risk.
• Give people a better way to share. Pasting stops when a vault link, a one-time secret share or a short-lived credential is faster than copying the value.

Where secrets hide in collaboration tools

Attackers know this. In the Schneider Electric Jira breach, infostealer credentials gave the attacker a Jira login and they claimed to have taken more than 40 GB of projects and issues, so any secret in those issues went with it. The same habit outside the company boundary produced the JSONFormatter and CodeBeautify leak, where saved pastes exposed AWS keys, CI secrets and Active Directory credentials. See the OWASP NHI Top 10 NHI2 Secret Leakage Guide for the wider leak paths.

Native detection in each platform

• Slack: rules can be limited to Slack Connect conversations, specific workspaces or conversation types. Slack warns that preconfigured rules "may not detect all targeted data" and can produce false positives. The warning action does not work on canvases or snippets.
• Teams: scope the policy to groups, not individual users, if you want channel messages covered: Microsoft's scope table shows channel messages are not protected when the policy targets individual accounts. In external chats, the hosting tenant's policy applies. The General Password type detects English keywords only.
• Atlassian: content is scanned when created or updated, and for Jira only the changed fields, so old tickets need a full-site content scan. Redaction of Confluence affects the current version; earlier versions containing the secret must be deleted separately, which removes those versions and their edit history permanently.

Without premium tiers, use the platforms' export or API access with a secret scanner that supports custom sources. See the Secret Scanner Rule Coverage Comparison Guide and the Secrets Scanning Buyer's Guide.

Scanning history safely

A historical scan reads every message and ticket, so it is itself a sensitive operation. Treat the scanner as a privileged non-human identity.

• Access path: use the platform's supported route: Slack exports or the Discovery API on Enterprise, Purview content search for Teams, the Atlassian full-site content scan or REST APIs with a dedicated service account for Jira and Confluence.
• Least privilege and lifetime: give the scanning app read-only scopes, a short-lived token and an owner. Revoke it when the scan ends. See the How to audit Slack apps, bots and tokens page and the Atlassian API Tokens Security Guide.
• Keep results small: store finding metadata (location, secret type, fingerprint, author, date), never the full secret value, and restrict the findings store to the response team.
• Validate before alarm: where the scanner can check whether a key is live, use that to rank findings; a live cloud key in a public channel comes first.
• Retention interaction: on Slack, retention settings decide what exports contain, including whether edits and deleted files are kept. A secret deleted by a member may still sit in exports and the Discovery API if retention keeps deleted content.

Cleaning up a secret found in chat or a ticket

1. Identify the credential: which system it opens, which identity it belongs to, and its privilege. Many are non-human identities: service account passwords, API keys, OAuth client secrets.
2. Check for use: look in the target system's logs for use of the credential from unexpected sources since it was posted.
3. Rotate or revoke at the source: issue a new credential through the secrets manager, update consumers, then revoke the old one. Follow the Leaked Credential Response Playbook.
4. Preserve evidence if needed: if use from an unexpected source was found, capture the message, author, channel and timestamps before redacting.
5. Redact or delete the copy: Slack DLP delete, Purview action, Atlassian redaction, and for Confluence delete earlier page versions that still hold the value.
6. Tell the author: explain why and show the approved way to share. Atlassian and Slack notify the person whose content was redacted or deleted, so prepare the message rather than leaving the platform notice to speak for you.
7. Close the record: log the finding, rotation date and owner, so the same credential is not "found" again.

Choosing an approach

Small organisations can search their workspace periodically for well-known prefixes such as AKIA, ghp_, xoxb- and -----BEGIN, using the platform's own search with an admin account, then rotate what they find. Large organisations should run native DLP or an external scanner continuously, send alerts to the SIEM, and route findings to the owning team automatically.

Rolling out detection

1. Baseline: run a historical scan of all platforms and count live secrets by type, location and team.
2. Rotate the backlog: start with live cloud, CI and production database credentials, then work down.
3. Enable alert-only rules: turn on native secret detection in alert mode for two to four weeks and tune false positives, for example test keys in documentation.
4. Pilot prevention: enable warn or hide for a pilot group (one engineering department) and measure friction.
5. Extend scope: include DMs, Slack Connect and external chats, bots, and attachments where supported.
6. Integrate: forward alerts to the SIEM and to the secrets response queue; link each finding to rotation.
7. Roll back: move rules back to alert-only if prevention blocks critical work, fix the cause (often a legitimate token format in documentation), then re-enable.

Changing the habit

• A faster safe path: provide a secrets manager or password manager sharing feature that creates an access-controlled link, and a one-time secret tool for external parties.
• Short-lived credentials: where people paste credentials to unblock each other, the real fix is just-in-time access or dynamic secrets, so there is nothing long-lived to paste. See the Dynamic Secrets and Ephemeral Credentials Guide.
• Ticket templates: remove "password" fields from access request and support forms; replace them with a vault reference.
• Bots that echo output: scrub CI and alert bots so they do not post environment variables or headers into channels.
• Incident hygiene: add "rotate any credential shared during the incident" to the post-incident checklist.

Detection and measurement

• Live secrets found per month: by platform and team; should fall after the backlog is cleared.
• Time to revoke: from detection to source rotation; target hours for live production credentials.
• Revoke-before-delete rate: share of findings where the credential was rotated, not only the message removed.
• Coverage: share of platforms, workspaces and conversation types under active detection, including DMs and bots.
• Repeat offenders: share of findings from authors with earlier findings, showing where training or tooling is not working.

Feed these into the wider measures in the Secret Sprawl Measurement Guide.

Common failure patterns

• Deleting without rotating: the message disappears but the credential still works, and copies remain in exports, notifications and screenshots.
• Scanning only new content: Atlassian scans on create and update, and Slack rules act on new messages; years of history stay unscanned without a deliberate backlog scan.
• Policy scoped to users: a Teams DLP policy targeting individual accounts leaves channel messages unprotected.
• Confluence history forgotten: redacting the current page leaves the secret in earlier versions until those are deleted.
• The scanner becomes the leak: a historical scan that stores full secret values in a spreadsheet or broad-access bucket creates a new, concentrated exposure.
• Ignoring the people: heavy blocking with no safe alternative pushes sharing into personal messaging apps that the organisation cannot see at all.

Framework mapping

Practitioner checklist

• Run a historical secret scan across Slack, Teams, Jira and Confluence, storing fingerprints, not values.
• Rotate or revoke every live credential found before deleting or redacting the copy.
• Enable native secret detection (Slack DLP, Purview "All credentials", Atlassian Guard) where licensed, starting in alert mode.
• Scope Teams DLP policies to groups so channel messages are covered.
• Delete earlier Confluence versions that still contain a redacted secret.
• Give scanning integrations read-only scopes, an owner and a short lifetime.
• Remove password fields from ticket templates and add a vault-link alternative.
• Add credential rotation to the post-incident checklist for anything shared in incident channels.
• Track time to revoke and revoke-before-delete rate monthly.

Standards and references

• Slack Help Centre: Slack data loss prevention
• Slack Help Centre: Customise message and file retention policies
• Microsoft Learn: Data loss prevention and Microsoft Teams
• Microsoft Learn: All credentials sensitive information type
• Atlassian Support: What sensitive data is detected?
• Atlassian Support: What happens when data is redacted?
• Atlassian Support: What are findings?
• MITRE ATT&CK: Unsecured Credentials, Chat Messages

Related NHI Mgmt Group resources: Secrets Management Guide · Slack Tokens Security Guide · Microsoft Teams Security Guide · Atlassian Cloud Security Guide · Leaked Credential Response Playbook