TL;DR: Slack’s identity sprawl problem shows up when one inventory surfaces people, guest accounts, bots and OAuth tokens, with posture flags for dormancy, non-MFA, SSO bypass and privilege drift, according to Unosecur. The governance gap is that access you cannot inventory or revoke quickly is effectively standing privilege.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should security teams govern Slack bots and OAuth tokens as identities?
A: Security teams should treat Slack bots and OAuth tokens as delegated non-human identities with owners, purpose, expiry and revocation paths.
Q: Why do collaboration platforms create hidden NHI risk?
A: Collaboration platforms create hidden NHI risk because access accumulates through guest invites, app installs, tokens and inherited roles that are easy to lose track of.
Q: What breaks when Slack access is reviewed only on a schedule?
A: Scheduled reviews miss the speed at which Slack access can become stale, over-privileged or abandoned.
Practitioner guidance
- Inventory Slack identities alongside other NHIs Pull people, guest accounts, bots and OAuth tokens into the same identity inventory used for cloud and SaaS access.
- Review nested roles for shadow-admin paths Trace indirect permissions through workspace groups and inherited roles to identify users or bots with hidden elevated access.
- Treat dormancy as excess privilege Flag inactive bots and stale guest accounts for removal or downgrade as soon as they lose business purpose.
What's in the full announcement
Unosecur's full announcement covers the operational detail this post intentionally leaves for the source:
- Step-by-step detail on how the Slack Connector discovers people, guest accounts, bots and OAuth tokens in a workspace.
- The specific posture flags used for dormancy, non-MFA, SSO bypass and privilege drift.
- How the one-click remediation flow records disable, revoke or downgrade actions for audit purposes.
- Deployment details for the read-only OAuth integration and agent-free setup.
👉 Read Unosecur's announcement on its Slack Connector for identity visibility →
Slack connector coverage: are your bots and tokens actually governed?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Slack identity governance is now an NHI problem, not a collaboration admin problem. Once bots, guest accounts and OAuth tokens sit alongside employee access, the control question shifts from workspace hygiene to delegated identity governance. The issue is not the chat channel itself. It is whether the organisation can inventory, classify and retire non-human access with the same seriousness it applies to cloud workload identities. Practitioners should treat Slack as part of the NHI estate, not a separate exception.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Aembit reports that 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge.
A question worth separating out:
Q: Who is accountable when a forgotten Slack token is abused?
A: Accountability usually sits with the team that owns the workspace, app integration and identity lifecycle for the token or bot. If ownership is unclear, the organisation has already failed the governance test. Access that can be created, expanded or forgotten without a named owner is not ready for audit, incident response or recertification.
👉 Read our full editorial: Slack identity governance gaps persist as bots and tokens spread