Claude Tag admin guide

Claude Tag (public beta) is Claude working in your team's Slack channels, with its own accounts in your tools. People tag Claude the way they'd tag a colleague, and Claude Tag picks up the work and follows through in the thread. Hand it standing work and it runs on its own: a Monday-morning routine posts its report before anyone opens Slack. Out of the box, anyone on your team can tag Claude, and Claude Tag answers using your team's connected tools, from Google Drive to BigQuery to GitHub. By the end of this guide you'll have paired the workspace, decided who can use Claude Tag, connected its tools, capped its spending, and planned the rollout.

1. Before you start

You will need:

• A Team or Enterprise plan: individual plans and third-party deployments don't qualify (the prerequisites cover what to do if you don't have one).
• An Owner (or Primary Owner) in the Claude organization that will hold the pairing: pairing is Owner-only, and so are access bundles unless you're on Enterprise, where a Claude Tag admin (a member whose custom role has the Claude Tag Admin permission) can manage them and a channel manager can create one for their assigned channel (section 4). Owner status in another Claude organization does not apply.
• A Slack workspace admin: installs the app and generates the pairing code. On Enterprise Grid, a Grid org admin also qualifies. The code is single-use and expires 15 minutes after generation, so coordinate to be online at the same time. This person can be the same as the Owner.
• A funded usage balance: on a Team plan, Claude Tag won't answer in channels until your organization's usage balance is funded. How channel work bills, and the card-billed vs. invoiced difference, is in Set a spend limit.
• An IP allowlist entry, filed early: if a connected service restricts by source IP, add Anthropic's published egress range now; enterprise allowlist changes can take days, and every connected service must be reachable from the internet (network requirements has the range).
• A Claude organization without Zero Data Retention (ZDR), customer-managed encryption keys (CMEK), or Anthropic's HIPAA configuration for Claude Code and Cowork in local mode: none of these permits Claude Tag. If other Claude products need them, ask your account team about a separate Claude organization to hold the Slack pairing.
• Routines enabled for your Claude organization (Admin settings › Capabilities): Claude Tag requires the feature. Until an admin enables it, every mention and direct message (DM) gets an "unavailable" reply and no work happens.
• One Claude organization to hold the pairing: a Slack workspace (or Enterprise Grid) pairs with one Claude organization at a time. If your company has multiple organizations, determine which one holds the pairing before you connect.

The six decisions you own

1. Where Claude Tag lives: the paired workspace and which channels it works in (sections 3–4).
2. Who steers it: Owners hold the admin controls (on Enterprise, they can share most of them through a custom role); channel members shape their own channel from within it (sections 4–5).
3. What it can touch: repositories, credentials, connections, and plugins, organized into access bundles and scoped to different levels (section 4).
4. How it behaves: ambient or mention-only, controlled by a switch on each channel's Configure page, plus written instructions (section 5).
5. What it remembers: channel and workspace memory that you can open, edit, and delete (section 5).
6. What it costs: a monthly ceiling for the organization and a limit per channel (section 6).

When a question about Claude Tag comes up later, start by working out which of the six it touches.

2. The map: five surfaces, three scopes

Claude Tag's settings are spread across several pages in claude.ai and Slack, each controlling a different type of configuration.

Channel memory and individual routines aren't created on a settings page: you shape both by talking to Claude Tag in the channel. An Owner can review both (memory files from the scope's menu, section 5; routines from the Activity page's Scheduled work tab, section 7), and the org-level Routines feature itself is switched on by an admin (see Before you start). The settings map is the one-page reference.

Access is granted in scopes, and scopes inherit downward

Access is packaged into access bundles: named sets of connections, repository grants, domains, plugins, and instructions. Bundles attach to scopes. There are three scopes:

1. Default Slack access: the organization-wide root that every channel gets.
2. A workspace: everything Claude Tag does in that paired workspace.
3. A single channel: just that one room.

Scopes stack downward, so a channel sees the union of everything above it plus its own:

1. Narrower scopes only ever add: detaching a channel's bundle removes only that channel's additions; the workspace and default bundles still apply there.
2. Same host, two credentials, the narrowest scope supplies the credential: channel beats workspace beats default, with no fallback. If the winning credential returns a 401 or 403, Claude Tag does not quietly retry with the next one.
3. Custom instructions concatenate top-down: default first, then workspace, then channel. A channel's instructions add to what's set above it.
4. A thread keeps what it started with: a running thread keeps the skills, plugins, and custom instructions it began with, while connections and domain rules apply on every request, so a connection added mid-thread works if you name the service. After any configuration change, test from a new top-level thread.

3. Get live: the setup flow, screen by screen

Aside from two moments in Slack itself (installing the app and sending the connect message) and the accounts you create in your own tools (steps 3–4), every setup step runs on one page: claude.ai's Admin settings › Products › Claude Tag (claude.ai/admin-settings). Every step saves as you go, so you can leave and come back later.

Step 1. Pair your Slack workspace

Pairing takes one code. It links your Claude organization to Slack, and Claude Tag joins the workspace like a new member with its own profile.

1. Add the Claude app to Slack from the Slack Marketplace. A Slack workspace admin does this.
2. Invite Claude and send @Claude connect: in a channel with no guests that belongs only to this workspace, run /invite @Claude (Claude posts a short welcome), then send @Claude connect as a new message with no other text. Claude Tag can decline to reply in guest channels, and Slack Connect channels don't work at all. Claude replies with a one-time pairing code that only you can see.
3. Paste the pairing code into the Paste the pairing code field on this screen; Connected to and your workspace name appear when it's accepted.
4. Choose where Claude can reply when tagged, between Entire workspace and Specific channel. Entire workspace is the recommended default. (If the screen doesn't ask, Claude Tag replies across the whole workspace once you launch.)
5. Click Pair workspace.

Entire workspace or Specific channel

Both set a switch you can hand back to Inherit later (section 4; a Team plan has a single switch for all workspaces instead). Neither choice automatically adds Claude Tag to any channel: members bring it in one channel at a time, and it joins on its own only where an admin has set an auto-join channel-name rule (section 4). How members add it, and how those joins appear in Slack's audit log, is covered in What the Claude Slack app can access.

The console shown is an illustration of a fictional company; all names and numbers are invented.

What access pairing grants

Pairing grants Claude Tag no one's existing access. It takes nothing from:

• The Slack admin who installs the app
• The Owner who redeems the code
• Any workspace member's connected tools

It creates a new participant in Slack, tied to your Claude organization, and that participant has no access to your external systems until an Owner (or, on Enterprise, a Claude Tag admin or a channel manager) adds connections. A member's own connectors are separate: they can serve that member's own requests once the member allows it (see Connections and connectors, in Step 2).

Pairing on Enterprise Grid

On Slack Enterprise Grid, the @Claude connect reply carries two codes: workspace_… pairs one workspace, and enterprise_… pairs the whole grid. One-to-one DMs work only for people whose home workspace is paired, so pair the grid if they should work for everyone. The pairing steps in the setup docs cover both codes and have the complete walkthrough.

Step 2. Choose Claude Tag's first tools

In the tools you set up here, Claude Tag works with its own account, so it acts as itself, not as you. Pick at least two tools your team actually works in to start (Search all tools finds ones not shown; GitHub has its own step next).

Connections and connectors

A connection is Claude Tag's; a connector is yours. The tools you connect in this setup flow become connections: Claude Tag's own sign-ins, shared by the workspace or a channel, recording every action under Claude Tag's name for audit and revocation. A connector is a tool on your own claude.ai account, under Customize › Connectors: private to you, and used in your one-to-one direct messages with Claude Tag.

Claude Tag can also offer to use your connectors for a task you asked for in a channel or group DM, after you allow it, and never for anyone else's request. The boundary otherwise runs both ways: your connectors don't do the channel's shared work, and a channel's connections don't follow anyone into a DM.

Step 3. Connect GitHub, then choose repositories

If your GitHub organization doesn't yet have the Claude GitHub App, the GitHub owner installs it here; the setup docs cover the three states this screen can show, including an app installed on a personal GitHub account (Claude Tag needs it on a GitHub organization).

Choose repositories

Once the app is installed, you land on the repository picker: one row per GitHub organization, with options to connect all or pick specific ones. These grants attach to the workspace you just paired and apply to every channel Claude Tag works in there; on an Enterprise Grid organization-wide pairing they apply across the whole organization instead.

Treat the picker's grants as a floor: a bundle bound to a workspace or channel adds repositories on top, and narrower scopes only ever add. The real ceiling is upstream of any bundle, in the Claude GitHub App installation's repository selection on github.com.

You can skip this step and grant repositories from the admin page later. See granting repository access.

Step 4. Create accounts for Claude Tag's other tools

Claude Tag needs its own account in a tool before it can do the channel's shared work there, so a skipped tool stays out of that work until you add it. A member's own connector to that tool can still serve their requests once they allow it. The account is usually an email address Claude Tag can be invited with; some tools that do not support email accounts offer service accounts instead, which serve the same purpose.

Create the account and paste its keys

The screen shows three rows (create the email address, invite Claude Tag to each tool, connect each tool with its credentials); the work behind them is four sub-steps:

1. Create an email address for Claude Tag.
2. Invite it to each tool the way you'd invite a new hire (scoped to only what it needs).
3. Create an API key as Claude Tag in each tool.
4. Paste each key here.

The setup docs detail each sub-step; work one tool end to end before starting the next.

The console shown is an illustration of a fictional company; all names and numbers are invented.

Limit what each account can reach

For the recommended account pattern per service type, and how to limit each account to only the folders, projects, or spaces Claude Tag should reach, see creating a dedicated account per service; the per-service connection guides have the exact credential fields and allowed-website values per tool.

Step 5. Buy usage credits

Claude Tag runs on usage credits: its channel messages and tool actions draw from your organization's usage balance.

Load the credits on this setup screen:

1. Type an amount ($5 or more).
2. Confirm the total.
3. Buy now charges your saved card.

You can skip and fund later from the Usage page, but Claude Tag stays silent in channels until the balance is funded. See Set a spend limit.

Step 6. Launch Claude Tag

One decision every organization sees at launch: the Let members know they can now tag Claude toggle, which has Claude Tag DM each member to say it's available. Those messages do not count toward billing. The toggle is on by default; turn it off until your pilot channel is running well and you want wider adoption.

Then press Launch Claude Tag.

4. Access and identity

After launch, come back to the Claude Tag page (claude.ai's Admin settings › Products › Claude Tag). It's your control room:

• The enable switch for the organization
• The Allow direct messages switch under it
• The included-usage meter if you started on a promotion
• Two sections below them: Where Claude Tag works, one row per surface, and Claude Tag's access

One toggle decides who may use Claude Tag

Under Where Claude Tag works, click Manage next to Member access and set the restriction toggle: Restrict to your organization on a Team plan, Restrict to roles with Claude Tag access on Enterprise. The toggle decides who in the paired workspace can use Claude Tag, and it applies to channels and direct messages alike:

• Off (the default): anyone in the workspace can use Claude Tag in channels, whether or not they have a Claude account. Someone who hasn't connected a Claude account, other than a Slack guest, can also DM Claude Tag one-to-one for a limited time on your organization's bill (section 6); after that, Claude Tag asks them to connect one, and their one-to-one DMs then run on that account (the identity model below). In a group DM they can ask without connecting one, and the per-person limits in section 6 don't apply.
• On: only Slack users with a Claude account in your organization can.

On Enterprise, every built-in role already grants the Claude Tag in Slack capability, so in an organization with no custom roles, turning it on simply limits Claude Tag to your organization's members. To narrow further, create a custom role that grants or withholds the capability; see restrict by role on Enterprise.

If your organization sits under a parent enterprise organization, the Member access dialog also offers Restrict to your verified domains. The dialog lists the connected workspaces as well, each with a Disconnect. Disconnecting deletes that workspace's Claude Tag data after a short grace period (your access bundles stay), so read disconnect a workspace before you use it. See restricting who can use Claude Tag.

Three settings that are easy to mix up

Scope switches and Inherit

Turning a scope's switch off stops Claude Tag there; a workspace or channel with its own On setting stays on even when the scope above it is off. That includes a workspace you launched with Entire workspace, or each channel you chose in a Specific channel launch: the Launch step sets that scope's switch to On for you.

To make a scope follow the one above it again, set its Claude Tag version under Advanced back to Inherit, or use the inherited-setting link beside its switch (an "Inherited: On" or "Inherited: Off" byline there shows what the scope above passes down until you set the switch yourself).

On the Team plan you instead see a single Respond in channels switch on the Slack page (Enable Claude Tag on Default Slack on the earlier admin page) and no per-scope switches; it turns Claude Tag on or off in the channels of every connected workspace at once.

Guests and Slack Connect

Two checks run before a scope's enable switch is consulted. Claude Tag is off in any channel that includes a Slack guest unless the scope's How should Claude work in channels with guests is set to Channel only or Full access. Under Channel only and Full access alike, guests can read what Claude Tag posts there. Under Channel only, treat the channel's own instructions, and those in any bundle attached directly to it, as visible to them; under Full access, treat everything the scope inherits as visible too.

Claude Tag doesn't work in Slack Connect channels, the channels your workspace shares with another company, and no admin setting turns it on there; see Slack Connect channels in the docs for what a mention gets and what happens when a channel Claude Tag works in becomes one.

Grid-shared channels

Claude Tag answers in a channel shared across your Enterprise Grid's workspaces only when every one of them is paired to your Claude organization, and even then with just your Default Slack access scope (workspace and channel bundles, instructions, and memory don't reach it). See grid-shared channels for the guest check, the refusal cases, and why there is no per-channel override.

The Legacy version

Legacy is the earlier Claude in Slack; skip this if your organization never used it. Since October 5, 2026, Legacy no longer answers in the channels of a paired workspace, and you can't switch a scope to it. One-to-one direct messages aren't affected, but Claude Tag doesn't answer group DMs in a workspace still set to Legacy.

A channel still set to Legacy, directly or by inheriting it, answers a mention only with a notice that the legacy bot is retired. To bring Claude Tag back there, set Claude Tag version to New on the channel, or on the scope it inherits from: its workspace, or the Slack page (Default Slack access on the earlier admin page). See migrating from the earlier Claude in Slack.

The access editor: pick a scope, read its access

Under Claude Tag's access, the Slack tab is a two-pane editor.

The left rail: your scopes

• Default Slack: at the top is Default Slack access, the organization-wide root. Each paired workspace sits under it with its channels underneath.
• Channels appear automatically: whenever Claude Tag is added to a channel in Slack, that channel shows up here as a scope under its workspace, with nothing to create on this page. The Search channels field finds one by channel name or ID.
• Add the rest yourself: a channel that isn't listed yet gets a scope with Add channel; attach to a channel covers finding channel IDs and the private-channel caveat.

The right pane: the selected scope

• Connectors: every connector Claude can use in this scope, the scope's own and the inherited ones in one list, with a + for attaching a single connector without opening a bundle. Despite the name, this section deals in Claude Tag's own connections, not anyone's personal connectors (section 3's boundary).
• Repositories: every repository Claude can reach in this scope, own and inherited in one list, with the same + for granting a single repository.
• Plugins: the org plugins Claude loads in this scope, own and inherited in one list, with the same +; the section appears once your organization has installed plugins.
• Custom instructions: the scope's standing guidance, in plain text.
• Access bundles: the bundles attached to this scope, each with a remove, plus a + to attach another. What a bundle from a parent scope grants shows up in the lists above; to change it, edit the scope it comes from.

Each row carries an origin line naming the scope or bundle it came from; select the name in it to open that scope or bundle (the docs explain where each item comes from under check or remove what a place has).

Reading a scope's lists

A scope's lists are the resolved answer: every connector and repository this channel ends up with after the channel's bundles, the workspace's, and the root's are unioned together, each row labeled with where it came from. When someone asks "Can Claude reach Datadog from this channel?", open the scope and read its Connectors and Repositories lists instead of reasoning about inheritance. They cover the channel's shared work; a member's own connectors aren't listed there.

Which credential acts on a host is rule-governed: Claude Tag uses the narrowest scope's credential, with no fallback to a broader one. Keep the map just as legible within a scope by binding one credential per host per scope; then the Connectors list reads one-to-one, for you and for any security review.

The console shown is an illustration of a fictional company; all names and numbers are invented.

The rest of a scope's settings live under Advanced

The scope's Advanced section holds Claude Tag version: New, plus Inherit on workspaces and channels (a scope can no longer be switched to Legacy; see The Legacy version, above). The other Advanced settings:

• Default model: the model new sessions start on, drawn from the models your organization allows for Claude Code. A scope without its own setting inherits its parent's.
• Auto mode allow rules: plain-sentence rules that pre-approve actions Claude Tag's permission checker would otherwise flag or stop. Rules inherit downward, so keep each one narrow (auto mode allow rules has the form and an example).
• Environment: the cloud environment the scope's sessions run in, which sets their network access level (see Credentials never reach the sandbox, below).
• Channel name rules: two pattern lists on the root and workspace scopes: blocked channel patterns keep Claude Tag out of channels whose names match, and auto-join channel patterns add it to new public ones.
• How should Claude work in channels with guests: three values. Restrict, the default, means Claude Tag doesn't reply wherever a guest is present; Channel only lets it answer with only what's set directly on the channel (its own instructions and connections, plus a bundle attached to it whose attachment includes channels with guests; members-only is the default), with nothing inherited from the workspace or the organization, no memory or skills, and the standard environment in place of the scope's own (how Channel only works has the full exclusion list); Full access lets Claude Tag use everything the scope gives it. Even on Full access, workspace search is unavailable while a guest is present, and Channel only takes effect only on scopes set to New.
• Channel member edits: whether channel members can edit this channel's settings from the Configure link in Slack. Block at the workspace or root makes the whole Configure page read-only for members across every channel beneath it (section 5 has the details). A channel manager (on Enterprise, someone an Owner or a Claude Tag admin has delegated that channel's setup to) can still edit the channel's instructions and default model regardless of this setting.
• Respond automatically (a per-channel setting; workspaces and the organization have no such switch): on by default; turn it off and Claude Tag replies in that channel only when mentioned. Channel members can also flip this by asking Claude Tag in Slack.

The rows carry an Inherit option that shows what a scope currently resolves to. That is the place to look when one channel behaves differently from its siblings. See which settings admins control.

Inside a bundle, and who can edit what

Click a bundle to open it. The bundle editor has five tabs:

1. Credentials: Claude Tag's own account in each app. Connect a preset, or use Custom tool for anything with an API; a credential's Edit can narrow what it may do by HTTP method and path (add a connection).
2. Repositories: the GitHub grants for this bundle.
3. Domains: hosts allowed through with no credential attached, and, where your organization has it, a Blocked domains list: blocked entries are checked ahead of this bundle's allowed domains. A domain entry needs only the host, plus a port when the service isn't on 443.
4. Plugins: your organization's plugins toggled on for this bundle.
5. Instructions: text that rides along wherever the bundle is bound.

Each bundle shows how many scopes use it. Check that count before you edit a shared bundle.

Who can do what

The built-in Admin role in your Claude organization can't do any of these:

• Pair a workspace
• Manage access bundles
• Open the Activity page or memory files

Those need an Owner (on Enterprise, a Claude Tag admin can also manage access bundles; see below). Spend limits are the exception: an Owner or Admin can set those on the Usage page. On Enterprise, an Owner can delegate in two ways: a Claude Tag admin can administer most of Claude Tag, and a channel manager takes on the setup of the channels assigned to them (both below). Delegate Claude Tag administration has the steps for giving a member the Claude Tag Admin permission, including the permissions to add for someone who is an Admin today, because changing their role to Custom takes them off the built-in Admin role.

Even on Enterprise, these stay Owner-only: the switch at the top of the Claude Tag page that turns Claude Tag on or off for the whole organization, Allow direct messages, the member-access restriction, pairing or disconnecting workspaces, channel name rules and the bundles on them, Channels Claude can search, and Full access or Inherit for guests.

The full table is in the docs; see permissions by role.

The identity model: Claude Tag acts as itself by default

In a channel, Claude Tag acts with its own service accounts:

Claude Tag doesn't use the requester's own access for a channel's shared work. Two things follow: every action taken through the channel's connections is attributable to Claude Tag, which makes audit clean; and least privilege becomes a decision you make when you connect each tool. Three points to carry into that decision:

• Its own accounts: the channel's own connections give everyone in it the same capability, so the shared work doesn't change based on who asked. (A member's own connectors can additionally serve that member's own task, with their approval.)
• Grant read broadly, write narrowly: read-only connections across the tools your teams work in are a sound day-one default. Add write access per team's bundle, only where you want Claude Tag changing things, and revisit as it earns trust.
• Keep a human as the approver: pull requests Claude Tag opens are authored by the Claude GitHub App, so required-review branch protection still demands a human approval. But it no longer keeps the asker from approving their own request, because GitHub blocks only the PR's author (under Legacy, the asker was the author). To make sure a second person reviews Claude Tag's work, require two approving reviews in the branch protection rule, and dismiss stale approvals on new commits.

Direct messages are the exception. A one-to-one DM has no channel to scope it to, so for someone who has connected a Claude account it runs on that account, with their personal connectors, billed to their seat, and attributed to them, except for pull requests: the Claude GitHub App authors those from DMs too, though it can only reach repositories connected on that user's own account. Someone who hasn't connected a Claude account, other than a Slack guest, can also DM Claude Tag one-to-one for a limited time, on your organization's bill (section 6). That DM runs as Claude Tag itself, with the access bundles a channel they created in that workspace would get and no personal connectors. A group DM, a Slack conversation among several people that includes Claude, works like a channel instead: Claude Tag uses its own service accounts with the workspace's and the organization's access (not any one channel's), and the work bills to your organization.

Channels and group DMs are the shared, service-identity surface and one-to-one DMs are personal, with two exceptions. When a member's own connectors serve their request in a channel or group DM, that work runs with their permissions and under their name. And a one-to-one DM from someone who hasn't connected a Claude account runs as Claude Tag. See how agent identity works.

Credentials never reach the sandbox

Each channel task runs in an isolated sandbox, one per thread, and that sandbox holds no keys. In an Anthropic-hosted environment, when the work needs an outside system the request crosses Agent Proxy, the network boundary, which checks it against your rules and attaches the matching credential there. The model and the sandbox are not handed the key.

A request that matches no connection rule, no Domains entry, and no environment setting is blocked, and only HTTP and HTTPS cross at all. See security and data handling.

What Claude Tag can reach: the environment layer starts at the Trusted access network level, a documented set of package registries and developer hosts. For broader access, create an organization-shared environment from the Cloud environments page in Admin settings with a more permissive level (Full access allows any domain) and pin it on the scope. Do not create it at claude.ai/code, where environments belong to your individual account and never appear in the picker.

Allow-all egress, a * entry on a bundle's Domains tab, is off by default and enabled per organization by Anthropic; see allowing a host without a credential.

Web search runs on Anthropic's servers, outside all these layers; web search vs. network requests explains why Claude Tag can quote a page it can't open.

For companies that handle PHI

If anyone in your Slack workspace handles protected health information (PHI), configure Claude Tag so that it cannot read, search, or connect to places that might include PHI. Claude Tag is in public beta and is not a HIPAA-eligible service under Anthropic's Business Associate Agreement (BAA). Do not submit PHI to Claude Tag.

If your Claude organization has Anthropic's HIPAA configuration applied to Claude Code and Cowork in local mode, Claude Tag isn't available in that organization; ask your account team about a separate Claude organization, without that configuration, to hold the Slack pairing (section 1). In any other organization on Anthropic's HIPAA-ready Enterprise offering, Claude Tag starts switched off; an Owner can turn it on, and it remains outside BAA coverage. The Claude Tag documentation carries the fuller procedures: see Use Claude Tag at a healthcare organization.

Retention and deletion

Claude Tag retains channel memory and session transcripts (the Zero Data Retention item in section 1), so treat "what Claude can reach" as the boundary to design. Deleting a memory file doesn't delete transcripts, and there is no control that deletes a single thread's transcript.

The deletion controls run from largest to smallest: disconnecting a workspace deletes the workspace's Claude Tag data (sessions and transcripts, memory, routines, published artifacts, scopes, and members' account links; the Disconnect control itself is in the Member access dialog, above), and removing a channel's entry under Claude Tag's access deletes that channel's transcripts, memory, routines, and published artifacts.

Removing a channel's entry doesn't reach what the channel's sessions left elsewhere: notes saved to shared workspace memory or transcripts in other channels (disconnecting the workspace does delete those). And neither control reaches the pages, tickets, and pull requests Claude Tag created in your connected tools; those live in those tools and are yours to clean up.

What to do if PHI reaches a channel

If PHI does reach a channel, Anthropic recommends the following, alongside your own incident-response and HIPAA obligations: report to your privacy officer, remove the Slack message in line with your retention and legal-hold policies, have an Owner remove that channel's entry immediately, check workspace memory for notes saved while the channel was public, then contact Anthropic at privacy@anthropic.com for anything those controls don't reach, for example a transcript in another channel whose session found the message through search. Include the workspace, the channel ID, and the approximate time of the message. Do not include the PHI itself.

The recommended configuration

• Run Claude Tag as an allowlist: turn off Respond in all channels at the top of the Slack page's General tab (Claude's access › Channels › Slack; on the earlier admin page, Enable Claude Tag in Slack on Default Slack access), set any workspace or channel that has its own On setting back to Inherit (the inherited-setting link beside its enable switch, or Claude Tag version under Advanced; a workspace you launched with Entire workspace has one, and so does each channel chosen in a Specific channel launch), then turn on Enable Claude Tag in this channel on only the channels you approve. A mention anywhere else gets a disabled notice instead of a reply. Choosing Specific channel when pairing starts you in this posture. Per-scope switches are an Enterprise-plan capability. A Claude Tag admin can change them and Respond in all channels too, so give the Claude Tag Admin permission only to people you trust to approve a channel as PHI-free. A Team plan has name-based blocked channel patterns and Specific channel pairing (see limiting Claude Tag to specific channels), and Team plans can't be HIPAA-enabled for any Anthropic service. If PHI may be present in your workspace and you're on a Team plan, don't deploy Claude Tag in that workspace. Whichever plan you're on, turn off Allow direct messages so every interaction happens in channels, where the controls and deletion ladder above apply; the toggle covers group DMs too, and a one-to-one DM from a member who has connected a Claude account runs on that account, with their personal connectors. Turning DMs off doesn't keep members' own connectors out of channels (see "Never connect PHI-bearing systems," below). See allowing or disabling direct messages.
• Keep Claude Tag out of PHI's path entirely: with its own Slack access, Claude Tag can read a channel's full history only where it has been added (a member's own Slack connector is covered in the next bullet), so never invite it to a PHI-bearing channel. It can, however, keyword-search public channels across the workspace from the guest-free channels it works in; that search is the same keyword search any workspace member has, so the allowlist only keeps PHI out of Claude Tag's reach if your workspace policy already keeps PHI out of public channels. If you can't rely on that policy, pair Claude Tag with a separate Slack workspace that has no PHI rather than one in which PHI may appear. Approve PHI-free channels only. Slack Connect channels, the ones shared with other organizations, are already covered: Claude Tag doesn't work in them at all (see "Guests and Slack Connect," above). And Claude Tag is off by default wherever a Slack guest is present; see restricting guest channels.
• Never connect PHI-bearing systems: Claude Tag holds no credential of its own for an external system until an Owner (or, on Enterprise, a Claude Tag admin or a channel manager) adds a connection, so the EHR and clinical tools simply never get one. Read each approved channel's Connectors and Repositories lists to confirm the resolved set. Members' own claude.ai connectors are a separate path: once a member allows it, their connectors can serve their own requests in a channel, and each one, Slack included, reaches whatever that member's own account can. No organization setting turns personal connectors in channels off entirely, but a connector you block for your organization under Admin settings › Connectors stays blocked in channels too; count every connector you haven't blocked among the tools that must stay PHI-free. On an Enterprise plan, an Owner can require the requester to review every result before it posts (Require human review of every message, in the Personal connectors settings on the Claude Tag admin page); that limits what reaches the channel, not what Claude Tag reads. See per-channel access and personal connectors in channels.
• Review what accumulates: an Owner can open, edit, or delete each scope's memory files. The Activity page lists scheduled work, and actions in connected tools land in those tools' own logs under Claude Tag's service accounts (work done with a member's personal connectors is recorded under that member's name instead; section 7). Published artifacts are pages hosted on claude.ai, so anything that reaches one is held by Anthropic until the channel's entry is removed. See audit and review.

5. What your members will do, and what you control

Claude Tag is an ambient, multiplayer presence: one Claude per channel, shared by everyone in it. Wherever Claude Tag is on, a mention guarantees a reply; it isn't required for one.

What it can see follows the same shape: it reads the channels it has been added to, it can keyword-search public channels across the workspace (the same search any member has, though not from channels with guests; section 4), and it can't read private channels it isn't in. The exception is a member's own request: once they allow it, their own connectors, Slack included, reach whatever their account can (section 4).

When it replies on its own

With Claude Tag enabled for your organization (section 4) and Routines enabled (section 1), four settings decide whether one-to-one DMs work, and all four must allow it:

Group DMs follow the same Allow direct messages toggle and member-access restriction, and they stop wherever Claude Tag is switched off for the workspace; no setting covers group DMs alone. Claude Tag doesn't answer a group DM that includes someone from another company through Slack Connect, one in a workspace still set to Legacy, or, on Enterprise Grid, one whose members share no workspace. Outside Enterprise Grid, a group DM with a Slack guest in it follows the guest setting, so under the default, Restrict, Claude Tag posts its guest notice instead. See group DMs.

Quieting a channel

The volume knob lives where the noise is heard. Anyone in the channel can turn it by telling Claude Tag there; a channel member in your Claude organization can also flip Respond automatically on the channel's Configure page, and an Owner or a Claude Tag admin can switch it on the channel's page in Admin settings. Either way it applies to everyone's threads there.

Quiet one noisy thread by saying so in that thread, and remove Claude Tag entirely with /remove @Claude. The exact prompts to paste are in Control when Claude Tag responds.

Claude Tag also understands a short list of commands, sent as @Claude followed by the exact command word: !mute and !unmute quiet a thread or undo it (muting is per thread by design), !restart resets a stuck or wrong-context session, !configure returns the link to this channel's Configure page, and !status asks whether Claude Tag is still working, with an answer only you can see. The full list (including !fork, !help, !feedback, and !routines), with each command's exact syntax, is in Commands Claude Tag understands.

Two behaviors surprise people before they read the docs: reacting 👎 to one of Claude Tag's replies mutes that thread (a mention that carries a request brings it back), and when a lot of messages pile up in a channel since Claude Tag last posted there, it stops reading that channel and unprompted replies stop with it; it doesn't announce this, and a mention starts it reading again.

The hard boundaries

Respond automatically and the muting commands are guidance Claude Tag follows, and there is no organization-wide mention-only switch. If your security team wants an enforced boundary, use one of these:

Channel members shape their own channel

Every Claude reply in Slack ends with a footer, and outside Grid-shared channels its Configure link opens a page for that channel. Anyone in the channel who is also in your Claude organization can adjust how Claude Tag behaves there.

The page's two levers are the Respond automatically switch and Channel instructions: standing guidance read in every session there, which outranks channel memory. Instructions cover tone, scope, what to route to a human, and what never to touch. A pilot channel's might read:

Keep answers short and cite the dashboard you used. Only take on reporting questions for this team. Route anything about customer contracts to a human. Never touch production configs.

The rest of the page shows the channel's connections and allowed domains read-only, lets members add plugins, and lists the channel's routines; the tab-by-tab tour is in Configure Claude for a channel.

If you set Channel member edits to Block, the whole page goes read-only for members, the Respond automatically switch included; a channel manager you've assigned can still edit the instructions and default model.

Memory: who can see it, and how you review it

Claude Tag records memories as it works (What Claude Tag remembers has the mechanics), and where a memory lands depends on the channel it was made in.

Memory files and transcripts are separate records: deleting a memory file doesn't delete transcripts, and changing a channel between public and private doesn't move what's already saved. Deleting stored data happens at the workspace or channel level (section 4).

Who can see a memory follows two rules:

1. Public channels can add to the shared workspace memory: a note Claude Tag saves there from one public channel is available when someone asks in another, by design. If that's not what a team wants, that work belongs in a private channel.
2. A private channel reads the shared workspace memory but writes only to its own store: nothing Claude Tag learns in a private channel leaks into the shared pool.

Direct messages and other workspaces stay separate in both cases.

From any scope's menu, an Owner can open View memory files to read, edit, or delete the store, and anyone in the channel can curate memory just by asking Claude Tag what it remembers (see checking and correcting memory).

6. Cost aligns with the work Claude Tag does

Channel work and group DM work bill to your organization's usage balance, and a spend limit caps how much of that balance Claude Tag can draw each billing period. One-to-one direct messages from someone who has connected a Claude account are the exception: they bill to that user's own seat, like the rest of their claude.ai usage.

Someone in the workspace who hasn't connected a Claude account, other than a Slack guest, can DM Claude Tag one-to-one on your organization's balance for a limited time. That ends at whichever comes first: 7 days from their first such DM (or from starting the daily briefs Claude Tag offers them), $50 of usage (or your default limit for channels, if that's lower), or 50 sessions. After that, Claude Tag asks them to connect an account. The usage counts toward the organization-wide limit but doesn't show in the per-channel breakdown. Turning off Allow direct messages, turning on the member-access restriction, or switching Claude Tag off for the workspace stops these DMs; see direct messages from members without a Claude account.

Where the limits live

The money lives on the Usage page, not on the Claude Tag settings page, and that is easy to miss. It holds:

• The organization-wide limit for the period
• The default limit for channels without their own
• One row per channel with its spend against its own limit or the default; a channel whose limit you've set to none shows No spend limit and no usage bar, because only the organization-wide limit applies there

Channel spend counts toward two limits at once, the organization-wide limit and each channel's own, and Claude Tag declines new work in a channel when either is reached. Group DM work counts the same way, with your default limit for channels applying to each group DM.

Limits are enforced at list price and reset each billing period; for the fine print (negotiated discounts apply on your invoice, and promotional-credit usage shows here as $0.00, so read the List price column on the Analytics page instead), see Set a spend limit.

The console shown is an illustration of a fictional company; all names and numbers are invented.

What happens at a limit, and how spend is attributed

1. Claude Tag declines work that would cross a limit: it tells the requester in the thread. They can ask an admin for more, and the admin's notification says whether the balance or the limit caused the block. A separate throughput limit can also pause work; the reply names a short wait, and raising the spend limit doesn't clear it. See rate limits versus the spend limit.
2. Spend is shown per channel, not per user: on an Enterprise plan you can also pull per-user rows from the Analytics API's cost report grouped by claude_tag_user_id; see attributing costs to users in the docs for how work maps to people. Structure channels so each maps to a team, and the per-channel breakdown reads as your per-team report, with per-channel limits acting as team budgets.

Lowering spend in a high-volume channel

A channel where Claude Tag follows every message uses more of the budget than a mention-only channel, because it starts more working sessions on its own (reading the channel itself isn't billed). Where volume is high and value is low, turning off Respond automatically is your first lever, before the limit.

7. Review what Claude Tag has done

The Activity page (under Claude Tag in Admin settings) is the organization-wide view of:

• Scheduled work
• Memory files
• An hourly export of the network calls Claude Tag made through Agent Proxy

The page opens for Owners, not the built-in Admin role. The docs' Review what Claude Tag has done page details each tab.

Where each task is recorded

The Activity page does not log every task and who asked for it. That record lives in four places:

1. The Slack thread: Claude Tag works in the open. The plan, progress, and the result are in the thread, visible to anyone in the channel. For a task that used a member's personal connectors, the thread has the result Claude posted, and the detailed work lives in a session only that member can open.
2. The work itself: posts come from the Claude app; commits and pull requests show the Claude GitHub App and link back to the Slack thread. Who can open a published artifact follows access to the source channel, with no share setting to change; see artifact visibility in the security and data handling docs.
3. Each system's own log: because you provisioned the service accounts, what Claude Tag does through a connection shows up in that tool's own audit log the same way any user's actions do, under the account your security team already watches. Work done with a member's personal connectors is recorded under that member's name instead.
4. Your Claude organization's audit log (admin changes, not tasks): read through the Compliance API, it records workspace disconnects, scope removals, and what channel managers change.

8. Rollout: widen in rings, each one earns the next

Nothing here is a big-bang install. The organization ceiling is set once; everything after is a channel at a time, at the pace teams pull it. Ring one is a single pilot channel your own admin team lives in; you'll notice every quirk because you're in the room. Ring two is one team with real work in their channel and their own instructions. Ring three is everyone who asks, and by then budgets and habits are boring, which is the goal.

Day one: complete this checklist in order.

1. Pair the workspace and choose where Claude Tag may reply when tagged: the Entire workspace or Specific channel choice from step 1 of setup.
2. Connect GitHub and the other tools: create Claude Tag's own account in each tool it will use.
3. Fund usage and set limits: buy usage credits during setup (organizations that don't see that step set the monthly limit at launch instead), launch, then set a limit on the pilot channel from the Usage page, plus the organization spend limit if you didn't set it at launch.
4. Decide who may use Claude Tag at all: the restriction toggle under Member access › Manage.
5. Bind the pilot channel's access: keep elevated credentials on private-channel scopes.
6. Write the pilot channel's instructions on day one: tone, scope, what routes to a human, what never to touch; and turn off Respond automatically if it should stay quiet unless tagged.
7. Run one test task: ask Claude Tag to file a ticket or create a draft document in a connected tool, and confirm the action appears in that tool's own audit log under Claude Tag's account.

Watch the first week: check the Usage page for spend by channel, the Activity page for what's scheduled, or just ask Claude Tag in the channel what it's been working on. Then stop watching. Widen to ring two only after all of the above is dull.

The Claude Tag docs' after setup guidance covers the same pattern in more depth, and verifying your setup has the first-task checks.

9. FAQ

Where do I see every channel Claude Tag is working in?

The access editor's left rail (section 4) is the roster: every channel Claude Tag has been added to appears there automatically, whether it has spent anything or not. Spend by channel and per-channel limits live on the Usage page, and the Analytics page shows spend by channel read-only, including promotional-credit usage that the Usage page reports as $0.00 (section 6 also has the reseller note).

Can I make it mention-only across the whole organization?

Not organization-wide; the switch is per channel. Turn off Respond automatically on the channel scope's Advanced settings in Admin settings, on the channel's Configure page, or just by telling Claude Tag in the channel, and it holds for everyone there; see controlling when Claude Tag responds. If you need a hard organization-wide boundary instead, use the enforced controls listed under "The hard boundaries" in section 5.

Whose permissions does Claude Tag use?

Its own service accounts in channels and group DMs. In one-to-one direct messages, the asker's own claude.ai account; someone who hasn't connected one gets Claude Tag's own accounts for a limited time (section 6). In a channel or group DM, the asker's own connectors can also serve their own request after they allow it, recorded under their name. Section 4 has the identity model.

Can I block Claude Tag from a channel before someone invites it?

Yes: a Blocked channel pattern (the Advanced settings in section 4) keeps it out of matching channels even if someone invites it, and one channel's own Enable Claude Tag in this channel switch does the same for that channel. To confine it to chosen channels instead, see limiting Claude Tag to specific channels in the docs (on a Team plan, blocked channel patterns are the fence).

Can I read or delete what it remembers?

Yes. An Owner can open a scope's memory files from the scope's menu, and can edit or delete them. Anyone in a channel can also ask Claude Tag what it remembers and tell it to update or forget an entry.

Can I cap spend per user, or bill back by user?

Caps, no: limits are per organization and per channel, and channel and group DM work bill to the organization balance. (One-to-one DMs from people who haven't connected a Claude account have a built-in per-person limit; section 6.) Bill-back, yes on Enterprise, through the Analytics API's cost report (section 6; the how is in attributing costs to users).

Not answered here? The full list of controls that aren't available (third-party deployment, renaming the app, per-user caps, session-length enforcement, and more) is in the docs, alongside the glossary.

For the authoritative reference on every step, see the Claude Tag documentation. For account and billing questions, the Claude Help Center is the support channel.