Your first Access bundle
An Access bundle is a named set of credentials, repository grants, and instructions that Claude uses in the channels the bundle covers. A connection is one service credential inside a bundle, like a Datadog API key or a warehouse service account, that Claude uses to act in that service from any channel under the bundle’s scope. If you’re in setup, you add these connections there; skip to Decide what to connect. The steps below are for creating a bundle outside setup, on the admin page directly.1
Open the admin page
Go to
claude.ai/admin-settings/claude-tag. Under Claude Tag’s access, the Slack tab shows your scopes (Default Slack access, then each workspace).2
Create a bundle on a scope
On the scope where you want the bundle to apply, click + next to Access bundles and choose Create new bundle. This creates the bundle and attaches it to that scope in one step; the bundle dialog opens.
3
Name the bundle
Click the pencil next to Untitled profile to rename it (the console uses “profile” and “Access bundle” interchangeably).
data-readonly, github-write, monitoring, gtm-tools. A capability name stays meaningful when the same bundle serves several teams; a team name (devprod-team) works when one team’s full access is the unit you’ll reuse.
Why create more than one bundle
Multiple bundles let you grant access by capability and compose it per channel. For example, with separatedata-readonly, github-write, and monitoring bundles: #platform-eng gets all three, #gtm-analytics gets only data-readonly, and #incidents gets monitoring plus github-write. Each credential is defined once, so rotating a Datadog key means editing one bundle without touching the others.
A bundle also has Domains, Plugins, and Instructions tabs alongside Credentials and Repositories. Use the bundle’s Instructions for guidance that should travel with a credential; use per-scope custom instructions for guidance tied to a place.
Decide what to connect
Six categories cover most of the work teams hand to Claude. Any service with an HTTP API can be added; start with the categories that match what your teams already do. Read-only connections are most useful in combination: an answer that joins the ticket, the deploy, and the error rate needs all three systems connected. Connecting many systems read-only is a different decision from granting write access anywhere.
Per-service instructions, with the credential fields and allowed-websites values, are in the connection guides.
Create a dedicated account per service
For each tool, create that identity specifically for the agent rather than reusing a shared bot key. The pattern depends on the service.
A dedicated account keeps the agent’s activity separately auditable in each tool’s logs and lets you revoke its access without touching anyone else’s. Grant read-only wherever the categories below say read; Claude can never exceed what the key allows.
If the person who administers a service isn’t you, send them this:
Limit access to specific resources
A connection has no setting for which pages, folders, or projects Claude can reach inside a tool. The connection’s reach is whatever the connected account can access in that tool. To narrow Claude to a subset, narrow the account:- Confluence or another wiki: give the service account read access to only the spaces or pages Claude should see
- Google Drive: share only the relevant folders with the dedicated Google account; see Google Workspace
- Project or ticket trackers: add the service account to only the projects it needs
Connect a service that isn’t in the list
The services with Connect buttons on the Credentials tab are presets, not the full set Claude can connect to. Any app with an API can be connected: use Connect another tool. See the Custom connection guide for the form fields, credential types, and how to add a custom MCP server.Allow a host without a credential
Claude does channel work in an isolated sandbox. A network request is traffic that sandbox sends to a host, such as an API call, acurl fetch, or a package install. Before Claude can make one from a channel, the destination host has to be allowed by one of three settings, the allow layers:
- A domain entry: a hostname listed on this bundle’s Domains tab. Requests to it pass with no credential attached; see Add a domain.
- A connection: a credential on this bundle’s Credentials tab. Requests matching its allowed websites pass with that credential attached.
- The scope’s environment: the compute configuration the scope’s sessions run in, which carries its own network access setting, starting at the Trusted level that covers common package registries. Requests to hosts it allows pass with no credential; see Broad web access through the environment.
Add a domain
A domain entry allowlists one hostname for every channel this bundle covers. After you add it, requests from those channels’ sandboxes to that host go through with no credential attached. To get there, open the bundle from the scope that covers the channel, under Claude Tag’s access atclaude.ai/admin-settings/claude-tag; if the scope has no bundle yet, create one first. On the bundle’s Domains tab, fill in the form and click Add domain:
- Domain: the hostname to allow; a wildcard is allowed as the leftmost label, like
*.example.com, and covers subdomains at any depth but notexample.comitself - Ports: needed only when the service listens on something other than 443
Agent Proxy carries only HTTP and HTTPS. A protocol that isn’t HTTP, such as SSH, can’t cross the proxy, so listing a host here doesn’t make it reachable over SSH.
Broad web access through the environment
Domain entries allow hosts one at a time. For a scope whose work needs more of the web, the environment setting grants broader access. An environment is the sandboxed compute configuration the scope’s sessions run in, and it carries its own network access setting. A new environment’s network access level is Trusted, which allows a documented set of package registries and developer hosts. A channel can already reach hosts likepypi.org and registry.npmjs.org with no domain entry.
To give a scope broader access, create an environment with a more permissive level and pin it on the scope.
1
Create the environment
At
claude.ai/code, add an organization-scoped environment and set its network access level. Full allows any domain. See Network access in the Claude Code docs for the create dialog. This step takes the Developer, Admin, Owner, or Primary Owner role.2
Pin it on the scope
Open the scope’s Advanced section and use the Environment picker. With nothing pinned, sessions use the organization default.
Allow all hosts
Allow-all egress is off by default; ask your Anthropic account team to enable it for your organization. Once enabled, you can enter* alone as the domain. A * entry needs ports assigned; it admits any host on those ports, with no credential attached.
With * active:
- Requests to hosts that no connection covers go through with no credential attached.
- A
*entry never carries a credential, and a connection’s credential still travels only to its allowed websites. - Private and internal network addresses and cloud metadata endpoints remain blocked.
* fails with an error saying allow-all hosts is not enabled for this organization. If the capability is later disabled, you can disable an existing * entry or narrow it to specific hosts, but you can’t keep it active.
Web search vs. network requests
Web search needs no domain entry, connection, or environment setting. It’s Anthropic’s built-in web search tool, and the searching happens on Anthropic’s servers rather than in the channel’s sandbox, so no allow layer applies. Opening a page is not part of the search. A search returns content from the pages it matches, which Claude reads and cites; fetching a URL from the sandbox is a network request like any other, and the host needs an allow layer. Claude can answer from a page that search surfaced yet report that it can’t open the same link. If the work needs Claude to open and read pages rather than answer from search results, allow those hosts through the settings above. Web search vs. network requests covers the session mechanics behind the split.Add a connection
On the bundle’s Credentials tab, click Connect next to a listed service, or Connect another tool for a service not in the list. For a custom connection, choose the credential type:
Credentials are injected at the network boundary by Agent Proxy; the model and the sandbox are not given the key. A request to a host you haven’t allowed is blocked, not sent. See how Agent Proxy works.
Set allowed websites
List the hosts a connection’s credential may be sent to. A wildcard works only as the leftmost label, like*.example.com; it covers subdomains at any depth but not example.com itself. You can’t enter * alone here; a credential is always limited to specific hosts. To let Claude reach any host without a credential, see Allow all hosts.
To change a connection’s name or allowed websites after saving, open the ⋮ menu on that connection’s row in the bundle’s Credentials tab and choose Edit. The same menu has Rotate secret (where the credential type supports it) and Delete.
Check the host against your account’s region before saving. Some presets fill a default host that may not match your account’s region; a Datadog key, for example, only works against your account’s Datadog site, like api.datadoghq.com or api.datadoghq.eu.
Restrict by path or method
After saving, you can restrict a connection by URL path or HTTP method, like allowingGET but not DELETE, for control tighter than host-level.
Connections vs claude.ai connectors
The connection gallery lists credential types the agent can hold, not the connectors your organization or its members have set up on claude.ai. A connection authenticates the agent, not a person; a connector on someone’s personal claude.ai account doesn’t appear here. For Google services, use a service-account key or the OAuth sign-in option, both of which give the agent one credential with access to the data the channel needs. Personal connectors keep working in DMs.Attach plugins
A connection grants access; a plugin teaches Claude how to use it well. A plugin is a bundle of skills, reusable instructions for working with a specific tool or following a specific process, and you attach plugins to the same Access bundle or scope that carries the connection, so the credential arrives with directions for using it. A Datadog API key, for example, makes the API reachable, and a Datadog plugin tells Claude which endpoints answer which questions. Sessions in covered channels pick up attached plugins automatically; there is nothing for channel members to install or enable. Anthropic provides plugins for common tools, and you can add your own from a skills repository. To give Claude organization-wide skills, bundle them in a plugin. Plugins attach in two places, and the two behave differently:- A plugin added directly on a scope (the plugin chips on the scope’s panel) is enabled there as soon as you add it.
- A bundle’s Plugins tab lists the plugins available to your organization, each off until you toggle it on.
Verify the connection saved
- Each connection is listed in the bundle with the host you set.
- New threads pick up new connections on their own. An existing thread isn’t told about a connection added after it started, but the connection works there; ask Claude to use the service by name.
Related resources
- Set a spend limit: fund usage so the connections you just added can run
- Configure GitHub access: repository access, managed through the Claude GitHub App
- How agent identity works: how the credentials you just added reach Claude without entering its sandbox