Putting an AI to work in your team chat

The AI at work used to be a tab. You opened it, pasted something in, copied the answer out, and it forgot you by morning. The version now arriving in team chat is a different arrangement. It sits in the channel, reads what gets said there, keeps notes between conversations, and acts on the systems someone connected for it. Anthropic’s Claude Tag, in public beta on Team and Enterprise plans, is built exactly this way: you mention @Claude in a channel, and what it can reach “depends on the channel you’re in, not on who you are” [1].

That sentence is the whole design, and it is the part teams skip. A chat agent is not a subscription you hand to a person. It is a standing grant attached to a room, held by everyone in the room. This guide is for an owner or operator deciding whether to put one in a channel and how narrow to make it on the first day. It is not a setup walkthrough, and it is not for anyone on an individual plan, since Claude Tag is not available on Free, Pro or Max [1]. It is also no use to an organisation running Zero Data Retention, which cannot use the product at all, because it retains channel memory and session transcripts [2]. The examples here are Slack, because that is where these products currently live. The questions transfer to wherever your team talks.

The channel is the unit of access, not the person

Out of the box the agent is close to harmless. In channels Claude “acts under its own service accounts that an Owner provisions”, it can read and post in channels it has been added to, it can search public channels by keyword, and “it has no access to your external systems until an Owner adds connections” [2]. Installing the app adds it to nothing. Someone has to run /invite @Claude in a channel before it can respond there [6].

Access then arrives in bundles, which an Owner attaches at one of three levels: a single channel, a whole workspace, or the organisation-wide root covering every paired workspace [2]. Attach at the channel and the credential exists in that channel only. Attach at the workspace and every channel underneath inherits the same reach. The consequence is stated plainly in the documentation: “Anyone in a channel under that scope can ask Claude to act with the credential, so whatever the connected account can read or write is available to every member of those channels” [2].

Two defaults deserve a minute before the first task. Anyone in the connected Slack workspace can invoke Claude in channels, with or without a Claude account, until an Owner turns on the restriction toggle [2]. And a bundle attached to a public channel grants its access to anyone who joins that channel [2]. If a credential matters, the channel holding it is private, or the credential does not belong there.

For a first run, the narrow shape is a pilot confined to one channel. Turn the version setting off at the organisation root, reset the scopes that override it, then switch a single chosen channel back on, at which point Claude answers there and stays silent everywhere else [3]. Two boundaries are set for you. Claude is disabled by default in any channel that includes a Slack guest, and it does not operate in Slack Connect channels shared with another company, where the behaviour “isn’t configurable” [3]. Blocked channel patterns, up to 50 of them at 80 characters each, keep it out of channels by name even if someone invites it in [3].

Its own accounts, or you cannot tell what it did

The agent does not act as you. In channels it uses service credentials of its own rather than the account of the person who tagged it, and every connected tool beyond Slack and GitHub uses a service account an Owner provisions [2]. What you provision matters more than it looks. Anthropic’s own advice is to connect a dedicated identity for each service, such as a [email protected] seat or a native service account, rather than a personal login, because “a dedicated account keeps the agent’s actions separately auditable in each tool’s logs and lets you revoke its access without affecting a person” [2].

That is the practical audit story. The trail you will actually read when something looks wrong is the connected service’s own log, showing the agent’s actions under an account your team already watches [2]. Wire it to a personal login and you have merged the agent’s history with a colleague’s, permanently, in a system neither of you controls.

The credential handling underneath is worth knowing so you can stop worrying about the wrong thing. The sandbox that runs a thread holds no credentials; the network layer injects them at the boundary, so the model is never given the key, a saved credential is never displayed again, and it travels only to the hosts you named when you added the connection [2]. Outbound traffic from a channel session is default-deny, meaning requests reach only hosts an allow layer covers and everything else is blocked [2]. You can narrow a credential further, to one host, one path prefix, or read-only methods [2].

Use that last option first. It matches the OWASP guidance for this class of system, which lists enforcing privilege control, restricting the model’s access to minimum necessary levels, among its primary defences [7]. An agent that reads and summarises is a cheap two-week experiment. An agent that can write to your ticket tracker, push a branch or message a customer is a different risk class, and it should get there on purpose.

Anything in the channel reads as an instruction

This is the failure mode people do not anticipate, and the vendor documents it. Anthropic’s page for the Slack integration warns that when Claude is invoked, it is given the conversation context, and “Claude may follow directions from other messages in the context, so users should make sure to only use Claude in trusted Slack conversations” [6].

OWASP names the general case. A prompt injection vulnerability “occurs when user prompts alter the LLM’s behavior or output in unintended ways”, and the inputs “don’t need to be visible to humans” for the model to act on them [7]. The indirect version happens when the model accepts input from external sources such as websites or files [7]. A team channel is full of external sources wearing a colleague’s face: the pasted customer email, the ticket body, the contents of an uploaded PDF, the text inside a screenshot someone dropped in to ask about.

The mitigations that survive contact with a chat channel are the boring ones. Segregate external content and mark it as untrusted, enforce privilege control, and require human approval for high-risk operations [7]. In practice that means the channel where the agent has write access to real systems is not the channel where you paste things customers sent you. Keep intake and action apart, and the injection has nowhere to land.

Two controls you might reach for do not exist. There is no per-channel responder allowlist, so you cannot narrow invocation to five named people in one channel while leaving the rest of the workspace alone [3]. And there is no read-scope confinement: the agent can search public channels by keyword the same way any workspace member can, without being added to them, and there is no setting to disable workspace search [3]. Your private channels are not searched, but “private” is doing all the work in that sentence.

Memory belongs to the room, and the transcript outlives it

Memory is kept per channel, and memory generated in public channels is shared across the workspace automatically, so a decision recorded in one channel is available when you ask in another [4]. A private channel writes to its own store and reads workspace memory read-only [4]. Anyone in the channel can save, read and correct what it remembers, which is the same permission model as everything else here [4]. If a private channel is later made public, the memory it saved while private is no longer read by new sessions [4].

The security page states the trap in one line: “Isolating a credential doesn’t isolate what Claude knows” [2]. You can confine a finance credential to one private channel and still find that what the agent learned in a public channel is readable from every other channel in the workspace [2][4]. Ask it directly, in the channel, what it remembers, and read the answer honestly [4]. An Admin can view a scope’s memory files in admin settings, though only an Owner can edit or delete them [4].

Then there is the second copy, which is the part that surprises people. Anthropic keeps a session transcript for each thread, holding the messages Claude was shown and who sent them, files attached there, earlier versions of messages that were later edited, and what it retrieved while working [5]. Deleting or editing a message in Slack does not remove it from a transcript that already includes it [5]. During the beta there is no automatic retention period, and an organisation’s custom data retention setting does not apply to Claude Tag transcripts or memory [5]. There is also no control that deletes a single thread’s transcript on its own; the smallest lever is removing the channel’s scope, which deletes that channel’s sessions, transcripts, memory, routines and published artifacts [5].

Published artifacts have their own rule worth knowing before someone generates one. A page a session publishes stays available after the work ends, and anyone with access to the source channel can open it, which in a public channel means everyone in the workspace [2].

Standing work inherits the channel’s permissions

The interesting capability is the one that runs without you. Any member of a channel can create, list or disable a scheduled job there, and those jobs run with the channel’s credentials, so a member setting one up “can’t reach anything the channel itself can’t” [3]. That is a well-designed boundary and also a plain statement of who is now driving. The scheduling question and the permission question are the same question, answered once, when you decided what the channel could touch.

Money works the same way. Adding the agent to Slack does not add a per-seat charge; channel and thread work bills by usage against a balance an Owner funds, and a spend limit caps how much of that balance it can draw each billing period [1]. Direct messages are the exception, running on the sender’s own account under that seat’s usual limits [1]. You can set an organisation-wide limit, a default per-channel limit, and limits on individual channels, and work that would exceed a limit “is declined rather than silently truncated” [3]. What you cannot do is cap one person: there are no per-user spend caps on channel work [3].

Set the limits before the first task, not after the first invoice. A pilot with a spend limit and the per-channel breakdown on the usage page is how you find out what your team’s usage actually costs [1].

What it costs, in the two shapes the cost takes

The bill has two shapes and most teams end up paying both. The first is per-seat AI inside the chat tool itself. Slack’s Free plan is $0, Pro is $8.75 per user per month paying monthly or $7.25 paying annually, and Business+ is $18 per user per month monthly or $15 annually, with Business+ the tier that carries the advanced AI features including Slackbot as a personal AI agent; Enterprise+ is quoted by sales [8]. That cost scales with headcount whether or not anyone uses the feature.

The second shape is the usage-billed agent you invite in on top. No per-seat charge, a funded balance, and a ceiling you choose [1]. That cost scales with work, which is better aligned to value and much harder to predict, which is exactly why the cap exists.

The honest planning number is not a forecast, it is a ceiling: seats times the per-seat price, plus the cap you set. If that number is one you could absorb in a bad month, the pilot is safe to run. If it is not, lower the cap rather than promising yourself you will watch the dashboard.

What still goes wrong

The product is in public beta, and the documentation says features and behaviour may change before general availability [2]. Every control, default and price above was read from the vendor’s own pages on 5 September 2026, and the ones that move fastest are the retention rules and the list of controls that do not exist yet. Re-read them before you widen anything.

The gaps are real and worth naming. You cannot cap one person’s spend on channel work, you cannot restrict who may invoke the agent in a single channel, and there is no switch that turns off web search for channel sessions [3]. So the sentence “only these three people, only in this channel, with a hard budget each” is not currently expressible. What you can express is a narrow channel with narrow credentials and a cap, which is close enough if you also keep the channel small.

The quieter problem is not technical. Shared identity makes the work visible, which is genuinely useful, and it makes mistakes visible in the same way, with no second reviewer built in anywhere. A colleague pastes a customer’s email into the channel to ask a question, and it is now in a transcript you cannot delete thread by thread [5]. Nothing in the setup stops that, and no policy document will either. The only thing that works is picking a channel where you would be comfortable if everything in it were kept, and widening from there slowly, on evidence, after you have watched it behave.