Give it access to your tools

The agent starts with the group's own history and files, and the web. Everything else, such as your issue tracker, docs or data warehouse, you connect. Connections act with accounts you authorize on the group's behalf, not as the person asking: anyone in the group can ask the agent to use a connector.

There are several ways in:

Members can also connect their own accounts as personal connectors, used only for their own requests.

One group, some groups, or every group

Connectors, repositories, skills and secrets can be set up at three levels:

• For one group, by its admins, on the group's pages.
• For a bundle of groups, by the organization's Owners and Admins, on its Bundles tab. See Configure per-group access with bundles.
• For every group in the organization, by its Owners and Admins, on the organization's Connectors, Skills and Secrets pages. They apply unless a narrower connection overrides or disables the same server. Each group's pages list them under From the organization.

When the same server is connected at more than one level, the narrowest wins: the group's own connection, then a bundle's, then the organization's. Disabling a narrow connection suppresses the wider one. An anonymous narrow connection runs without a wider credential. A secret name may be configured at several levels; only the narrowest valid generation is mounted, and an unavailable narrow winner does not fall back.

Add a connector

1. On the Connectors page, under Add a connector, paste the server's MCP URL, e.g. https://mcp.example.com/mcp, and optionally a name.
2. Pick how it signs in:
   • No sign-in: leave the API token empty.
   • A static token: paste it as the API token. It's sent as a bearer token.
   • OAuth: leave the token empty. Servers that need sign-in send you through their OAuth flow next. Sign in with the account the agent should act as: a dedicated service account is best, since everyone in the group acts through it.
3. Cloud Tag lists the server's tools. Choose the connector's permissions (below) and save.

Each credential generation is stored in its own Anthropic Vault, and Anthropic refreshes OAuth tokens. Sessions mount only the Vaults selected with their connector policies. The agent's sandbox never sees them.

Existing authenticated connections show Reconnect needed after the one-time credential replacement. Reconnect OAuth accounts; remove and re-add static-token connections or re-enter secrets. Removed/replaced credentials first withdraw access; remote revocation remains pending until sessions stop and cleanup is confirmed.

On each connector you can Connect account or Reconnect account (OAuth), Refresh tools (no sign-in), turn it off with Enabled, or Remove it.

A group's agent attaches up to 20 MCP connectors after combining its own, its bundles' and its organization's settings. Its own connectors take priority, then applied bundles by bundle name, then the organization; within each scope, selection is by server name. If more are configured, the Connectors page names those left out of the next session. Turn off unneeded connectors at their owning scope to free a place. Changes to a resource that remains outside this selection do not start a new session.

Tool permissions

Each connector has a preset, plus optional per-tool overrides:

Under Per-tool overrides, set any tool to always_allow, always_ask or disabled.

A tool that isn't in the connector's tool list yet, because the server added it later, always asks first (under Only the tools enabled below, it's off).

An agent takes at most 128 per-tool settings across all its connectors. Only tools set differently from what a new tool gets (asking first, or off) count. Past that, disabled tools stay off and the rest ask first; if even the disabled ones don't fit, tools left out stay off. A connector that passes the limit by itself says so on its card. For a very large server, choose Only the tools enabled below and enable just the tools you need: tools that are off cost nothing.

Approvals

When the agent calls a tool set to ask, it pauses and posts a note in the thread naming the tool, with a link to the group's Approvals page. Any group admin can Approve or Decline there and see the call's arguments. The agent continues the thread as soon as you answer. Requests nobody answers are declined after a day.

The page shows each call's arguments in full, so what you approve is exactly what runs. A call whose arguments can't be shown in full is declined without asking anyone: one with a value under a name that says it holds a secret (such as a password, API key or access token), a URL with credentials in it, text with invisible or direction-changing characters, or arguments over 64 KB. The agent is told which arguments were the problem, never their values. Requests from before this check can only be declined.

Waiting requests are listed separately from recent decisions. Use Older requests to reach the rest, or All waiting requests to return to the first page.

Auto-approve rules

To skip the wait for routine calls, write auto-approve rules: plain sentences, one per line, each approving one kind of action, such as "Creating issues in the Platform project is fine." Before a call waits for an admin, a small model checks it against the rules. A call that one rule clearly covers goes ahead; anything else, or anything it's unsure about, still asks. Calls with very long arguments always ask, and calls with anything that looks like a secret in them are declined.

Write organization-wide rules on the organization page, and a group's own on its Approvals page. Up to 50 rules each. These are Claude Tag's auto mode allow rules.

Add a secret

For an API without an MCP server, add a secret:

1. Give it a variable name, e.g. EXAMPLE_API_KEY.
2. List the hosts it may be sent to, e.g. api.example.com.
3. Paste the value.

The sandbox sees only a placeholder in that environment variable. Anthropic substitutes the real value on requests to the listed hosts, and nowhere else. Values can't be read back; add the same name again to replace one.

Network access

On the group's Network & secrets page:

Connectors always work, whatever the mode: the mode governs web tools, package installs, and code the agent runs.

Limited mode still allows package managers when its host list is empty. Choose No internet to block package installs too. Changing the effective network policy, including the hosts listed for secrets, moves each thread to a fresh session on its next reply.

Network activity

The Network & secrets page lists what the agent reached recently, read from its tool calls: web fetches and searches, connector calls, and shell commands that name a host. A script that builds its URLs as it runs won't show there.

When a change takes effect

Adding, removing or changing a connector, repository, skill, secret or network setting changes the group's agent. Each thread moves to a fresh session on its next reply, reading the thread again, so the change applies everywhere, including a revoked credential.

Not built yet

• Curated connection guides for specific services, and federated identity (short-lived tokens instead of stored credentials).
• Auto mode as a whole. The auto-approve rules decide calls that would ask; nothing reviews calls that are already allowed.
• A sandbox-level network log. Network activity comes from the agent's tool calls.

Replacing a secret with the same hosts keeps the working value until the replacement is published. Changing its allowed hosts withdraws the old grant first; if the provider is unavailable, reconnect to finish the new configuration.