Skip to main content
Claude Tag’s identity depends on where you message it. In Slack channels, Claude acts with its own service accounts, rather than as a specific user. An organization Owner provisions this identity during setup, so it arrives with its own account in each system it works in: the Claude app in Slack, the Claude GitHub App on GitHub, and a service account in every other connected tool. Actions it takes are attributed to those accounts; for example, posts come from the Claude app and pull requests show the Claude GitHub App as the author. In organizations where personal connectors in channels is available, Claude can also use your own claude.ai connectors for a task you hand it in a channel, after you allow it. See Personal connectors in a channel. In direct messages (DMs) between a user and @Claude, the provisioned identity does not apply. DMs are one-to-one only; group DMs aren’t supported. A DM has no channel to scope it to, so a DM session runs on the individual’s own claude.ai account instead, with their personal connectors. GitHub is the exception in attribution: a pull request opened from a DM is authored by the Claude GitHub App, the same as in channels, though the session can only work with repositories connected on that user’s own account. Owners can disable DMs organization-wide; see Allow or disable direct messages.
How Claude behaves in channels (its standing instructions, plugins, and channel memory) is configured separately from its identity; see custom instructions, plugins, and memory for more information.

​
Channel sessions

When Claude works on a channel task, the request moves through three places:
  • The ask happens in your Slack workspace, when a user tags Claude to do something or a scheduled task starts.
  • The work Claude does runs in a sandbox, an isolated working environment built for the thread.
  • The agent’s credentials for any additional connections, such as GitHub or a data warehouse, reach those systems to pull the required information. An organization Owner sets up those credentials as part of provisioning the identity.
The diagram below traces one request through this process. 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 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 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.
1

Tag Claude in a channel

A user asks Claude to chart last week’s signups or fix a deploy test. The task gets a session in a thread under the message.
2

The session sandbox starts

Claude does the work in an isolated environment built for this thread, reading files, writing documents, and running code. The credentials you provision are not placed in the sandbox; they stay in the credential store and are injected at the proxy.
3

The request crosses Agent Proxy

When the work needs something outside the sandbox, like calling the GitHub API or querying a warehouse, the request crosses Agent Proxy, the network boundary between the sandbox and everything else. Agent Proxy checks it against the rules an admin configured, and decides whether it proceeds and what credential, if any, travels with it.
4

Agent Proxy attaches a credential

A matching credential comes from the credential store, where an admin’s connections are kept. Once saved, a credential is never displayed again; Agent Proxy retrieves it only at the moment of injection and attaches it to the request at the boundary, so the model and the sandbox itself are not given the key.
5

The result posts back, as Claude

The credentialed request reaches your system, like GitHub or the warehouse, and the result returns to the thread.

​
Agent Proxy

For each outbound request from the sandbox, Agent Proxy checks the destination against three allow layers. A request goes through if any one of them allows it; a host that none of them allows is blocked. A new environment’s network access level defaults to Trusted access, so a fresh setup can reach a documented set of package registries and developer hosts before an admin has configured anything. The cloud environments documentation lists the covered hosts. To narrow that default, pin an environment with a stricter level, such as No access. The same rules apply to code Claude runs in the sandbox, like curl or a fetch call: a request is blocked unless its host is allowed by one of the layers above. Agent Proxy carries HTTP and HTTPS only. A protocol that isn’t HTTP, such as SSH or a database’s native wire protocol, can’t cross the proxy even to an allowed host. For the endpoints and addresses your network team may need to allowlist, see Network requirements.

​
How a host gets allowed

A host that none of the three layers above allows is blocked, and Claude names the blocked host in the thread so an admin can add it; see Give Claude access to your tools.

​
Web search vs. network requests

Claude can search the web from a channel without any Domains entry. Web search is Anthropic’s built-in web search tool, which runs on Anthropic’s servers, not code running in the channel’s sandbox. The sandbox sends nothing new for a search. Search requests travel to Anthropic the same way the session’s model traffic already does, and the searching happens server-side. The Agent Proxy rules don’t apply to web search; fetching a page or calling a service from the sandbox is an outbound network request and follows them. Searching and opening a page are different actions. A search returns content from the pages it matches, which Claude reads and cites, so it can answer from a page that search surfaced. Opening a URL, whether one you pasted or one a search returned, is a fetch from the sandbox, and the host needs an allow layer. That is why Claude can quote a page it found through search and still report that it can’t open the same link. The web search capability setting in your organization’s claude.ai admin settings governs claude.ai chat; it doesn’t govern Claude Tag sessions, in channels or DMs. If Claude reports that it can’t reach a host from a channel, the fix is a domain entry or the scope’s environment, not that setting.

​
Agent access

What Claude can reach in a channel comes from the Access bundles an admin attached to that channel’s scope. Anyone in the channel gets the same capability, and the same request can do more in #platform-eng than in a general channel. This design has four consequences.
  • Configure once. Everyone in the scope can use it immediately.
  • Predictability. What Claude can do never changes based on who asked.
  • Personal connectors are separate. A shared channel session uses only the service-account connections an admin attached. Where personal connectors in channels is available, Claude uses the connectors on your own claude.ai account only for your own tasks, after you allow it.
  • Clean audit. Actions the channel session takes in connected tools show up under a service account your security team already knows how to reason about.
That service-account identity is also how Claude appears wherever it acts. In Slack, it posts as the Claude app. On GitHub, commits and pull requests show the Claude GitHub App, and pull requests link back to the Slack thread they came from. In every other connected service, actions appear under the service account an admin provisioned, in that service’s audit log.

​
Personal connectors in a channel

A channel session works with the channel’s Access bundles, so the connectors on your own claude.ai account are not part of it. Personal connectors in channels is available to a limited number of organizations. Where it is available and a task you hand Claude needs something only your connectors can reach, Claude can use your connector for that part of the work, and it asks you before it starts. The work runs with your permissions and is recorded under your name. Requests other people make to Claude in the task’s thread run with the channel’s own access, not with your connectors. Claude is designed to take direction from you, treating what other people post in the thread as information for the task rather than as instructions. Personal connectors in channels covers how you approve connector use, when Claude holds a result for your review before posting, what other people in the channel see, and how to stop a task.

​
Direct message channels

A DM with Claude works differently from a channel. There is no scope to attach an identity to, so a DM session runs with your own claude.ai account instead, the same way a Claude Code session on the web does, using your own connectors and credentials, with results attributed to you (pull requests excepted; the Claude GitHub App authors those from DMs too). The diagram contrasts with the channel path above; the sandbox is the same engine, but everything around it is yours. Diagram showing how a DM session reaches your systems. A message to Claude in a direct message runs in a session sandbox, in a zone labeled Anthropic's infrastructure, the same engine as a channel session, but it runs with your identity. From there it reaches your systems through your own connectors and accounts, like GitHub or Drive, using your own credentials. A dashed return path shows results posting back in the DM, as you. Diagram showing how a DM session reaches your systems. A message to Claude in a direct message runs in a session sandbox, in a zone labeled Anthropic's infrastructure, the same engine as a channel session, but it runs with your identity. From there it reaches your systems through your own connectors and accounts, like GitHub or Drive, using your own credentials. A dashed return path shows results posting back in the DM, as you. The table lines up the two paths on the four dimensions that differ. Three of those differences are worth spelling out.
  • Connectors. The connectors on your account are available, including MCP servers you’ve added.
  • Billing. Usage bills to your seat rather than the organization’s service key.
  • Channel-side configuration. It doesn’t follow you in; the agent’s connections and repository grants don’t apply in DMs.
DM work runs under your credentials, so most of it is attributed to you and can reach only what your own accounts can. Pull requests are the exception: Claude authors them as the Claude GitHub App from DMs too, so a repository’s history shows the same author either way, while the repositories it can reach are still only the ones connected on your own account. Use channels for shared work and DMs for personal tasks, or for data you’d rather access under your own authenticated identity than a shared channel credential.

​
Claude Tag versus Claude Code in Slack

A DM with Claude Tag runs under your own account, which is also how Claude Code in Slack works, routing a coding @-mention to a Claude Code session on the web under the requester’s own account. The two can look identical. The table shows how to tell them apart. If @Claude in your workspace opens pull requests as you, you’re seeing Claude Code in Slack, not a Claude Tag session.