Skip to main content
In channels, Claude acts under its own service accounts that an Owner provisions. 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 adds connections. Each connection is scoped to specific channels and workspaces, 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 a sandbox Anthropic hosts, leaves that sandbox only through Agent Proxy, and reaches your systems under the agent’s own accounts. DMs run on the user’s own claude.ai account instead and are covered separately on How agent identity works.

​
How a request travels

Each Slack thread runs in its own sandbox, and every outbound call from that sandbox passes through the same checkpoints. Diagram showing the request path across three zones. A task mentioned in your Slack workspace runs in a session sandbox on Anthropic's infrastructure, one sandbox per thread, holding no credentials. Outbound requests pass to Agent Proxy, which injects the credential drawn from the credential store; a request matching no rule 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.
CheckpointThe guarantee
The sandboxRuns on Anthropic’s infrastructure and holds no credentials
Agent ProxyInjects credentials from the credential store at request time, and blocks traffic to unlisted hosts by default
Your systemsSee the agent’s own accounts, so its actions there are attributable

​
Compute and the sandbox

Sessions run in sandboxes Anthropic hosts, the same managed compute behind 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.

​
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 the connection.
  • You can narrow the credential further, to one host, one path prefix, or read-only methods, in Add connections.

​
Network egress

Outbound traffic from a channel session’s sandbox is default-deny. Requests go only to hosts an Owner allowed, either on the bundle’s Domains tab or through a connection’s Allowed websites, and every request gets one of three outcomes:
  • Matches a credential rule. The credential is attached at the boundary and the request proceeds.
  • Matches only an allowlist. The request is sent without credentials.
  • Matches nothing. The request is blocked outright; the host is unreachable rather than merely unauthenticated.
Flow diagram across two zones. Inside Anthropic's infrastructure, a session sandbox that holds no 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, 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 unlisted hosts are blocked, data can only leave the sandbox to hosts you’ve allowed. The egress boundary is the Allowed websites list, which an admin sets on each connection and on a bundle’s Domains tab; see Set allowed websites and Allow a host without a credential.

​
Service accounts

In channels, Claude acts under service credentials of its own. The Slack surface is the Claude app, code work goes through the Claude GitHub App, and every other tool gets a service account an admin provisioned. See How agent identity works for the full model. DMs with @Claude run on the user’s own claude.ai account with their personal connectors, and work there is attributed to that user. Admins can disable DMs organization-wide; see Allow or disable direct messages.

​
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 to organization members only, or to members whose role grants it. The setting and the role-based configuration are on Members. It governs DMs as well as channels.