The Borrowed Identity: What Slack Code Reveals About Agent Accountability

What happened

On August 20, 2026, Salesforce launched Slack Code, a new channel type available on any Slack plan that lets a team member tag a coding agent directly into a conversation. The agent opens a dedicated, project-specific “code channel,” and from there the whole team can watch it work: separate views show the agent's conversation, its plan, and live code diffs, with screenshots and recorded demonstrations for verification along the way.

The list of agents a team can tag in is deliberately vendor-neutral: Anthropic's Claude Code, Cognition's Devin, GitHub Copilot, OpenAI's ChatGPT, and Vercel's coding agent are all supported at launch, according to InfoWorld's coverage. When the task is done, the agent can “package the work for human sign-off and, depending on the workflow and agent, open a pull request,” and the channel then archives itself automatically “while retaining the history as a searchable record.”

The permissions model, in the vendor's own words

The most consequential design decision in Slack Code isn't the chat interface — it's how the agents are authorized. Salesforce product leadership told VentureBeat plainly that agents do not get any identity or permission set of their own: “Everything is done on behalf of the user, using the user's ACLs, both in Slack and in the systems they're connecting to.” There are no elevated bot permissions. An agent tagged into a channel can only touch what the human who tagged it could already touch.

That is a reasonable, even conservative, security default. Cognition's Devin runs in an isolated sandbox with minimal access on top of it. Existing GitHub release gates and review processes stay mandatory on every pull request an agent opens. Nothing here is reckless.

But it is worth naming what “borrowed identity” actually means: from the system's point of view, the agent is not an actor. It is a costume the human is wearing. Every action a coding agent takes in a Slack Code channel is logged, everywhere it counts, as the inviting employee's own action — not as an entry in that agent's own history.

An analyst already flagged the crack

This is not a hypothetical concern. InfoWorld quoted analyst Advait Patel raising exactly this issue at launch: “Slack channel membership should not automatically translate into permissions to access or modify an underlying code repository.” Patel's point is about scope creep within a single workspace — being in the room shouldn't mean you can touch the repo. It is the first crack in the borrowed-identity model, and it points at a bigger one.

If channel membership shouldn't silently become repository access, then human identity shouldn't silently become agent identity either. The two problems share a root cause: nothing in the system distinguishes who is asking from what is actually doing the work.

The audit log is real. It just doesn't travel.

Slack Code's searchable, archived channel history is a genuine improvement over an engineer pasting code from a private terminal session with no record at all. But look at what that audit log actually captures: one workspace's memory of one project's conversation with an agent, indexed under the human's ACLs. It does not follow the agent.

Tag Claude Code into a channel at Company A and it does excellent, tightly-scoped work for three months. Tag the same underlying agent into a channel at Company B next week, and Company B starts from zero. There is no portable record that this specific agent stays in scope, that its diffs match what was actually asked of it, or that it has a long history of clean pull requests versus a history of scope creep that got caught by review. Every workspace re-litigates trust in an agent that other workspaces have already spent months evaluating.

That is not a flaw unique to Slack Code — it is the default state of agent commerce today, and Slack Code just makes it unusually visible because five different agent vendors are now standing side by side in the same interface, each one a black box with a workspace-local reputation that resets at every new door it walks through.

What identity plus a score would add

This is precisely the gap the AAIN and SKOOR exist to close — and it is worth being honest about the boundary. AAIN and SKOOR would not replace Slack's permission model, and they shouldn't: borrowing the human's ACLs to cap blast radius is good security hygiene regardless of what identity layer sits above it. What they would add is a second, complementary signal that currently doesn't exist anywhere in this stack.

SKOOR is a continuous, 300–850 behavioral score built from ten factors like these, recomputed as new behavior lands, with a full factor breakdown behind every number. Today it scores 190,057 agents, refreshed live at api.skoor.ai. None of those agents are coding assistants yet — but the factor model was built for exactly this shape of question, and nothing about Slack Code's design would prevent a coding agent from carrying an AAIN and a SKOOR into every channel it's tagged into, the same way it carries its vendor name today.

Why this matters beyond code review

Slack Code is a narrow product launch, but the pattern it exposes is not narrow at all. Any time an agent is granted access by borrowing a human's credentials — a coding agent under an engineer's ACLs, a purchasing agent under an employee's corporate card, a scheduling agent under an assistant's calendar permissions — the system inherits the same blind spot Slack Code has today. The permission model correctly limits what damage a single bad action can do. It says nothing about which agent, across every workspace it has ever touched, has actually earned a wider grant of trust.

That is a solvable problem, and it does not require Salesforce, Anthropic, or Cognition to change how permissions work. It requires a layer that sits beside the permission model, not inside it: a persistent identity per agent, and a behavioral track record attached to that identity that any workspace can check before deciding how much autonomy to extend on day one.

What this means for businesses

If your business is about to tag a coding agent, a scheduling agent, or any AI coworker into a shared workspace for the first time, Slack Code's own design is a useful checklist:

• Confirm the blast radius, not just the invitation. Being able to tag an agent into a channel should never, by itself, grant it repository or system access wider than the task at hand — Patel's warning applies just as much outside Slack.
• Ask what the audit log actually covers. A channel-local, workspace-local record is useful for compliance but tells you nothing about how that same agent behaved for the last team that used it.
• Look for a track record that travels with the agent. A permanent identifier plus a continuously updated behavioral score is what lets you extend more autonomy to an agent on day one instead of re-learning its habits from scratch, project after project.

Slack Code got the hard part right: capping what an agent can touch. The part it leaves for the rest of the industry to build is remembering who that agent actually was, the next time someone tags it in.