Slack Put Coding Agents in Group Chat. The Agent Runs at the Tagger's Access, Not the Asker's.
Slack Code shipped on 20 August. Mention Claude Code, Devin, GitHub Copilot or Vercel's agent in a project channel and Slack spins up a dedicated code channel around that task, where the whole team watches the diffs, checks a live preview, and approves the work in place. It archives itself when the work lands and stays searchable. It is on every Slack plan at no extra cost.
The design decision underneath it is the interesting part. The agent acts as an extension of the person who mentioned it, using that person's access controls in Slack and in every system it touches. Salesforce's Rob Seaman put it plainly: there are no god permissions or bot-level permissions.
That is the right call, and it has a consequence nobody put in the launch post. In a channel with a dozen people, the person who wants the change and the account that makes it are no longer the same person.
What actually shipped
Slack Code turns a chat channel into the workspace for a coding task. You are in a project channel, someone describes a bug, you tag an agent, and a code channel appears scoped to that one job. Everyone in it sees the agent's reasoning, its file changes, and a running preview. Non-engineers are explicitly part of the audience. Product managers and designers are meant to be in there watching and steering.
Five partners at launch: Anthropic, Cognition, GitHub, OpenAI and Vercel. You need your own subscription to whichever agent you use. Slack is not reselling the models, it is providing the room.
The output is a normal pull request. That matters, and it is underplayed in the marketing. Seaman told VentureBeat that the due diligence still happens in GitHub. Your branch protections, required checks and CODEOWNERS rules are untouched, because Slack Code is upstream of all of them. It changes where the work gets specified and watched, not where it gets merged.
Which makes the launch page's own framing of approval the thing to read twice.
Two stories about where the gate is
Slack's blog says high-stakes changes can route to a person for a fast approval, right in the channel, described as the speed of automation without giving up the confidence of a review.
Salesforce's product lead says the due diligence still happens in GitHub.
Those are two different gates and only one of them enforces anything. The in-channel approval is an intent check, useful and fast, sitting before a PR exists. The GitHub review is the merge gate with teeth. Read the launch page in a hurry and it is easy to come away thinking the thumbs-up in the channel was the review, especially when the channel is full of people who cannot read a diff and have just been told they are part of the process.
Both gates are fine. Confusing one for the other is how a team ends up with a well-documented conversation attached to code nobody qualified actually read.
The permission question is the whole product
Will McKeon-White at Forrester called permissions a persistent challenge for anything multiplayer, and listed the three ways vendors handle it: inherit permissions per task, keep persistent agent permissions with a separate invoking permission, or inherit the permissions of the room. Each one breaks somewhere.
Slack picked the first. The agent borrows the invoker's identity for the duration of the task. Compared to a service account with broad repo write access, this is a clear improvement. A bot identity that can touch every repo is a standing risk that gets forgotten in an admin console for two years. Borrowed credentials expire with the task.
The failure mode it introduces is quieter. Blast radius is now set by whoever typed the at-sign, and intent is set by whoever was talking. A support lead describes a data problem in a channel. A staff engineer with production database access tags the agent to look at it. The agent now works on the support lead's request at the staff engineer's access level. Nothing was escalated and no policy was broken. The two halves of an action that a normal review process keeps attached to one accountable person just came apart, in a room where seven other people can also type instructions into the agent's context.
Public channels make this worse in an ordinary way. Slack Connect guests, contractors, and integration bots post into channels all the time. Anything written in a code channel is input to a running coding agent. That is not a novel exploit, it is the same lesson from every agent incident this year, arriving through a door your organization already left open for good reasons.
The line in the launch post to ignore
Slack says Slack Code inherits Slack's existing permissions and admin controls, so IT does not need to configure or audit anything new.
Slack also shipped a control letting admins prevent non-technical workers from shipping code without engineering review.
Both statements are in the launch material and they cannot both be the operative advice. If a guardrail exists specifically to stop the thing you would not want happening, then there is something to configure, and the default is not it. The first sentence is a procurement argument. The second is the runbook.
What to do before you turn it on
Four things, and none of them take long.
Set the admin guardrail that requires engineering review before code ships. Do it on day one, not after the first incident, because the whole pitch of the feature is that non-engineers are now in the room.
Decide who is allowed to invoke an agent, and say it out loud. Not who is allowed in the channel, who is allowed to tag. Under a borrowed-identity model, that list is your real permission boundary, and right now it is implicit.
Keep the merge gate in GitHub and tell people that is where it lives. The channel approval is a check on intent, which is genuinely the more valuable of the two for catching the wrong job early. It is not a substitute for someone reading the diff.
Treat the code channel as untrusted input. Anyone who can post in it can steer the agent. If the channel is public or has Connect guests, that is your threat model, and it is a policy problem rather than a technical one.
The part I think they got right
Strip away the framing and Slack Code is a bet that the bottleneck in agent-assisted development is not code generation, it is everyone else finding out what happened. That bet looks correct. Most of the friction I see on teams running coding agents is not the agent writing bad code, it is a pull request appearing with no visible trail of what was asked, what was tried, and what was rejected along the way. An archived channel holding the full conversation next to the diff is a better artifact than a commit message written by a model.
The specification and the watching move into a room where the whole team already lives. The verification stays in GitHub, where it can actually block something.
Two jobs, two places. Just be deliberate about which one you think the thumbs-up in the channel was.