What do teams get wrong about sharing secrets through collaboration tools?

Why This Matters for Security Teams

Sharing secrets in collaboration tools is not just a messaging habit problem, it is an identity and retention problem. Slack, Jira, Confluence, ticket comments, and bot threads all become secondary storage layers for credentials that should have been short-lived, scoped, and revocable. GitGuardian’s The State of Secrets Sprawl 2026 found that 28% of secrets incidents now originate outside code repositories in collaboration tools, and those incidents are 13% more likely to be critical than code-based leaks. That is why “delete the message” is not a control. Retention, indexing, exports, screenshots, and integration logs can keep the secret alive long after the workflow is finished. The deeper mistake is assuming convenience tools are temporary by default. In practice, collaboration platforms are searchable knowledge systems with broad access paths, not ephemeral vaults. This is exactly the kind of exposure pattern discussed in the Guide to the Secret Sprawl Challenge, where the real failure is uncontrolled propagation rather than a single careless post. The OWASP Non-Human Identity Top 10 also frames secrets as lifecycle assets, not disposable text. In practice, many security teams encounter the breach only after search indexing or bot forwarding has already replicated the secret beyond the original channel.

How It Works in Practice

The operational failure usually starts with a legitimate need for speed. An engineer posts an API key in chat, a project manager pastes a token into a ticket, or a bot relays deployment credentials into a channel. The team believes the secret is “safe enough” because the message was visible only to a small audience at the time. That assumption ignores three mechanics: persistent retention, broad retrieval, and downstream propagation. A more effective pattern is to treat collaboration tools as untrusted transport, not secret stores. Current guidance suggests these controls:

• Issue JIT credentials for the task, then revoke them automatically on completion.
• Use ephemeral secrets with tight TTLs instead of static long-lived tokens.
• Route approvals through PAM or a secret manager, not chat history.
• Apply RBAC and workflow permissions to who can request access, not to the secret itself.
• Disable or tightly govern bots, exports, and third-party apps that mirror content outside the platform.

For implementation, the strongest pattern is to pair prevention with rapid revocation. If a secret appears in Slack or Jira, the response should be to invalidate it immediately and replace it with a new credential boundary, not to rely on deletion. This is consistent with the broader lessons in Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack, where exposed credentials remained useful because lifecycle controls were weak. The OWASP Non-Human Identity Top 10 is a useful reference point here because it emphasises credential sprawl, weak revocation, and excessive trust in interconnected systems. These controls tend to break down when collaboration platforms are deeply integrated with ticketing, CI/CD, and eDiscovery systems because the secret is replicated faster than the response can remove it.

Common Variations and Edge Cases

Tighter secret handling often increases friction, so organisations must balance speed against containment. That tradeoff is most visible in incident response, customer support, and release engineering, where teams are tempted to paste credentials to avoid blocking work. There is no universal standard for this yet, but best practice is evolving toward “never share the secret, share the capability.” That means using time-bound links, delegated access, or one-time approval workflows instead of plaintext credentials. The edge cases are usually the hardest. A message deleted in the main channel may still survive in exports, audit archives, email notifications, or connected apps. Private channels are not a safe exception, because internal systems are still searchable and often over-permissioned. GitGuardian’s 2025 research noted that 38% of secrets incidents in collaboration and project management tools were highly critical or urgent, which is a strong warning that the issue is not just accidental leakage, but high-impact exposure. For governance alignment, current guidance from Ultimate Guide to NHIs — Static vs Dynamic Secrets supports replacing static secrets with short-lived identities wherever possible, while 52 NHI Breaches Analysis shows how often weak secret hygiene appears in broader identity failures. In practice, the hardest environment is a collaboration stack with bots, retention holds, and third-party integrations because no single team fully controls where the secret ends up.

Related resources from NHI Mgmt Group

• What do security teams get wrong about secrets in third-party code and integrations?
• What do teams get wrong about rotating NHI secrets after compromise?
• What do teams get wrong about tools versus resources in MCP?
• What do security teams get wrong about agentic AI security tools?