Skip to main content
In channels, Claude acts under its own service accounts. By default it can read and post in Slack channels it’s been added to and search public channels by keyword; it has no access to your external systems until an Owner or a Claude Tag admin adds Claude Tag connectors. An admin chooses where each connector applies, from every channel down to one, and the actions Claude takes in connected tools are attributable to its own service accounts. Every channel request, whether a person typed it or a schedule triggered it, follows the same path: it runs in an isolated sandbox, and the credentials you provision aren’t placed in that sandbox. In an Anthropic-hosted environment, requests leave that sandbox only through Agent Proxy and reach your systems under the agent’s own accounts. Sessions in a self-hosted environment run on runners inside your network, and Claude can’t use the connectors an admin adds in those sessions. One-to-one DMs from members who have connected a Claude account run on the member’s own claude.ai account instead and are covered separately on How agent identity works. For DMs from members who haven’t, see Direct messages from members without a Claude account.

​
How a request travels

Each Slack thread runs in its own sandbox. In an Anthropic-hosted environment, every outbound call from that sandbox passes through the same checkpoints. Diagram showing the request path across three zones, labeled your Slack workspace, Anthropic's infrastructure, and your systems. A task mentioned in the Slack workspace runs in a session sandbox in the middle zone, one sandbox per thread, holding no stored credentials. Outbound requests pass to Agent Proxy, which injects the credential drawn from the credential store; a request that no rule, domain entry, or environment network access setting allows is blocked. Credentialed requests reach your systems, like GitHub, a data warehouse, monitoring, or any HTTP API. A dashed return path shows results posting back in the thread, as Claude. Diagram showing the request path across three zones, labeled your Slack workspace, Anthropic's infrastructure, and your systems. A task mentioned in the Slack workspace runs in a session sandbox in the middle zone, one sandbox per thread, holding no stored credentials. Outbound requests pass to Agent Proxy, which injects the credential drawn from the credential store; a request that no rule, domain entry, or environment network access setting allows is blocked. Credentialed requests reach your systems, like GitHub, a data warehouse, monitoring, or any HTTP API. A dashed return path shows results posting back in the thread, as Claude.

​
Compute and the sandbox

Sessions run in ephemeral sandboxes, the same infrastructure that runs Claude Code on the web. Each Slack thread gets its own sandbox. When a thread goes quiet, its sandbox is released; replying in the thread builds a fresh one. What persists across that release and rebuild:
  • Persists: The thread, its visible work, and anything pushed to a branch, opened as a pull request, or posted into Slack.
  • Does not persist: Files that existed only inside the sandbox. To keep generated files, ask Claude to push them to a branch or post them in the thread.
Claude Tag retains channel memory and session transcripts. Because of that retention, Claude Tag isn’t available to organizations with Zero Data Retention (ZDR) enabled. Claude Tag also isn’t available to organizations with a customer-managed encryption (CMEK) policy, or to organizations that have the HIPAA configuration applied to Claude Code (local mode) and Cowork (local mode).

​
Credential storage

Credentials you provision are kept in a separate credential store, not in the proxy itself. When an outbound request matches a rule, Agent Proxy, the network layer between the sandbox and any external host, retrieves the credential from that store and injects it at the boundary, so the model and the sandbox are not given the key. This means:
  • A saved credential is not displayed again. The setup screens are write-only.
  • The credential travels only to the hosts you named when you added it.
  • You can narrow the credential further, to one host, one path prefix, or read-only methods; see Restrict by path or method.

​
Network egress

In an Anthropic-hosted environment, outbound traffic from a channel session’s sandbox is default-deny. Requests go only to hosts an allow layer covers, and the layers are a credential’s allowed websites, the allowed domains that apply to the channel, and the network access setting of the environment the scope’s sessions run on. A new environment’s default level, Trusted access, already covers a documented set of package registries and developer hosts. See Agent Proxy for what happens to a request under each layer. Flow diagram across two zones, labeled Anthropic's infrastructure and your systems. In the first zone, a session sandbox that holds no stored credentials sends every outbound request to Agent Proxy, which matches it against admin rules. Three outcomes branch toward your systems: on a rule match, the credential is attached at the boundary and the request proceeds; on an allowlist-only match, from an allowed domain or the environment's network access setting, the request is sent without credentials; on no match, the request is blocked entirely (the default-deny outcome) and the host is unreachable. Flow diagram across two zones, labeled Anthropic's infrastructure and your systems. In the first zone, a session sandbox that holds no stored credentials sends every outbound request to Agent Proxy, which matches it against admin rules. Three outcomes branch toward your systems: on a rule match, the credential is attached at the boundary and the request proceeds; on an allowlist-only match, from an allowed domain or the environment's network access setting, the request is sent without credentials; on no match, the request is blocked entirely (the default-deny outcome) and the host is unreachable. Because requests to any other host are blocked, data can only leave the sandbox to hosts an allow layer covers. An admin sets the allowed websites on each credential and the allowed domains. An admin sets the environment’s network access level, which defaults to Trusted access, from the Cloud environments page in admin settings. See Set allowed websites and Allow a host without a credential. Allow-all egress is a * domain. The entry admits requests to any host on the ports it lists, still without credentials. Private and internal network addresses and cloud metadata endpoints remain blocked. See Allow all hosts.

​
Service accounts

In channels, Claude acts under service credentials of its own, not under the account of the person who tagged it. The Slack surface is the Claude app, code work goes through the Claude GitHub App, and every other connected tool uses a service account whose credential a connector holds. See How agent identity works for the full model. A connector’s credential belongs to that agent identity and is shared by everyone in the channels where it applies. Anyone in one of those channels 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. Connect a dedicated identity you control for each service, such as a claude@yourcompany.example.com seat or a native service account, rather than a personal login. 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; see Create a dedicated account per service. One-to-one DMs with @Claude from a member who has connected a Claude account run on that member’s own claude.ai account instead, with that member’s personal connectors, and work there is attributed to them, except pull requests, which the Claude GitHub App authors from DMs as well. For DMs from members who haven’t, see Direct messages from members without a Claude account. An Owner can turn off DMs for the whole organization; see Allow or disable direct messages. Claude uses a user’s personal connectors in a channel only for that user’s own tasks, after the user allows it. The work runs with that user’s permissions and is recorded under their name. Requests other people make to Claude in the task’s thread run with the channel’s own access, not with that user’s connectors. Claude is designed to take direction from the connector’s owner, treating what other people post in the thread as information for the task rather than as instructions, and the owner can tell Claude in the task’s thread to stop. On the Enterprise plan, an admin can require the user’s review of every result before it posts. See Personal connectors in channels.

​
Isolate credentials between channels

A channel session can use only the access an admin applied in one of these places:
  • The channel itself. Access added on the channel’s page, or a bundle applied to the channel, reaches that channel only.
  • The channel’s workspace. Access added on the workspace’s page, or a bundle applied to the workspace, reaches every channel of that workspace.
  • All of Slack. Access added on the Slack page, or a bundle applied there, reaches every channel of every paired workspace. The first credential you add for a service on the Connectors tab is on here as soon as you save it. See how scopes inherit.
  • A channel rule. A bundle an Owner applies to a channel name pattern reaches every matching channel in all of Slack or in one workspace, including channels created or renamed later.
Access applied anywhere else in your organization is invisible to the session, and no request from the session’s sandbox can carry a credential that doesn’t apply to its channel. For example, if a bundle holding finance credentials applies only to one private channel, sessions in every other channel run as if that credential doesn’t exist. If the same bundle applies to a workspace or to all of Slack instead, every channel beneath it gets that access, so isolation comes from where the access applies, not from the bundle itself. To confine a credential to one channel:
  1. Apply it to that channel and nowhere broader. The first credential you add for a service on the Connectors tab applies in all of Slack as soon as you save it. To keep the credential out of other channels from the start, add it in one of these ways instead:
    • In a bundle whose Where it applies list holds only that channel.
    • From the channel’s page. Under Claude’s access, click Add and select Connector. On the dialog’s Connectors tab, select the service under Connect new and click Continue. The credential you enter in the connect form applies in that channel only.
    • On the page of a connector already on the Connectors tab, select Add credential from the ⋮ menu at the top of the page. The new credential is off everywhere until you pick it in the channel’s row under Assign access, selecting Add place if the channel isn’t listed.
  2. Keep the channel private. Access on a public channel reaches anyone who joins.
  3. Open the channel from the Channels tab under Claude’s access at claude.ai/admin-settings/claude-tag and check its Claude’s access table. It lists the access that reaches the channel, and an item a bundle brings is listed under that bundle’s row. The Inheritance column shows whether each bundle, and each item outside a bundle, was added on the channel’s page or inherited from the workspace or from Slack.
In a channel shared with another company through Slack Connect, once Claude is turned on there, it has the connector credentials from the bundles attached directly to that channel, including bundles attached before the channel was shared. It also has those from any bundle attached specifically for Slack Connect channels, and it can use them for anyone it answers there, including the other company’s people. Credentials inherited from the workspace or the Slack page don’t reach that channel, and neither do members’ personal connectors. Before you share a channel that already has bundles, check its Claude’s access table and remove the channel from any bundle you don’t want used for the other company’s people. When you ask Claude in one channel to post into another, Claude works with the access and instructions of the channel you asked in, not the target channel’s. From a private channel, Claude doesn’t post anywhere else, and nothing asked elsewhere makes Claude post into a private channel. What Claude can do in other channels covers where Claude can post from each place you ask. Isolating a credential doesn’t isolate what Claude knows. The workspace notes it saves from a public channel are read by sessions in every channel of the workspace, and it can search public channels by keyword without being added to them, the same way any workspace member can.

​
Artifact visibility

A session can publish an artifact, a web page hosted on claude.ai with the link posted in the thread, and the page stays available after the sandbox is released. Anyone with access to the source Slack channel can open it, which in a public channel covers everyone in the workspace. Someone who opens the link without that access can’t see the page and has no option to request access. There is no share setting for anyone to change. Updates go through Claude: ask in the Slack thread, or send Claude a comment on the page, which anyone who can post in the channel can do. While a Slack guest is in a channel set to Channel only, Claude doesn’t publish artifacts there. Artifacts you publish from your own Claude Code sessions work differently: they belong to you, and you control who can open them, with sharing options that depend on your plan and organization settings. See the Claude Code artifacts documentation.

​
Member access

By default, anyone in a connected Slack workspace can invoke Claude in channels, with or without a Claude account. An Owner can narrow that on the Advanced tab of the Slack page, which the Slack row on the Channels tab under Claude’s access opens:
  • Team plans: Restrict to your organization limits Claude to people with a Claude account in your organization
  • Enterprise plans: Restrict to roles with Claude Tag access limits Claude to members whose role grants the Claude Tag in Slack capability
See Restrict who can use Claude. The restriction governs DMs as well as channels.