Why do collaboration tools create such a large secrets risk?

Why This Matters for Security Teams

Collaboration tools are where security work becomes conversational, and that is exactly why secrets end up there. Engineers paste credentials into chat to unblock incidents, project managers collect tokens in tickets, and support teams attach configuration data to documents for speed. Those channels are designed for visibility and persistence, not secret handling, so the result is shadow storage that bypasses normal rotation, approval, and revocation workflows. GitGuardian found that 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent in The State of Secrets Sprawl 2025.

The core failure is not user carelessness alone. It is that collaboration platforms sit outside the control plane most teams use for secrets, so a credential can be shared once and then survive in search, backups, exports, and threaded replies long after the original incident is forgotten. That makes the risk durable, discoverable, and hard to unwind. The governance gap is also why guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 increasingly treats secret handling as an operational discipline, not just a repository setting. In practice, many security teams encounter collaboration-tool leakage only after an incident review has already exposed how widely the secret was shared.

How It Works in Practice

Collaboration tools become a secrets sink because they are optimised for fast, human-readable coordination. That makes them ideal for troubleshooting, but poor for credential governance. A developer pastes an API key into Slack to reproduce a failure. A responder shares a certificate in Jira to unblock a release. A Confluence page stores an emergency token so the next shift can continue the work. Each action seems temporary, yet the platform preserves content, indexes it, syncs it to mobile and desktop clients, and often exposes it to broader audiences than intended.

This is why secret risk in collaboration channels is usually a process failure before it is a technical breach. Controls need to extend beyond source control into the places where people actually exchange operational data. That means three things in practice: detect secrets in messages and attachments, revoke and rotate exposed credentials quickly, and build a better path for legitimate sharing so teams are not forced to improvise. NHIMG research on Guide to the Secret Sprawl Challenge shows why sprawl is rarely confined to code, and the Shai Hulud npm malware campaign is a reminder that exposed secrets are often harvested well after the original leak.

• Set DLP and secret scanning rules for chat, ticketing, and document systems, not only Git.
• Use short-lived credentials where possible, so a pasted secret expires before it can be reused.
• Quarantine and revoke anything found in collaboration tools as if it were public.
• Give responders approved channels for temporary access, such as JIT workflows and vault-backed sharing.

Current guidance suggests that this breaks down most often in fast-moving incident response environments, where speed pressures defeat normal approval steps and make ad hoc sharing feel unavoidable.

Common Variations and Edge Cases

Tighter secrets controls often increase friction, requiring organisations to balance rapid troubleshooting against reduced exposure. That tradeoff becomes sharper in teams that operate across time zones, use contractor-heavy support models, or run major incident bridges where many people need to see the same information quickly. In those settings, the real question is not whether secrets should ever appear in collaboration tools, but how to minimise the damage when they do.

One edge case is operational runbooks that include example credentials or copied configuration snippets. Another is federated workspaces, where external guests can access messages or files that internal teams assume are restricted. A third is regulated environments where retention policies preserve everything by design, which can extend the lifetime of a leaked secret far beyond its usefulness. Best practice is evolving here, but there is no universal standard for every collaboration platform’s secret-handling model.

That is why many teams pair preventive controls with architectural change. The broader lesson from OWASP NHI Top 10 and the NHI research in Ultimate Guide to NHIs — Static vs Dynamic Secrets is that static credentials create long-lived exposure wherever they are copied, while dynamic secrets reduce the blast radius. In practice, the safest collaboration model is the one that makes secret sharing unnecessary, because every extra exception becomes a future incident record.

Related resources from NHI Mgmt Group

• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?