TL;DR: Slack agents should read with the requesting user’s token and write with the app’s bot token, according to Agentic Fabriq, because user tokens mirror the user’s workspace view while bot tokens preserve attribution and survive installer churn. The identity model, not convenience, determines safe access boundaries.
At a glance
What this is: This is a Slack identity and OAuth analysis for AI agents, showing that read and write actions should split across user and bot tokens to preserve least privilege and attribution.
Why it matters: It matters because practitioners building AI agents in Slack have to govern who the agent can see, who it can speak as, and how those permissions scale across many workspaces.
By the numbers:
- Since May 29, 2025, new installs of unlisted commercial apps get conversations.history and conversations.replies at 1 request per minute and 15 objects per call.
Context
Slack agents create a governance problem when one system needs to act under two identities at once. A read action should be bounded by what the requesting user can already see, while a write action should be attributable to the app, not to a person who never typed the message.
The core issue is not token format but identity scope. Once a Slack agent can search, summarise, and post across many customer workspaces, teams have to decide whether each action inherits the user’s permissions, the bot’s workspace membership, or neither by default.
Key questions
Q: How should security teams separate read and write access for Slack AI agents?
A: Give the agent the requesting user’s token for search and the app’s bot token for posting. That preserves least privilege, keeps message attribution clear, and prevents one credential from silently expanding access across private channels, direct messages, or other workspace areas the user may not legitimately see.
Q: Why do installer tokens create risk in multi-user Slack workflows?
A: An installer token often belongs to the first admin who completed consent, not to every later user. Reusing it for searches means each request can inherit that admin’s wider visibility, which collapses individual authority and makes the agent answer questions with access the requester never had.
Q: What signs show a Slack agent is using the wrong identity model?
A: The clearest signs are messages that appear under a person’s name when they should show the app, search results that exceed the requester’s normal Slack visibility, and a single stored credential that serves every user. Those symptoms indicate the token model has been flattened into one shared access path.
Q: When do Slack API limits become an architecture issue for agents?
A: They become an architecture issue when the agent depends on conversation history, cross-workspace distribution, or long-lived retained copies of Slack data. At that point, token choice, retrieval timing, and retention policy are one design problem, because distribution status and API terms can constrain how the agent works.
Technical breakdown
User tokens vs. bot tokens in Slack
Slack treats user tokens and bot tokens as different identity types, not interchangeable credentials. A user token represents a workspace member and carries that member’s visibility, while a bot token represents the app’s bot user and only sees channels where it has been added. For an AI agent, that means search, summary generation, and action-taking do not share the same identity boundary. The correct design separates what the agent may discover from what it may publish, instead of letting one credential impersonate both roles. See the AI Agent Authorisation Guide.
Practical implication: bind search-style reads to the requesting user and keep outbound messages on the bot identity.
How combined Slack installs issue two grants
Slack OAuth v2 can return both a bot token and a user grant in one consent flow. The installation record belongs to the workspace or organisation, while the user grant belongs to the person who authorised it. For multi-workspace agents, that separation matters because the same app may hold one bot credential per installation and multiple user credentials per person. The architecture therefore needs two storage and lookup paths, not a single universal token store that blurs who approved what. See the Agentic AI Identity Guide.
Practical implication: store installation credentials and user grants separately so token selection follows the authenticated requester.
Why workspace distribution changes the access model
Once an app moves from a single workspace to broad distribution, rate limits and API terms become part of the identity design. Slack’s unlisted commercial installs face tighter history-read limits, and the platform’s terms restrict long-term copying of other organisations’ API data. That means an agent that relies on historical Slack search is no longer just an identity question; it is also a retrieval and retention question. The programme must decide whether to fetch at query time or obtain a reviewable distribution path that supports the intended read pattern. Read Zero Trust for AI Agents.
Practical implication: align token strategy with distribution status before building any Slack history-heavy agent.
Threat narrative
Attacker objective: The objective is to obtain broader Slack visibility or misattribute agent output by collapsing distinct user and bot identities into one credential path.
- Entry begins when a customer installs the app and grants both bot and user scopes through Slack OAuth v2.
- Credential access occurs when the product stores the bot installation and the user grant separately, because each credential controls a different view of Slack data.
- Escalation appears if the system reuses the installer’s user token for every search, expanding one admin’s visibility to unrelated end users.
- Impact follows when the agent reads or posts with the wrong identity, exposing private workspace content or misattributing its output to a person.
Breaches seen in the wild
- Slack GitHub breach 2022: Slack employee tokens stolen via a compromised vendor were used to download private GitHub repositories over the 2022 holidays.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Token identity is now the control plane for Slack agents: the question is not whether an agent can act in Slack, but which identity it should inhabit for each action. When search and messaging are split cleanly, the agent inherits only the permissions that match the task. The practitioner takeaway is to treat token choice as a policy decision, not an implementation detail.
Installer-token reuse is a privilege-escalation pattern, not a convenience: using the first admin’s credential to answer every user’s query turns an installation artifact into a de facto shared access model. That breaks the assumption that each requester is bounded by their own visibility. The implication is that token stores must preserve per-user authority, not collapse it into one privileged grant.
Slack agent governance is shifting from static consent to action-scoped authority: the right design asks who is speaking, who is reading, and whether the answer needs to be attributable to a person or to the app. AI Agent Authorisation Guide maps directly to this split because least privilege for agents is enforced per action, not per deployment.
Multi-workspace distribution creates identity blast radius: once the same agent spans many customer workspaces, the consequences of token confusion scale with every install. That is why the strongest control is not a bigger permission bundle but tighter separation between installation identity, user grant, and message attribution. Practitioners should assume that one blurred token model becomes a cross-customer governance defect.
Slack’s history limits make retrieval design part of identity design: an agent that searches prior conversations is governed by both access scope and distribution status. The named concept here is identity-retrieval coupling: when the ability to answer depends on how the credential is scoped and how Slack permits history reads. Teams should plan for that coupling before they promise interactive search at scale.
From our research library:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Authorisation Guide
What this signals
Slack agents will become more reliable when teams stop treating token selection as a connector detail and start treating it as a governance boundary. The next programme decision is whether the agent’s answer should be bounded by the requester’s view, the bot’s channel membership, or a hybrid policy that changes by action type.
Identity-retrieval coupling: when conversational search depends on both access scope and data retention constraints, the identity model and the retrieval architecture cannot be separated. Teams that design Slack search as a background indexing problem will hit policy limits faster than teams that design it as a per-request entitlement problem.
Zero Trust for AI Agents is the right lens for this pattern because Slack’s own permission model already assumes action-level verification, not ambient access. For practitioners, that means a Slack agent should prove whose authority it is using before each read or write, rather than inheriting a broad standing grant.
For practitioners
- Separate read and write identities Use the requesting user’s token for search and the app’s bot token for posting, so visibility and attribution stay aligned with the action.
- Store installation and user grants independently Keep bot installations keyed by workspace or enterprise and user grants keyed by both your internal user and the Slack user ID.
- Reject installer-token shortcuts Never route all searches through the first admin’s user token, because that silently expands one person’s workspace view to everyone.
- Design for Slack distribution constraints Treat Marketplace review, rate limits, and API-term retention limits as architectural inputs before committing to history-heavy agent workflows.
Key takeaways
- Slack agents should not use one credential for both reading and writing, because the action type determines whose authority is being exercised.
- The biggest operational risk is collapsing installation identity, user authority, and message attribution into a single token store.
- Distribution limits and API retention rules are part of the access model, so Slack history workflows must be designed as governance decisions, not just integration work.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article hinges on choosing the right Slack credential for each action. |
| NHI-05 — Overprivileged NHI | Installer-token reuse and broad user grants can overextend one credential across many users. | |
| NHI-09 — NHI Reuse | Reusing one installer credential for every query is the exact failure mode discussed. | |
| Recommendation — Use action-scoped authentication so the agent reads as the requester and writes as the app. Reduce standing access by keeping user grants and bot installations separate and narrowly scoped. Prevent credential reuse across users by binding each Slack search to the correct authenticated person. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Credential misuse here expands one admin’s visibility into other users’ data paths. |
| Recommendation — Map token reuse to credential access and lateral movement to prioritise containment of shared grants. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle, rotation and separation are central to the article’s control model. |
| Recommendation — Apply authenticator management to keep bot and user tokens distinct, rotated and revocable. | ||
Key terms
- Slack User Token: A Slack user token represents a specific workspace member and carries the access that person was allowed to use. In agent workflows, it should be reserved for requests that need the requester’s own visibility, because it mirrors the user’s permissions rather than the app’s.
- Slack Bot Token: A Slack bot token represents the app’s bot identity in a workspace or organisation, not a human user. It is the correct credential for posts that should appear as the app and for actions that must survive user churn without inheriting one person’s identity.
- Installer Token: An installer token is the user credential returned when the first person authorises an app, often an administrator. It becomes risky when reused as a general-purpose credential, because it can silently grant later requests the installer’s broader Slack view.
- Identity-Retrieval Coupling: Identity-retrieval coupling is the dependency between who may read data and how the system fetches it at runtime. In Slack agents, it means search, retention and distribution rules must be designed together, because the credential model directly shapes what can be retrieved.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org