Should organisations allow Slack notifications to be sent on behalf of users?

Why This Matters for Security Teams

Allowing Slack to act on behalf of a user is not just a convenience decision. It creates a delegated identity path that can expose messages, files, approvals, and downstream workflow actions if the permission scope is too broad or the re-authentication model is weak. Collaboration tools are already a high-value target surface: GitGuardian reports that 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent, which is a useful reminder that message automation often touches sensitive data sooner than teams expect. The control question is therefore not whether notifications are useful, but whether the identity binding is narrow, revocable, and auditable. Guidance from the NIST Cybersecurity Framework 2.0 supports treating this as an access governance issue, not a UI preference. Where organisations also use delegated workflows for incident response, the lessons from the Schneider Electric credentials breach show how quickly trust can collapse when token handling and permissions are not tightly controlled. In practice, many security teams encounter this only after a stale integration keeps posting long after the user has left or revoked access.

How It Works in Practice

The safest pattern is user-scoped delegation with explicit consent, short-lived tokens, and automatic revocation on uninstall, password reset, or role change. Slack app permissions should be limited to the smallest set of channels and actions needed for the workflow, and notifications should be sent only when the app can prove the user identity behind the action. For identity governance, that means treating the Slack integration as a non-human identity with its own lifecycle, not as a permanent extension of a person. NHI controls such as least privilege, rotation, and offboarding are directly relevant here, and the Schneider Electric credentials breach is a cautionary example of how delegated access and credentials can outlive the business need that created them.

Practical implementation usually includes:

• JIT authorization for sensitive notification actions rather than standing approval for all message types.
• Ephemeral secrets or access tokens with tight TTLs, especially where the app can post on the user’s behalf.
• Explicit re-connection after revocation, reinstall, or workspace changes so old grants cannot persist silently.
• Audit logs that preserve who approved the delegation, what scopes were granted, and when the token was last validated.
• RBAC for administrators, but runtime checks for the user’s current context, because static roles do not fully capture delegated messaging risk.

This aligns with the NIST Cybersecurity Framework 2.0 emphasis on access control and continuous governance, while also fitting Zero Trust expectations that trust should be re-evaluated, not assumed. Where organisations have broader NHI programs, the same principles show up in the Schneider Electric credentials breach lessons on revocation discipline and blast-radius reduction. These controls tend to break down in large, multi-workspace environments because admin consent, channel membership, and app reinstall flows often vary by workspace and create inconsistent revocation behaviour.

Common Variations and Edge Cases

Tighter delegated-access control often increases user friction and support overhead, requiring organisations to balance delivery speed against revocation reliability. There is no universal standard for every Slack use case, so current guidance suggests using stricter controls for anything that can expose data, trigger approvals, or alter records, and lighter controls only for low-risk status updates. If the notification simply mirrors a completed workflow and never reveals secrets or sensitive content, the risk is lower, but the identity path still needs to be explicit.

Some edge cases deserve special caution. Shared channels and cross-tenant workspaces can make scope validation harder, especially when message routing depends on external identities. Service-managed notifications are often safer than true “on behalf of user” posting because they avoid overloading a human identity with persistent machine behaviour. If the workflow is driven by an agent or automation pipeline, the issue becomes even more sensitive: autonomous systems should use workload identity and short-lived credentials rather than borrowing user credentials, because their behaviour is goal-driven and can change at runtime. That is why teams should separate human delegation from machine delegation wherever possible. The NIST Cybersecurity Framework 2.0 is helpful for governance alignment, but the operational answer often depends on how quickly revocation is enforced and whether message content can be independently classified. If the organisation cannot guarantee immediate offboarding and scope shrinkage, the safer choice is to deny persistent “on behalf of user” notifications entirely.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?