Skip to main content
Federated connections are managed on the Federated agent access page, under Claude Tag in the admin settings sidebar. Connecting a gateway, cloud role, or authorization server needs an organization Owner, or an admin with full Claude Tag management permission.
In Slack channels, Claude Tag acts under its own agent identity rather than as any person. Federated agent access lets that identity prove itself to your systems with a short-lived, signed identity token instead of a credential you store in Claude. In the console, you connect your gateway, AWS role, Google Cloud identity, or authorization server under Federated agent access, add it to a bundle, and apply it to the channels where Claude should use it. Your cloud or gateway administrator configures that system to trust Anthropic’s issuer and to check that each token’s subject belongs to your organization, and the system then decides what the agent may do. To confirm the connection works, ask Claude in one of those channels to make a small request, then check its reply and your system’s logs. Federated agent access goes one way: Claude proves who it is to your systems. For your workloads proving who they are to the Claude API, see Workload Identity Federation on the Claude Developer Platform. Your systems can accept the token in one of four ways. The table below says which to choose; the rest of the page explains what the token is and what to have ready.

​
Choose a connection type

In every case the system on your side decides what the agent may do in your systems. Each connection type has its own setup page: Connect a gateway, Connect an AWS role, Connect a Google Cloud identity, and Connect an authorization server.

​
How it works

  1. When a request from Claude’s sandbox needs one of your systems, Agent Proxy matches it by destination to a federated connection that applies to the channel. Until an admin connects a system in Federated agent access and applies the connection to the channel, nothing matches and no token is issued for Claude’s requests.
  2. Anthropic issues an identity token. The token is a JSON Web Token (JWT) signed by Anthropic and valid for 10 minutes. Its subject names your organization and the agent, in the form wimse://identity.anthropic.com/org/<your organization ID>/agent/<agent ID>, and its audience names the destination. Claude reuses one token for a session’s requests to the same gateway for about five minutes, or until the gateway answers 401, and then requests a new one. The other connection types use a token once, in an exchange.
  3. Your side accepts the token. A gateway verifies it directly. AWS or Google Cloud exchanges it for a short-lived cloud credential. Your authorization server exchanges it for an access token. Agent Proxy attaches the result to Claude’s request, or signs the request with it for AWS, and forwards the request. The model and the sandbox are never given the token or the credential that comes back.
Whichever system accepts the token checks five things:
  • Signature, against the public keys Anthropic publishes, and issuer. Together these prove Anthropic issued the token.
  • Audience. This proves the token was issued for the destination it’s presented to: your gateway, your authorization server, your Google Cloud provider, or AWS.
  • Expiry. This proves the token is fresh.
  • Subject. This is what names your organization. Every Claude Tag organization’s tokens come from the same issuer, and every organization’s AWS tokens share the same audience, so the first four checks can pass for a token that belongs to someone else. Every connection type therefore requires a subject check. The strongest form accepts only the exact subjects of your own agents. The minimum form requires the subject to start with your Subject prefix, wimse://identity.anthropic.com/org/<your organization ID>/agent/, including the /agent/; a gateway, authorization server, or Google Cloud attribute condition can pin iss and tenant instead, since tenant carries the same organization ID.
The console shows the issuer, the signing-key location, and your Subject prefix with copy buttons, and each setup page says where they go. The identity token reference lists every value and claim and compares the two forms of the subject check. Anthropic stores no long-lived credential for your systems, and each call carries a short-lived signed token, so there is no key of yours to rotate or leak. Anthropic rotates its own signing keys, and the token reference says how a verifier follows them. To cut off access, remove the connection in the console. These lifetimes then apply: Anthropic doesn’t review your gateway, trust policy, or authorization server. When you connect a gateway, the console offers a connection check that confirms the gateway rejects a token whose subject isn’t your organization. The other connection types have no connection check. For an AWS role, Check trust policy in the role’s row of the Cloud roles table checks a trust policy you paste against that connection’s token format. The check runs in your browser and doesn’t change the connection. You verify the rest yourself with the steps on each setup page.

​
Before you begin

  • Federated agent access appears under Claude Tag in the console’s left navigation. It’s missing for organizations whose compliance configuration excludes federated agent access.
  • An organization Owner, or an admin with full Claude Tag management permission, makes the connection in the console.
  • Your cloud or gateway administrator configures the system on your side: the gateway operator, your AWS or Google Cloud IAM administrator, or your authorization server’s operator. Each setup page lists the values they configure.
  • You know which channels, workspaces, or all of Slack Claude should use the connection in. A connection applies wherever its bundle applies. A gateway can also be added to more than one bundle; an AWS role or authorization server is connected in one bundle only.
Federated connections work in Slack channels, where Claude acts under your organization’s agent identity. They don’t work in one-to-one direct messages from members who have connected a Claude account, which run under the individual’s own account.

​
Manage federated connections on the Connectors tab

After you connect a system, choose where the connection applies. Each connect dialog puts the connection in the bundle you choose or create there. The connection then also appears as a connector on the Connectors tab under Claude’s access at claude.ai/admin-settings/claude-tag, where the tab’s search finds it by name or host and its row in the connector’s Access from table shows its type in the Credential column. Manage it from there:
  • Choose where it applies: a bundle you create in the connect dialog applies nowhere until you choose places. The bundle is listed on the Bundles tab, where you add places under Where it applies and click Save changes. To choose places from the connector’s page instead, see Give Claude access.
  • Edit its allowed hosts: in the connector’s Access from table, open the connection’s ⋮ menu and choose Edit to open the Edit connection dialog.
  • Delete it from its bundle: open the connection’s bundle from the Bundles tab, and under What’s in it choose Remove credential from the connection’s ⋮ menu, then click Delete to confirm. The Set by column of the connector’s Access from table names that bundle.