Groups:History is a Slack OAuth scope that allows an app to read the history of user groups. It is used with the API to inspect group membership changes and related group activity, and it exposes directory and communication data to the authorised application.
What the scope does in Slack OAuth
Groups:History is not a generic read-only permission, it is a scoped API grant that lets an application inspect the history of user groups. That means the app can observe membership changes and related activity over time, which is more sensitive than a simple current-state lookup because it exposes how groups evolve and who has been associated with them.
From a security perspective, the important point is that scope-based access is still access. If an application is authorised for this scope, it can retrieve directory-adjacent information through Slack’s API, so the practical boundary is defined by what the app can learn about group history rather than by whether it can modify groups.
Why group history access is sensitive
Group history can reveal organisational structure, role shifts, project participation, and the timing of changes to access-related groups. Even when the content is not overtly secret, the pattern of membership change can expose who is important, who is leaving, and how communication or decision-making is organised.
That makes the scope valuable for collaboration tooling and reporting, but also risky if overused. A benign integration can accumulate enough visibility to support profiling, social engineering, or unapproved internal mapping when it is granted broader history access than the use case truly needs. The risk comes from context leakage as much as from raw message content.
How organisations should think about exposure
Exposure begins with app review: know which Slack applications have this scope, why they need it, and whether they really need historical group visibility or only current membership data. Because OAuth scopes are granted at install time, the permission model can outlive the original business justification if it is not periodically reviewed.
It also helps to separate directory data, collaboration data, and analytics use cases. A team may justify one but not the others. If the scope is being used to inspect group activity, organisations should treat that as access to sensitive operational metadata and assess whether the same outcome can be achieved with a narrower data set.
Control implications for apps and admins
Minimise the number of apps that can read group history, and review them as part of routine access governance. For Slack environments with many integrations, the main control issue is not only whether an app is trusted today, but whether its data access still matches its current function.
- Prefer least-privilege scope requests and deny history access where the app only needs current membership.
- Review authorised apps after onboarding, ownership changes, or changes in business purpose.
- Treat history-accessing apps as higher sensitivity than simple workflow bots because they can infer organisational relationships over time.
What to watch for in practice
Watch for apps that request broad Slack scopes without a clear business explanation, or apps whose function has expanded from notification to analysis. A scope like Groups:History can become a quiet source of excess visibility when teams assume it is just another collaboration integration permission.
The safer operational pattern is to tie each granted scope to a documented use case, a named owner, and a review point. If that linkage is missing, the application should be treated as an access-risk candidate rather than as a routine productivity tool.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Groups:History is access to sensitive Slack group data, so least privilege directly limits scope breadth. |
| AC-2 — Account Management | OAuth app grants and their ownership need lifecycle governance and periodic review. | |
| AU-2 — Event Logging | Group-history access is security-relevant activity that should be recorded for review and investigation. | |
| Recommendation — Limit Slack app scopes to the minimum data access required for the approved use case. Inventory Slack app grants and review ownership when business need or app function changes. Log application access to group-history data and monitor for unusual retrieval patterns. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The scope directly embodies access permission design and should be constrained by least privilege. |
| Recommendation — Apply least-privilege scope design to each Slack integration that requests history access. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | API access to group history can expose functions and data beyond the app's intended role. |
| Recommendation — Verify each Slack app can call only the API functions needed for its approved role. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org