Agent Setup From Slack in Enterprise Environments

Slack is turning into the front door for enterprise AI agents, and that door is being installed faster than the locks. Employees can now spin up an agent from inside a Slack channel in seconds, but the identity checks, credential handling, and approval gates that make that safe have to exist before the first workflow runs, not after someone notices data leaving the building. Get that sequence backward, and Slack's biggest strength, its role as the running memory of a company's channels, threads, and files, becomes the exact thing that puts the company at risk.

The scale of what's coming makes the timing matter. IDC projects active enterprise AI agents growing from 28.6 million in 2025 to more than 2.2 billion by 2030. The average enterprise already juggles more than 1,000 applications and loses up to 40% of productivity to context switching between them, and Slack is positioning itself as a primary layer for that agent work. Slack's pitch as a unified layer for agent work is a direct answer to that fragmentation. Three kinds of agents now live there: Agentforce, which draws on conversational and enterprise data to suggest and automate actions; custom-built AI assistants that developers wire up through purpose-built APIs; and third-party assistants pulled from the Slack Marketplace. Slack's Real-Time Search API and its native MCP server support let partners including OpenAI, Anthropic, Google, Perplexity, Writer, Dropbox, Notion, Cognition Labs, Vercel, and Cursor build agents that act on live conversational context rather than stale snapshots.

Slack Code, launched August 20, 2026, shows what a governed version of this looks like. Dedicated channels let teams watch, steer, review, and approve work from Anthropic's Claude Code, Cognition's Devin, GitHub Copilot, and Vercel's agent (with ChatGPT from OpenAI expected soon after launch), and nothing reaches production without a human sign-off. Channels auto-archive when a project closes, and every agent action lands in an audit log. The model is the setup just described: channels auto-archiving when a project closes and every agent action landing in an audit log. Most of Slack's agent traffic isn't running through it yet.

What MCP is and why it sits beneath almost every agent launched from Slack

Nearly every agent connecting to a tool from inside Slack is talking through MCP, the Model Context Protocol. Anthropic built it and released it in November 2024; it's now vendor-neutral, donated to the Linux Foundation's Agentic AI Foundation in December 2025. The mechanics are simple enough to sketch in one breath: a host app embeds a client, the client talks to external MCP servers using JSON-RPC 2.0, and those servers hand the agent a menu of tools, resources, and prompts it can call on.

Before MCP existed, wiring N tools to M different agent front-ends meant building a custom connector for every single pairing. MCP collapsed all of that into one shared protocol, and the industry adopted it fast: the Cloud Security Alliance counted more than 150 million package downloads by mid-2025, over 12,000 public MCP servers were indexed by February 2026, and monthly download counts reached around 97 million by early 2026. Anthropic still built it, but it's now co-governed under the Agentic AI Foundation alongside Block and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it too.

Here's the design choice that changes the risk calculus. Traditional APIs mostly wait for a client to ask for data. MCP flips that: servers are often built to query and execute actions on a client's behalf, once invited in. That reversal opens attack paths that conventional API security tooling was never built to catch, because it was built to watch requests, not to judge intent. Inside Slack, an employee who installs or simply invokes an agent is implicitly connecting to one or more MCP servers, and the agent then picks which tools to call based on its own reasoning. The attack surface stretches from that one Slack message all the way through the full decision chain the agent runs afterward. MCP's flexibility was intentional. Its security model, by contrast, was left thin, and Gartner expects 40% of enterprise applications to carry task-specific AI agents by the end of 2026, with 75% of API gateway vendors shipping MCP-native features by the same deadline.

The five MCP attack vectors that make unsecured Slack agent setup dangerous

Tool poisoning happens when a tool's written description gets read by the language model, but that text rarely appears anywhere a human can see it at runtime. Invariant Labs proved the danger in April 2025: a fake "fact of the day" MCP server buried hidden instructions inside its own tool description, aimed at a legitimate WhatsApp MCP server running in the same session. The agent pulled message history and routed it out through the trusted server, so the traffic looked ordinary the whole way. The same attack pattern applies in finance workflows: if an enrichment server's tool description is quietly edited after approval, a routine question can cause the agent to gather sensitive data and route it out without triggering any alert. Analysis from obot.ai found tool poisoning issues in 5.5% of the open-source MCP servers checked.

Indirect prompt injection is what let EchoLeak (CVE-2025-32711) work by hiding instructions in an email. When Microsoft 365 Copilot later read that email while answering an unrelated user question, it triggered data exfiltration proxied through a Teams domain to servers the attacker controlled. No large file transfer, no DLP trigger. Before a related Supabase incident, a coding agent connected to GitHub with elevated repository access processed a public GitHub Issue containing embedded instructions to pull private repository code. Then, in July 2025, General Analysis documented the Supabase case itself: a coding agent holding service-role privileges read a support ticket that included plain-text instructions to query a table of integration tokens, and it complied, posting live credentials into a public thread. No network intrusion needed. The words in a support ticket did the work.

Supply chain attacks and rug pulls exploit the trust developers place in third-party packages and marketplace listings. Between January and February 2026, researchers filed more than 30 CVEs against MCP servers, clients, and infrastructure. One of them, CVE-2025-6514, scored 9.6 on the CVSS scale and hit the widely used mcp-remote proxy package across more than 437,000 installed environments. Separately, Antiy CERT confirmed 1,184 malicious skills sitting in the ClawHub marketplace for the OpenClaw agent framework.

Unauthenticated server exposure persists because the MCP authorization spec defines OAuth 2.1 as the standard, but it marks authorization optional, which is exactly the kind of soft rule that gets skipped under deadline pressure. An internet scan in July 2025 found at least 1,862 publicly reachable MCP instances answering unauthenticated requests. By early 2026, estimates put the number of internet-exposed MCP servers somewhere between 8,000 and 12,500, with roughly 40% running no authentication at all. Trend Micro separately found 492 MCP servers sitting open to the internet with zero authentication.

Agent-to-agent identity exploitation follows from agents trusting each other by default, and that default is exploitable through impersonation, session smuggling, and unauthorized capability escalation. Picture a compromised research agent that slips hidden instructions into output a financial agent later consumes, and that financial agent then acts on instructions it never should have trusted. Local MCP servers connecting over STDIO transport make this worse: they need no authentication, since they lean on the host process's own trust boundary. That's a real blind spot in Slack deployments, where agents get spun up in minutes.

Put a Slack channel in front of all five vectors, and the whole chain becomes reachable from a single message an employee types without thinking twice.

How far governance has fallen behind adoption

The gap between deployment and readiness isn't marginal. Cisco's State of AI Security 2026 found 83% of enterprises have deployed or are planning AI agents, yet only 29% believe they have solid agent security capabilities in place. That's a 54-point gap, and it's the easiest door for an attacker to walk through right now. Okta's AI at Work 2025 research found 91% of organizations already using AI agents, while 44% have no governance framework at all. IBM's Cost of a Data Breach Report 2025 found 63% of breached organizations had no AI governance policy in place at the time they were hit.

Turn Cisco's numbers around and the sharper read is this: 71% of organizations are running agents they can't properly watch. That's not a hypothetical exposure. Between December 2025 and February 2026, a single attacker used Claude to breach several Mexican government bodies, including the federal tax authority, the electoral institute, four state governments, and a water utility in Monterrey. As of May 2026, the Cloud Security Alliance counted at least seven confirmed high- or critical-severity CVEs spanning major MCP-integrated platforms, among them MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf.

OX Security's disclosure, nicknamed the "Mother of All AI Supply Chains," found a STDIO design flaw touching an estimated 200,000 vulnerable instances across a supply chain built on more than 150 million package downloads. Anthropic confirmed the behavior was intentional and declined to change the protocol's architecture, leaving individual developers to patch around it on their own. None of this sits in the future tense. It's the condition most enterprises are already deploying agents under, from Slack, today.

What identity and authentication must look like before the first agent runs

MCP's own spec has been trying to catch up. The November 2025 update (version 2025-11-25) sharpened OAuth 2.1 as the standard for authenticating remote MCP servers, building on groundwork laid in March 2025 and reinforced in June 2025. PKCE is now mandatory for every public client, and a new step-up authorization mechanism lets a server respond to a request with a 403 and a list of scopes it still needs, so privilege can escalate dynamically rather than getting granted all at once. Since the June 2025 update, servers are treated as OAuth resource servers, shifting how token validation is handled in the protocol.

Local STDIO connections remain the soft spot. They need no authentication at all, running instead on the host process's trust boundary and often configured through plain environment variables, and that happens to be the setup most likely to get used when an employee wants an agent running inside Slack in the next five minutes. Enterprise-Managed Authorization, now an available extension, addresses the other problem: it lets an organization provision MCP server access centrally through its identity provider, so a user gets connected to approved servers on first login instead of clicking through a separate OAuth flow for every app. Anthropic, Microsoft, and Okta are adopting it, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase already support it, and Slack is actively building it in.

What this means in practice for a Slack rollout comes down to four things. Single sign-on needs to attach to every agent identity, not just the human who launched it. SCIM needs to handle lifecycle management, so an agent's access disappears the moment an employee offboards. Credentials need to be provisioned just-in-time rather than stored long-term, so no long-lived secret ever sits exposed to the model itself. And credential handling needs to stay invisible to the employee typing in Slack while remaining fully auditable to the security team watching from the other side.

Slack's Real-Time Search API already respects permission inheritance, meaning AI applications follow the same access rules as the human users they act for, and agents get treated as participants with their own permission structures and audit trails. That only holds, though, if the identity layer wires access correctly, since misconfiguration there produces the failures that follow. Skip that step, and developers fall into the same trap that broke Supabase: exposing raw data credentials directly to the model instead of routing through a scoped credential that limits what a compromised session can actually reach.

Governing what agents can do: permissions, scoping, and human approval gates

Slack Code makes the underlying governance principle visible in a way most deployments don't: agents work inside channels the whole team can watch, steer, and review, nothing ships without a human approval, and closed projects leave behind an archived channel with a full audit trail. That's the shape every Slack agent deployment needs, even outside the specific product.

Permission scoping produces that result by determining which calls and data an agent can reach. An agent should inherit only what the person who invoked it is authorized to see, never service-role or admin-level access by default. It should be able to call only the tools its specific workflow needs, not every tool a connected MCP server happens to expose. On the Slack Marketplace side, Slack runs a preliminary quality and security review before any third-party agent gets published, requires companies to agree to guidelines that prohibit training LLMs on Slack data, and requires disclosure of security and compliance details, while workspace owners and admins keep control over which agent apps get added in the first place.

Human approval gates for write-back actions aren't a nice-to-have. They're the structural control that tool poisoning and prompt injection attack most directly, and without them a single poisoned tool description can trigger a real-world action that can't be undone. Tool description changes, specifically, need to trigger re-approval on their own. The Microsoft finance-workflow attack succeeded because a description edit slipped through without re-earning trust, and that's a policy failure, not a technical limitation, which means it's fixable without waiting on a protocol update.

Multi-agent Slack workflows need explicit authorization checks at every handoff between agents, because implicit trust between agents is exactly the mechanism attackers lean on in agent-to-agent identity exploitation. Every agent running inside Slack should carry a registered identity, a named owner, and a written permission scope. An agent without those three things is invisible to the security program, whether or not anyone meant it to be. The OWASP Top 10 for Agentic Applications, released December 2025, now sits next to the older LLM Top 10 as a reference point here, and two categories map directly onto Slack deployments: ASI02, Tool Misuse, and ASI04, Agentic Supply Chain Vulnerabilities.

Real-time detection and audit: what security teams need to see once agents are running

Conventional security tooling wasn't built for any of this. WAFs, API gateways, DLP systems, and SIEMs were designed to evaluate traffic, checking whether a request looks like the requests that came before it. None of them were built to judge whether the reasoning behind a tool call makes sense. Both the Supabase incident and EchoLeak passed straight through environments that had these conventional controls sitting in place the whole time, because the attacks didn't look wrong from a traffic standpoint. They looked like an agent doing its job.

Catching tool poisoning means watching tool descriptions continuously for changes at runtime, not just checking them once at install and calling it done. Catching prompt injection means running semantic analysis on the actual content an agent processes, since EchoLeak moved data out through HTTP requests small enough to slide under the size thresholds most detection systems are tuned to flag. Security teams evaluating Slack's agent layer need visibility that matches the shape of these threats: continuous, content-aware, and built around intent rather than just traffic volume. Anything less leaves the same blind spot that let EchoLeak and Supabase happen in the first place, just with a Slack channel instead of an email inbox as the entry point.