Slack OAuth for AI agents exposes the identity governance gap

At a glance

What this is: This is a guide to wiring Slack into an AI agent with OAuth 2 and Frontegg, with a clear focus on tool authorization, token handling, and scope selection.

Why it matters: It matters because identity teams now have to govern agent access inside everyday business tools, where delegated permissions can expand faster than existing IAM and PAM controls were designed to handle.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Frontegg's guide to connecting Slack to an AI agent with OAuth 2

Context

Slack integration for AI agents is an identity problem before it is an engineering problem. The core question is how an agent gets authorised to act inside a user-controlled collaboration tool without creating broad, persistent, or poorly understood delegated access. That puts OAuth scopes, token lifecycle management, and approval boundaries at the centre of AI agent governance.

For IAM teams, the article is a useful example of how agent access is usually assembled from familiar parts such as OAuth clients, redirect URIs, scopes, and stored tokens. The governance gap appears when those familiar controls are applied to a runtime actor that can select and use tools on behalf of users, especially when the access path is broader than the task actually requires.

Key questions

Q: How should security teams govern AI agents that connect to Slack through OAuth?

A: Security teams should govern Slack-connected AI agents as delegated identities, not as ordinary app integrations. That means approving scopes based on the specific task, storing tokens in a controlled identity layer, reviewing renewals and revocations, and recertifying the integration as part of access governance. The goal is to keep the agent’s authority narrow and auditable.

Q: Why do AI agents complicate least-privilege access in collaboration tools?

A: AI agents complicate least privilege because their permissions are defined by scopes that can be broader than a single task and may persist through refreshed tokens. A human may approve one action, but the agent can reuse that delegated access across multiple steps. Identity teams need to align the scope set with the exact workflow, not the general tool capability.

Q: When does Slack OAuth create more risk than it reduces for AI agents?

A: Slack OAuth creates more risk when the agent receives reusable or overly broad scopes for a workflow that does not need them. It also becomes risky when token refresh and revocation are not controlled centrally, because the delegated access can outlive the original intent. The safer pattern is task-scoped, time-bounded authorisation with strong auditability.

Q: What should IAM teams review after an AI agent is granted access to Slack?

A: IAM teams should review the approved scopes, token custody model, refresh behaviour, and revocation process. They should also confirm who owns the integration, what business action it supports, and whether the agent’s Slack privileges still match the current workflow. If the answer is unclear, the access model is already too loose.

Technical breakdown

OAuth 2 for AI agents and delegated Slack access

OAuth 2 is an authorisation framework, not an authentication system. In this setup, the Slack app acts as the client, the agent receives delegated tokens, and the identity layer stores and refreshes those tokens so the agent can perform approved actions. The security boundary is defined by scopes, redirect handling, and token custody. If those elements are loose, the agent can inherit more capability than the underlying task needs, even when the integration is technically correct.

Practical implication: treat every agent-tool OAuth flow as a delegated-access design exercise, not a connectivity task.

Token lifecycle and refresh handling for tool-connected agents

Token lifecycle is the operational control that keeps delegated access bounded after the initial consent event. For AI agents, token refresh logic matters because long-lived or reusable credentials can outlast the immediate task and become a durable access path inside collaboration platforms. A secure design separates token storage from the agent runtime, limits refresh eligibility, and logs every renewal and use. Without that discipline, the token becomes a standing capability rather than a controlled delegation artifact.

Practical implication: design token handling so the agent never needs reusable secrets in its own execution path.

Scopes as the real least-privilege control

OAuth scopes define which actions the agent may take, such as reading channels or sending messages. In practice, scopes are the closest thing to task-scoped privilege in this model, which makes them the decisive control plane for agent access. The article correctly points to selecting only the scopes needed for the intended tool capabilities. That matters because scope creep turns a narrow assistant into a broader actor with permissions that may never be justified by the workflow that created it.

Practical implication: build scope approval into the agent design review, not after deployment.

Threat narrative

Attacker objective: The objective is to obtain authorised, reusable access to collaboration tools so the agent can perform actions inside Slack with delegated user or app privileges.

1. Entry begins with a user or administrator completing Slack OAuth consent for the agent, which creates delegated access through a legitimate authorisation flow.
2. Escalation occurs when the agent receives more scopes than the immediate task needs, allowing actions such as channel reading or message sending beyond the narrow use case.
3. Impact is the ability to act inside Slack on behalf of a user or app, with stored tokens turning a temporary integration into a durable access path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegated tool access is now an identity governance problem, not just an app integration pattern. The article shows the standard OAuth shape for connecting Slack to an AI agent, but the governance question is who can authorise that access, how scopes are bounded, and how long the token remains valid. That places AI agent access squarely inside IAM, PAM, and lifecycle governance rather than leaving it to application teams alone. Practitioners should treat tool-connected agents as governed identities with explicit approval and review paths.

Scope-based authorisation is the closest thing to least privilege for AI agent tools. The article’s emphasis on choosing only necessary scopes is the right control logic because the agent’s practical authority is defined by what the token can do inside Slack. This is where agent access starts to resemble NHI governance: the risk is not merely authentication, but excessive delegated capability. The implication is that scope reviews must be part of access governance, not an afterthought during testing.

Runtime trust assumptions fail when an agent can act on behalf of users inside chat and collaboration systems. A human-paced approval model assumes the operator, the task, and the permission envelope stay aligned long enough for review. That assumption fails when the actor is an AI agent because the same token can support multiple actions across multiple tools with little visibility between consent and use. The implication is that identity programmes need to separate human intent from machine execution more cleanly.

Token lifecycle is the control that turns delegation into managed access instead of persistent exposure. The article’s focus on token refresh handling is a reminder that delegated access is only safe when renewal, storage, and revocation are instrumented and owned. In NHI terms, this is the boundary between a controlled credential and a standing credential. Practitioners should use that distinction to decide whether an integration belongs in an app team workflow or an identity governance workflow.

Slack-connected agents sharpen the identity blast radius of everyday SaaS tools. Collaboration platforms are attractive to agents because they already sit at the centre of work execution, which means a small scope decision can quickly become a broad operational privilege. That widens the blast radius from a single app to communications, workflow coordination, and downstream data handling. Security teams should map which business actions an agent can trigger, not just which API endpoints it can reach.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Another finding from the same survey shows that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• For a deeper governance baseline, Ultimate Guide to NHIs explains how token lifecycle, scope control, and lifecycle governance apply to non-human access.

What this signals

Tool-connected AI agents are forcing identity teams to move from app-level review to runtime governance. Slack integrations are a practical example of where delegated access, token custody, and scope selection must be treated as one control surface. The programme implication is that agent authorisation will increasingly sit alongside NHI review, not inside application onboarding alone.

Scope drift is the named concept this pattern should sharpen for practitioners. Once an agent can call multiple Slack actions from one delegated consent event, the real risk is not the initial connection but the widening gap between intended task and actual permission set. Security teams should expect that gap to appear first in collaboration tools before it shows up in more critical systems.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the governance gap is already visible. Teams should prepare for more agent-enabled SaaS access requests and build review workflows that can distinguish a valid delegated workflow from over-scoped privilege.

For practitioners

• Review every agent-tool OAuth scope set before deployment Approve only the minimum Slack scopes needed for the intended workflow. Compare the requested scopes against the actual business task, and reject broad read or write permissions that are not justified by the use case.
• Separate token custody from agent execution Store and refresh delegated tokens in a controlled identity layer rather than inside the agent runtime. Require logging for consent, refresh, and revocation events so credential use is auditable across the integration lifecycle.
• Treat AI agents as governed identities in access reviews Add agent-enabled Slack integrations to IAM and lifecycle review cycles. Recertify who approved the integration, which scopes remain necessary, and whether the agent still needs access to the same channels or actions.
• Map collaboration-tool actions to business risk tiers Classify Slack actions such as sending messages, reading channels, and editing content by sensitivity. Use that mapping to decide when a task needs additional approval, tighter scopes, or a different integration pattern entirely.

Key takeaways

• AI agent Slack integrations turn OAuth scopes into a first-class identity control, because delegated access is only as safe as the permissions behind it.
• Reusable tokens and broad scopes are the real exposure points, not the connection flow itself, which means lifecycle controls matter as much as approval controls.
• Identity teams should govern tool-connected agents through scope review, token custody, and recertification, not leave them inside ad hoc application onboarding.

Key terms

• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another identity within a defined scope. In AI agent workflows, it usually means an app or agent receives limited authority through OAuth tokens rather than direct user credentials, making scope and lifecycle controls essential.
• OAuth Scope: An OAuth scope is a permission boundary that limits what a token can do. For AI agents, scopes are the practical expression of least privilege because they define whether the agent can read, write, or modify data inside a connected application.
• Token Lifecycle: Token lifecycle is the full sequence of issuance, use, refresh, revocation, and expiry for a credential. In agent integrations, lifecycle management determines whether access remains tightly bounded or becomes a standing capability that can outlive the original task.
• Tool Authorization: Tool authorisation is the control process that decides which external systems an AI agent may use and what actions it can perform there. It is the point where identity governance meets runtime behaviour, especially when agents operate inside collaboration or productivity tools.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Frontegg: Learn how to integrate Slack into your AI agent using Frontegg's identity infrastructure. Read the original.