Agent Setup From Slack in Enterprise Environments

Slack is now the structural center of how large companies deploy AI agents, and that happened by design, not by accident. Salesforce co-founder and Slack CTO called Slackbot "the front door to the Agentic Enterprise"; at TrailblazerDX 2026, held April 15 to 16 in San Francisco. That phrase describes an architecture in which Slackbot now functions as a complete MCP client that can pull together work across Agentforce agents, thousands of Slack Marketplace apps, and more than 6,000 AppExchange applications, all from a single conversation thread.

This matters inside Salesforce itself. Tens of thousands of Salesforce employees use Slackbot every week to read and update records in their own CRM. Among every tool Slackbot calls, the Salesforce MCP server ranks second only to Slack's own search function. That ranking says something simple: people are not just chatting with Slackbot. They route real work through it, tied to real systems, all the time.

Everything that follows in this piece, the mechanics of MCP, the threats, the governance gaps, the new spec, only matters because Slack has already become the place where agents get built. When tens of thousands of employees use a tool every week to touch production CRM data, that is infrastructure. And infrastructure that grows this fast, through a chat interface everyone already has open, is exactly the kind of infrastructure that outpaces the controls meant to govern it.

What MCP does when an agent launches from Slack

If someone sends an ordinary Slack message, MCP is what turns it into a working agent with real access to enterprise systems. That means every time someone sets up an agent from Slack, they trigger an MCP deployment, complete with its own permissions and its own trust assumptions.

The protocol runs on a three-part structure: Host, Client, Server. Slackbot plays the Host. It has a Client inside it, and that Client talks to external MCP Servers in a messaging format called JSON-RPC 2.0. The Servers are where the real capability lives: they expose Tools (actions the agent can take), Resources (data it can read), and Prompts (instructions that shape how it behaves).

When an employee kicks off agent setup inside Slack, the agent finds whatever MCP servers are out there, reads their tool descriptions, and takes on whatever permissions those servers happen to carry. All of that happens before a single human reviews any of it. There is no pause for approval built into the handshake. The agent discovers, reads, and inherits access in one motion.

What makes this especially consequential at enterprise scale is how much gets bundled into one click. One interface can hold credentials pulled from many systems at once, because MCP servers get built that way. A single "Add to Slack" action can connect an agent to CRM records, code repositories, ticketing systems, and internal databases, all at once. That's convenient for the employee setting it up. So one casual approval can open doors across an entire stack of enterprise systems at once.

The security threats that are specific to MCP-based agent setup

The risks from MCP-based agent setup don't look like the software vulnerabilities that security teams have spent decades learning to catch. They live in a different place entirely: in metadata that no employee ever sees, but that the agent reads as if it were a direct order.

Tool poisoning is the clearest example, and it's the attack that does the most damage to MCP-based agents today. Attackers write malicious instructions directly into a tool's description field. That description gets fed into the model's context window, but it never appears anywhere in the interface the employee used to set the agent up. Microsoft's Incident Response and Defender teams disclosed a case from mid-2026 showing how this plays out: a finance team connected its agent to a third-party invoice enrichment tool. The tool had been approved, but it never got a real security review. Later, the attacker simply edited the tool's hidden description. MCP picks up description changes automatically, so the poisoned version went live with no re-approval, no alert, nothing. Most host applications, Slack-based agents included, truncate tool descriptions or never show the full text to the person who authorized the integration in the first place. The attack works precisely because it was never meant to be seen.

Unauthenticated servers compound the problem. Trend Micro identified 492 MCP servers sitting exposed on the open internet with no authentication at all. Standing one of these up against a production database takes an afternoon, and once an agent has discovered it, that server's tools become part of what the agent can act on. If a server is compromised, unauthenticated, and exposed, it becomes a point of failure across every system it touches and every other agent that relies on it.

Supply chains carry the same risk. In February 2026, Antiy CERT confirmed 1,184 malicious skills circulating inside the ClawHub agent-skill ecosystem, first flagged by Koi Security on February 1, 2026. Snyk's ToxicSkills audit went further: it examined a large sample of these skills and found that a meaningful share carried at least one critical security flaw. Even official infrastructure isn't immune. On January 20, 2026, researcher Yarden Porat published an exploit chain against Anthropic's own Git MCP server, three separate CVEs covering unrestricted repository initialization, argument injection, and a path traversal bypass. In June 2026, an agentjacking technique using Sentry MCP event injection hit a significant number of organizations running injectable DSNs, with a high success rate in testing by Tenet. Sentry declined to fix the underlying issue, and instead it deployed a payload-string filter. Microsoft's Azure MCP Server had its own authentication bypass, CVE-2026-32211, rated 9.1 on the CVSS scale, which let attackers pull API keys and tokens without any credentials at all. That one got patched, but it shows how deeply this exposure runs through protocol-adjacent infrastructure, not just the protocol itself.

The most unsettling pattern is lateral movement between agents. Cisco's 2026 report documents an internal enterprise case where an attacker first compromised a low-privilege data query agent by poisoning the external data source it relied on, then used that agent's own cross-agent communication channel to send disguised requests to a much higher-privilege financial approval agent. That's the exact scenario that makes Slack-based agent setup so sensitive: an employee spinning up a low-stakes agent for a routine task can, without knowing it, build a bridge straight into higher-privilege agents already running somewhere else in the environment.

None of this traces back to a single fixable bug. The MCP STDIO transport runs operating system commands with no sanitization or validation step, and the protocol specification has no built-in defense against tool poisoning, rug pull attacks, or one server shadowing another's tools. An NSA advisory from June 2026 put it directly: the traditional pillars of cybersecurity, authentication, authorization, input validation, remain necessary but no longer sufficient on their own. Agentic AI systems carry risks that established defense strategies were never built to catch.

These are not a handful of isolated incidents.

Governing what enterprises are already deploying

Most enterprise governance today was built for AI that answered questions, not for AI that takes action. That infrastructure was never built for agents that read files, update records, call APIs, and invoke other agents on their own, with no one in the loop.

The numbers show how wide that mismatch has grown. Cisco's State of AI Security 2026 Report found that 83% of global enterprises have already deployed AI agent applications or are actively planning to, while only a small share believe they're genuinely prepared for the new risks agents bring. Cisco calls that gap the easiest entry point for attackers.

So you see that same gap again in how agentic pilots move toward production. Only a small fraction of enterprise agentic AI pilots make it to production with full security approval. Most stall out on identity, audit, or access-control problems. The agents that do reach production often got there by routing around the exact controls that stopped the others. Identity governance for AI agents produces this gap: it remains rudimentary almost by default. Shared service accounts, API keys that never expire, informal ownership with no clear accountable person, these are the norm across most enterprise deployments, not rare exceptions.

The EchoLeak attack, tracked as CVE-2025-32711, shows what that rudimentary governance actually costs. It targeted Microsoft 365 Copilot in a zero-click attack, and all it needed was for the victim to receive a specially crafted email. When the agent automatically processed that email during a later, unrelated query, it quietly sent emails, chat logs, OneDrive and SharePoint files, and Teams messages to an address the attacker controlled. No link was clicked. No attachment was opened. The agent did everything on its own, because that's what it was built to do.

The frameworks needed to catch this kind of failure exist now, even if most companies haven't applied them yet. The OWASP MCP Top 10, first published in 2025 and actively updated through 2026, now lists shadow MCP servers, token mismanagement, privilege escalation through scope creep, and context injection as their own distinct threat categories. The taxonomy is there. Most enterprises haven't mapped their own agent deployments against it yet.

Slack sharpens this problem in a specific way. Security teams used to worry that an employee might type sensitive information into a chatbot. Now they have to contend with AI systems that retrieve, process, and act on enterprise data entirely on their own. You now need controls that most security programs haven't built yet, because this is a different threat model.

None of this reflects carelessness on the part of enterprise security teams. The tooling needed to govern autonomous agents at this scale has only existed for a matter of months. Companies are running production workloads through a technology, and its own safety frameworks are still being written in real time.

What the July 2026 MCP specification changed about authentication

The MCP specification rewrite released on July 28, 2026, turned authentication from a loose convention into an actual defined architecture. It stopped short of solving the hardest problems enterprises face: how to establish identity for an autonomous agent, how to define its scope of access, and how to set authorization policy around it. These remain explicitly outside what the spec covers.

What it did fix matters. The new spec lines MCP authorization up with OAuth 2.0 and OpenID Connect, two standards most enterprise identity teams already know well. MCP servers must now implement OAuth 2.0 Protected Resource Metadata, defined in RFC 9728, so a client can automatically find the correct authorization server instead of guessing or hardcoding it. MCP clients, for their part, must now implement Resource Indicators from RFC 8707, so a client has to state explicitly which MCP server a given token is meant for. That single requirement closes a dangerous gap: a malicious server can no longer trick a client into handing over a token meant for a completely different resource.

Alongside the spec, Enterprise-Managed Authorization, stable as of June 18, 2026, gives organizations a way to centrally provision MCP server access through their own identity provider. Under EMA, a user gets connected to approved servers the first time they log in, so you don't need a separate OAuth flow for every single app. Anthropic, Microsoft, and Okta are all adopting it.

Authorization itself, though, is still optional under the spec. The document says that authorization server details are "beyond the scope of this specification," and it leaves scope values, what an agent is allowed to touch, entirely up to whoever builds the server. That's a meaningful gap.

EMA has the same limit built into its design. It solves access for employees logging into an approved client, but it does not, by itself, establish identity or trust for a workload acting on its own, without a human present to authenticate. So the lateral movement risk and the governance shortfalls already in place across most enterprises leave that gap open. The spec fixed how a token gets requested and where it's allowed to go. Who, or what, is actually making that request in the first place went unanswered.