One read of Claude Documentationclaude-docs-20260814T092040Z

government/org-admin/overview First recorded · 78 lines, first recorded

# Organization administration ## Key concepts ## Who can access it ## Getting around ## Pages in this portal ## How changes take effect

The first capture of this source. The page was already there, and this is what it said.

# Organization administration

> Manage the people, seats, and settings for a single organization within your agency.

> **Who this portal is for:** Organization owners. If you manage multiple organizations across your agency, see the [Tenant administration](/docs/government/tenant-admin/overview) guide instead.

The organization admin portal is where you manage the people, seats, and settings for a single organization in Claude for Government. It covers the day-to-day work of administering who has access, how much they can use, and how the Claude products behave for your users.

## Key concepts

Before you use the portal, it helps to understand how the pieces fit together.

Your agency's deployment is a **tenant**, which is the top-level container that holds one or more **organizations**. An organization is a self-contained group of users with its own seats, settings, and usage. Most administrators work at the organization level, while tenant administrators oversee all of the organizations together and control tenant-wide resources such as single sign-on, directory provisioning, and billing accounts.

Every person in an organization holds a **role**, which determines whether they can reach this portal at all, and occupies a **seat** on a **seat tier**, which determines which Claude models they can use and how much they can use them. Seat tiers come in two kinds:

* **Anthropic-managed tiers** that are supplied to you as a fixed number of seats.
* **Self-managed tiers** that your organization defines itself and that draw from the billing account's balance.

## Who can access it

You can reach the organization admin portal if your role in the organization is **Owner** or **Primary Owner**. Users who hold the standard **User** role are redirected to their personal account page instead.

> **For tenant administrators:** You can also open this portal for any organization in your tenant. When your tenant contains more than one organization, an **Acting as** selector appears at the top of every admin page so you can choose which organization you are currently managing. All the changes you make while acting as an organization apply to that organization, and the audit trail records your own identity as the actor.

## Getting around

The portal header shows your organization's name, and a navigation bar below it gives you access to each admin page.

<Note>
  If the account your organization draws from crosses a warning threshold, a banner appears just below the navigation on every page of this portal. When your organization manages the account or is the only one using it, the banner tells you the percentage of credits used. When the account is shared with other organizations and yours does not manage it, the banner instead says credits are running low and points you to your tenant administrators. The banner stays in place until more credits are added to the account, and it escalates in color and wording if usage crosses a higher threshold. Every owner sees the banner, including when the Billing tab is hidden, so that you always know when your organization is running low.
</Note>

> **For owners and tenant administrators:** You can reach the user view from the **Switch to user view** link in the page footer. If you are also a tenant administrator, the footer additionally offers **Switch to tenant view**.

## Pages in this portal

The navigation groups the pages into three sections.

**People**

| Page                                                 | What it's for                                                                                                                  |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| [Users](/docs/government/org-admin/users)                 | Find users, change their role or seat tier, check their usage, and reset their rate limits.                                    |
| [Seats](/docs/government/org-admin/seats)                 | See how many seats of each tier your organization has and how many are currently in use.                                       |
| [Tiers](/docs/government/org-admin/seat-tiers)            | Review the Anthropic-managed seat tiers and create your own tiers with custom model access and spend limits.                   |
| [Group mappings](/docs/government/org-admin/provisioning) | Map directory groups to seat tiers and roles so that users added through your directory land in the right place automatically. |

**Usage**

| Page                                                   | What it's for                                                                                                          |
| ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| [Analytics](/docs/government/org-admin/analytics)           | Review requests, tokens, spend, top users, and credit balance over time across your organization.                      |
| [Compliance API](/docs/government/org-admin/compliance-api) | Create and manage read-only API keys that stream your organization's audit events to a SIEM or log management system.  |
| [Billing](/docs/government/org-admin/billing)               | See the billing account that funds your organization, its balance and any spend caps, and adjust your seat allocation. |

**Settings**

| Page                                          | What it's for                                                                                                                     |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| [Config](/docs/government/org-admin/configuration) | Adjust product settings such as telemetry, the Claude Desktop banner, and product availability for everyone in your organization. |
| [Readiness](/docs/government/org-admin/readiness)  | See what is blocking users from using Claude and where each item is resolved.                                                     |

<Warning>
  The **Billing** tab only appears when the billing account is active and your own organization is active on it. If you don't see it, contact your tenant administrators about credits or spend caps.
</Warning>

<Warning>
  The **Group mappings** tab only appears if automatic directory provisioning has been set up for your tenant. If you don't see it, your tenant administrator has not connected a directory, and users are placed by the tenant's routing rules alone.
</Warning>

<Note>
  Single sign-on and the SCIM provisioning connection are configured at the tenant level, so they are managed on the [tenant portal's Identity and access page](/docs/government/tenant-admin/identity-and-access) rather than here.
</Note>

## How changes take effect

Most changes you make in this portal take effect immediately. Changing a user's seat tier, updating a spend limit, or resetting a user's rate limits applies to their very next request. Product configuration changes are picked up the next time a user's Claude application refreshes its settings, which happens when the application is launched or when the user signs in. Group mapping changes trigger an immediate re-sync so you do not need to wait for a scheduled cycle.

government/org-admin/provisioning First recorded · 56 lines, first recorded

# Group mappings ## How provisioning works ## Group to seat tier ## Group to role ## How mappings are applied ## Group to organization routing ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Group mappings

> Use this page to map the groups pushed from your identity provider to seat tiers and roles in this organization.

> **Who this is for:** Organization owners who want directory groups to drive seat tiers and roles automatically.

Use this page to map the groups pushed from your identity provider to seat tiers and roles in this organization.

<Note>
  The **Group mappings** tab only appears in the navigation if automatic directory provisioning has been set up for your tenant. If you don't see the tab, your tenant administrator has not connected a directory.
</Note>

**SCIM** (System for Cross-domain Identity Management) is the standard protocol that identity providers such as Okta and Microsoft Entra use to push user accounts and group memberships into other applications. Once a SCIM connection is in place, your directory groups appear here and you can map each one to a **seat tier** (a named level of access that determines which Claude models and usage limits a user gets) and a **role** (which controls whether a user can access this admin portal).

<Note>
  The SCIM connection itself, including the base URL and secret token, is set up once for the whole tenant on the [tenant portal's Identity and access page](/docs/government/tenant-admin/identity-and-access). This page only covers the group mappings for your organization.
</Note>

## How provisioning works

Your identity provider pushes users and groups to Claude for Government whenever something changes in your directory, and most providers also run a full sync periodically (the default interval depends on your identity provider). Each push is written to a staging area first and then applied to your real user list by a reconciliation pass.

Reconciliation runs automatically whenever your identity provider pushes a change and also whenever you add, edit, or remove a mapping on this page. You do not need to trigger it manually, and you do not need to wait for a scheduled cycle after changing a mapping.

## Group to seat tier

To add a mapping, choose a group and a tier and click **Add**. Existing mappings are listed with a **Remove** button. Each group can be mapped to at most one tier, and you can only select tiers that are available to this organization (either an Anthropic-managed tier you have been allocated or a self-managed tier you created on the [Tiers](/docs/government/org-admin/seat-tiers) page).

<Note>
  The **Add** form only appears when at least one synced group is still unmapped. If no groups have appeared at all, assign groups to the Claude for Government application in your identity provider and run a provisioning sync first.
</Note>

## Group to role

The same mechanism can set a user's role. Map a directory group to **User** or **Owner**, and members of that group receive that role when they are provisioned. You cannot map a group to Primary Owner; that role must always be granted manually on the [Users](/docs/government/org-admin/users) page.

## How mappings are applied

When a provisioned user belongs to several mapped groups, the first matching tier mapping and the first matching role mapping in a fixed order win. This order is deterministic but not one you can configure, so it is best to avoid assigning a user to overlapping mapped groups.

A provisioned user who belongs to no mapped group is placed on a seat using the automatic assignment described on the [Seats](/docs/government/org-admin/seats) page and is given the standard **User** role.

If a mapped tier has no free seats when a user is provisioned, the user is created but left **Unassigned** and has no model access. They will be seated automatically on the next reconciliation after seats become available, for example after you increase the allocation on the [Billing](/docs/government/org-admin/billing) page or another user is deactivated.

Adding, changing, or removing a mapping triggers a full reconciliation immediately, so existing users are re-evaluated against the new mapping without waiting for your identity provider's next sync.

## Group to organization routing

> **For tenant administrators:** Mapping directory groups to organizations is handled on the [tenant portal's Identity and access page](/docs/government/tenant-admin/identity-and-access) rather than here.

## Things to know

* Provisioning is the source of truth while it is connected. A seat tier or role you set manually on the [Users](/docs/government/org-admin/users) page will be overwritten on the next reconciliation if the user's group mappings say otherwise. Make permanent changes in your directory instead.
* Deactivating a user in your directory deactivates them in Claude for Government and releases their seat. Reactivating them in the directory reactivates them here and attempts to seat them again.
* The reconciliation pass protects against removing your last administrator. It will not deactivate the organization's only active Primary Owner, and it will not deactivate the tenant's only tenant administrator, even if your directory says to.
* A group mapping cannot be saved if it points at a seat tier that no longer exists, and a seat tier cannot be deleted on the [Tiers](/docs/government/org-admin/seat-tiers) page while a mapping still points at it.

government/org-admin/readiness First recorded · 36 lines, first recorded

# Readiness ## How the checklist is presented ## What each check means ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Readiness

> Use this page to see everything that is stopping people in your organization from using Claude, and where each blocker is resolved.

> **Who this is for:** Organization owners who are setting up an organization for the first time, or who need to find out why their users are unable to use Claude.

Use this page to see everything that is stopping people in your organization from using Claude, and where each blocker is resolved.

Your organization is ready when a member can sign in, hold a seat on a tier that reaches a working model, and send a message that the organization can pay for. This page runs that check and lists each step that is complete, blocked, or waiting on someone else. You would normally work through it once when the organization is first set up and then return whenever the **Settings** menu shows a notification dot, which appears whenever anything on this page needs attention.

## How the checklist is presented

Each step sits on a vertical track with a status marker.

* A **green check** means the step is complete. The label is struck through and you can ignore it.
* A **filled circle** marks the step you should act on next. It expands to explain why it is blocked and offers an **Open** button that takes you to the page where the fix is made.
* A **clock** means the step is blocked but you are not the person who can clear it. A line underneath tells you whether it is waiting on Anthropic, on your tenant administrator, or on the owner of a shared billing account.
* A **hollow circle** is a step still to come. It stays collapsed until the steps ahead of it are cleared.

Use **Refresh** at the top right after you make a change elsewhere to see the updated state without leaving the page.

## What each check means

* **Activate the tenant** appears on its own if your agency's tenant is still being provisioned by Anthropic or has been deactivated. Nobody in any organization can sign in until this clears. Only Anthropic can resolve it, so contact your Anthropic representative.
* **Activate the organization** appears on its own if this organization has been deactivated. While it is inactive its members cannot sign in and none of the other checks can be cleared. Reactivation is handled by Anthropic. If the organization's billing account has also been retired, the page explains that it must be assigned a new account before it can be brought back.
* **Add credits** checks that the billing account your organization draws from has enough balance to cover at least one request on the cheapest model available to it. Until it does, every message from a user on a self-managed tier is refused. Credit is added to the billing account by Anthropic, so this step shows who to contact: your tenant administrator, or the owner of the organization that manages the shared billing account.
* **Raise the organization's spend cap** appears when a tenant administrator has set a spend cap on your organization that is lower than the cost of one request on the cheapest model available. Every request from a user on a self-managed tier is refused until the cap is raised or cleared. Only a tenant administrator can change caps, so this step shows **Waiting on your tenant admin**.
* **Allocate seats** checks that the organization has been allocated at least one seat of any tier. This is advisory. Without an allocation you can still assign tiers to people individually, but anyone who signs in before you do lands without a seat and cannot send messages. **Open Seats** or **Open Billing** takes you to the page where allocations are set, depending on how your billing account is managed. If the shared seat pool is already fully distributed, the step instead explains that the pool needs to be raised and shows who can do that.
* **Assign a model to your seat tier** checks that at least one seat tier in this organization can actually reach a working model, meaning a model that is enabled, priced, and allowed by a tier whose usage limits are high enough to cover a single request. If no tier qualifies, nobody can send a message regardless of credits or seats. **Open Tiers** takes you to the [Seat tiers](/docs/government/org-admin/seat-tiers) page to add a model or raise a tier's limits. If every tier available to you is Anthropic-managed, only Anthropic can change its model list, so the step shows a waiting state.
* **Enable a product** checks that at least one Claude product, such as Claude Desktop, Claude Code, or Claude for Microsoft 365, is enabled for this organization. This is advisory. With nothing enabled, direct API access still works, but no client application can start. Enable a product on the [Config](/docs/government/org-admin/configuration) page.

## Things to know

* Every **Open** button goes to the page where the fix belongs. You make the change there and return here to see it reflected.
* If a step you expect to clear yourself is shown as waiting on your tenant administrator, it usually means the resource it checks is managed at the tenant level. Your tenant administrator can clear it from the [tenant Readiness page](/docs/government/tenant-admin/readiness), which shows every organization's checklist in one place.
* Hover the help icon next to any step's label for a one-line explanation of what the check looks for.

government/org-admin/seat-tiers First recorded · 57 lines, first recorded

# Seat tiers ## The tier list ## Anthropic-managed versus self-managed tiers ## Creating a self-managed tier ## Viewing and editing a tier ## Deleting a tier ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Seat tiers

> Use this page to see the models and spend limits attached to each tier and, when permitted, to create and edit self-managed tiers.

> **Who this is for:** Organization owners who need to review the seat tiers available to their organization or define their own.

Use this page to see the models and spend limits attached to each tier and, when permitted, to create and edit self-managed tiers.

A **seat tier** bundles together which Claude models a user may access and how much they may spend in a given period. Every user sits on exactly one tier (or is unassigned), and the tier they hold controls their day-to-day limits. The **Tiers** page lists every tier available to your organization.

## The tier list

Tiers are listed with Anthropic-managed tiers first, followed by your organization's self-managed tiers. Each entry shows the tier's name, how many users are currently on it, and the seat limit if one applies. Clicking any tier opens its detail page.

## Anthropic-managed versus self-managed tiers

**Anthropic-managed tiers** are defined by Anthropic and allocated to you through your tenant's billing account. On the detail page you can see which models the tier allows, but the spend limits are not shown and you cannot change the tier's settings or delete it. These tiers are paid for as seats rather than through credit drawdown, so their per-user spend limits are an internal detail that Anthropic manages on your behalf.

**Self-managed tiers** are created by your organization. They draw from the billing account your organization spends from instead of a fixed seat count, and you have full control over their name, spend limits, and allowed models. A self-managed tier may or may not have a seat limit, depending on how it was allocated; when it has no limit, you can place as many users on it as you wish and the account's balance and any spend cap set on your organization are the effective constraint.

## Creating a self-managed tier

Click **New seat tier** and fill in the form.

* **Name** sets what the tier is called, for example *Analyst* or *Reviewer*. Names must be unique within your organization, and cannot duplicate the name of any Anthropic-managed tier.
* **Five-hour spend limit** sets the most each user on this tier can spend in any rolling 5-hour window, expressed in dollars. When a user reaches this amount, further requests are refused until the window rolls forward. Set it to zero to allow no usage at all.
* **Seven-day spend limit** does the same for a rolling 7-day window. Both limits apply at the same time, so whichever is reached first stops the user.
* **Allowed models** controls which Claude models users on this tier may use. If you leave it empty, users on the tier have no model access regardless of their spend limits.
* **Sort order** is a number that controls the order in which a seat is automatically chosen for a newly provisioned user (lowest number is tried first). If two tiers share the same sort order they are ordered consistently, but it is clearer to give each tier a distinct value.

An organization may create up to 50 self-managed tiers.

<Warning>
  The **New seat tier** button only appears if your tenant has allowed organizations to manage their own seat tiers. This permission is controlled by the **Let organizations manage their own seat tiers** setting on the tenant's Config page. If you don't see the button, ask a tenant administrator.
</Warning>

## Viewing and editing a tier

A tier's detail page shows its current values along with an **Allowed models** section that groups the permitted models by family.

<Note>
  The **Edit** form and **Delete** button only appear on self-managed tiers. For an Anthropic-managed tier the page is read-only.
</Note>

For a self-managed tier the **Edit** form lets you update any of the fields above. Changes take effect immediately for every user on the tier: if you lower the spend limit, a user who is already over the new limit will be blocked on their next request until their window rolls forward, and if you remove a model from the allowlist it becomes unavailable to every user on the tier straight away.

## Deleting a tier

The **Delete** button removes a self-managed tier entirely. Deletion is permanent and cannot be undone from this portal.

You can only delete a tier that nothing references. If any users are still assigned to it, any API keys are bound to it, or any group mapping on the [Group mappings](/docs/government/org-admin/provisioning) page points at it, the delete is refused with a message telling you so. Reassign or remove those references first, then delete the tier.

## Things to know

* Changing a tier's **Sort order** affects where newly provisioned users land, but it does not move anyone who already has a seat.
* The spend limits are per user, not per tier. Ten users on a tier with a \$20 seven-day limit can together spend up to \$200 from the billing account over seven days.
* Moving a user between tiers does not reset their usage counters. A user who has spent \$15 in the current 5-hour window carries that spend with them, and it is measured against the new tier's limit on their next request.

government/org-admin/seats First recorded · 49 lines, first recorded

# Seats ## What you see ## How seats are assigned automatically ## What you can do here ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Seats

> Use this page to check your organization's seat counts at a glance before assigning or reclaiming seats on the Users page.

> **Who this is for:** Organization owners who need to see how many seats of each tier are available and how many are in use.

Use this page to check your organization's seat counts at a glance before assigning or reclaiming seats on the Users page.

The **Seats** page shows how many seats your organization has for each seat tier and how many of them are currently assigned to users. It is the default landing page when you open the organization admin portal.

A **seat tier** is a named level of access that defines which Claude models a person can use and how much they can use them over a rolling time window. Every user in your organization occupies exactly one seat, and that seat belongs to a tier (or the user is **Unassigned**, in which case they have no model access at all).

## What you see

Seats are grouped into two sections based on who controls the tier.

<Note>
  Each section below only appears when your organization has at least one tier of that kind. If you have neither, the page shows a message explaining that seats are distributed by your tenant administrators.
</Note>

**Anthropic-managed tiers** are defined by Anthropic and allocated to your organization from your tenant's seat pool. For each one the table shows the **Assigned** count, which is how many of your users are on that tier, alongside the **Limit**, which is the number of seats your organization has been allocated. You cannot assign more users to a tier than its limit allows.

**Self-managed tiers** are tiers that your organization created itself on the [Tiers](/docs/government/org-admin/seat-tiers) page. For each one the table shows the **Assigned** count and, if a seat limit has been allocated for that tier, the **Limit**. These tiers draw from the billing account your organization spends from, so the effective constraint is usually the account's balance and any spend cap set on your organization rather than a seat count.

## How seats are assigned automatically

When a new user is created in your organization, whether they arrive through single sign-on or through directory provisioning, Claude for Government tries to place them on a seat tier automatically so they can start working right away.

If the user arrives through directory provisioning and belongs to a group you have mapped to a specific tier on the [Group mappings](/docs/government/org-admin/provisioning) page, that mapping takes precedence and the user is placed on the mapped tier if a seat is available.

Otherwise the system walks through all of your tiers, both Anthropic-managed and self-managed, in sort order (lowest first) and places the user on the first tier that has a free seat. Self-managed tiers may or may not have a seat limit, depending on how they were allocated. A user is left **Unassigned** only when every tier that has a seat allocation is full. An unassigned user has no model access until an owner assigns them a seat manually on the [Users](/docs/government/org-admin/users) page or until more seats become available.

<Tip>
  If you see an Anthropic-managed tier whose **Assigned** count equals its **Limit**, new users cannot land on it automatically. Either increase the allocation on the [Billing](/docs/government/org-admin/billing) page, move existing users to a different tier to free seats, or ask a tenant administrator to add seats.
</Tip>

## What you can do here

This page is read-only. To move a user onto a different tier, use the [Users](/docs/government/org-admin/users) page. To create or edit self-managed tiers, use the [Tiers](/docs/government/org-admin/seat-tiers) page.

<Tip>
  To change how many seats of an Anthropic-managed tier your organization holds, go to the [Billing](/docs/government/org-admin/billing) page if it is available to you, or ask a tenant administrator.
</Tip>

## Things to know

* The **Assigned** count includes only active users. When a user is deactivated, their seat is released immediately and becomes available for someone else.
* Changing a tier's limit on the Billing page does not move any users. If you lower a limit, you must first move enough users off the tier so the assigned count fits within the new limit, because the system will not let you reduce an allocation below the number of people currently seated on it.
* The sort order that controls automatic assignment is managed on the [Tiers](/docs/government/org-admin/seat-tiers) page. Anthropic-managed tiers have a fixed order set by Anthropic, and self-managed tiers sort wherever their sort order number places them relative to the managed ones.

government/org-admin/setup-wizard First recorded · 64 lines, first recorded

# Setup wizard ## How the wizard is laid out ## Step 1: Welcome ## Step 2: Seat tiers ## Step 3: Seats and credits ## Step 4: Products ## Step 5: Finish ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Setup wizard

> Walk through the steps that get your organization ready for users after a tenant administrator creates it.

> **Who this is for:** Organization owners setting up a newly created organization, or returning to finish setup later.

When a tenant administrator creates your organization and names you as its primary owner, a few things still need to be in place before your team can use Claude. The setup wizard walks you through those items in order, shows you which ones are already done, and tells you when something is waiting on someone else.

Until setup is complete, a banner reading **A few steps remain before your team can use Claude** appears at the top of every page in the organization admin portal. Click **Resume setup** in that banner to open the wizard. The banner goes away once everything is ready, and it reappears on its own if a required item later becomes incomplete, for example if the billing account's balance runs out or a spend cap is set too low.

You don't need to finish the wizard in one sitting. Use **Continue later** on any step to return to the admin portal, and come back through the banner whenever you are ready.

## How the wizard is laid out

The wizard is titled **Set up your organization** and lists five steps down the left side. Each step shows a green check once its requirement is met, and you can click any step to jump straight to it. The checks reflect the live state of your organization rather than whether you have visited the step, so a step can already be checked when you arrive and can lose its check if something changes later.

At the bottom of every step, **Continue later** exits to the admin portal and **Next** moves to the following step.

## Step 1: Welcome

The first step confirms which organization and tenant you are setting up and what your role is. It also explains the division of responsibility: single sign-on and provisioning are configured by your tenant administrator rather than here, so your members will appear in this organization automatically once they sign in through the tenant's identity provider. There is nothing to fill in on this step.

## Step 2: Seat tiers

A seat tier sets which Claude models a group of users can access and how much they can spend in a given period. This step lists every tier available to your organization. Anthropic-managed tiers are shown first and are labeled **Managed by Anthropic**, followed by any self-managed tiers your organization has defined. Each row shows the tier name and the number of allowed models, and self-managed tiers also show their five-hour and seven-day spend limits.

Click any tier to open it. An Anthropic-managed tier opens as a read-only summary, because its limits are set by Anthropic. A self-managed tier opens as an editable form where you can change the name, spend limits, and allowed models without leaving the wizard.

If your tenant lets organizations manage their own tiers, an **Add seat tier** button appears below the list so you can create one here. If that button is missing, your tenant has not turned on **Let organizations manage their own seat tiers**, and only Anthropic can create or change tiers for your organization.

The step is checked once at least one of your tiers has at least one model allowed. See [Seat tiers](/docs/government/org-admin/seat-tiers) for more on creating and editing tiers.

## Step 3: Seats and credits

This step shows whether your organization has the seats and credits it needs. Seats are allocated by your tenant administrator, and Anthropic adds credits to the billing account your organization draws from, so this step is a status display rather than a form. It is here so you can see at a glance whether you are still waiting on someone.

Two status lines are shown:

* **Add credits** is complete once the billing account your organization draws from has enough balance to serve at least one request. This is funded by Anthropic through your tenant administrator, so when it is incomplete the line shows **Waiting on your tenant admin**. Use **View billing** to open the [Billing](/docs/government/org-admin/billing) page and see the current balance and any spend caps set on your organization.
* **Allocate seats** is complete once your organization has been allocated at least one seat. Use **View seats** to open the [Seats](/docs/government/org-admin/seats) page and see the counts.

The step is checked only when both lines are complete. If either one is still waiting, contact a tenant administrator.

## Step 4: Products

These are the Claude products your members sign in to, such as Claude Desktop, Claude Code, and Claude for Microsoft 365. This step shows an on/off switch for each one. Turning a product on allows your members to sign in to that application.

This step is marked **Optional** in the step list, and you can leave every product off and still complete setup. A product that is not available appears with its switch disabled and a note to contact Anthropic if you would like it enabled.

You can change these switches later from the [Config](/docs/government/org-admin/configuration) page.

## Step 5: Finish

The final step shows the full readiness checklist for your organization so you can confirm everything is in place. Completed items are crossed out, and any item that is still outstanding shows the reason and who it is waiting on.

If anything required is still incomplete, a warning banner appears at the top of this step and the primary button reads **Continue later**. Back in the admin portal the **Resume setup** banner will stay in place until the outstanding items are resolved.

Once every required item is complete, the warning goes away, the primary button changes to **Go to the Admin Console**, and your users can sign in and start using Claude.

## Things to know

* The wizard makes the same changes as the matching pages in the admin portal. Creating a seat tier here is exactly the same as creating one on the Tiers page.
* Checks in the step list are derived from your organization's current state, so they update whenever that state changes, even outside the wizard.
* Once setup is complete the subtitle changes to **Setup complete. Revisit any step to make changes**, and you can return at any time to review or adjust what you set.

government/org-admin/users First recorded · 84 lines, first recorded

# Users ## Finding users ## What's shown for each user ## Understanding roles ## Changing a user's role ## Assigning a seat tier ## Resetting a user's limits ## Deactivated users ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Users

> Use this page to find a user, change their role or seat tier, check how close they are to their usage limits, and reset those limits when needed.

> **Who this is for:** Organization owners who need to manage individual users' roles, seat tiers, and usage limits.

Use this page to find a user, change their role or seat tier, check how close they are to their usage limits, and reset those limits when needed.

The **Users** page lists everyone in your organization and lets you manage their access.

## Finding users

Type into the search box to filter the list by name or email address. Use **Filters** to include deactivated accounts.

## What's shown for each user

Each user appears as a card with their name, email address, and the following fields:

| Field          | Description                                                                                                                                                                                                                                         |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Role**       | The user's role in this organization. You can change it directly from the dropdown.                                                                                                                                                                 |
| **Seat tier**  | Which seat tier the user currently occupies. You can change it directly from the dropdown.                                                                                                                                                          |
| **Usage**      | Two bars showing how much of the user's 5-hour and 7-day spend limits are currently used, with the exact percentage alongside each. Hover over the bars to see when each limit resets. Users who have no seat tier show a dash instead of the bars. |
| **Last login** | The date and time the user last signed in.                                                                                                                                                                                                          |

The **…** menu on each card has the **Reset usage limits** action, which clears the user's current rate-limit windows. The menu appears only when your organization has at least one [self-managed seat tier](/docs/government/org-admin/seat-tiers).

## Understanding roles

A **role** controls what a person can do in the admin portal. It has no effect on which Claude models they can use or how much they can use them; those are controlled by the seat tier.

* A **User** can use the Claude products but has no admin access.
* An **Owner** can access this organization admin portal and perform every action described in this guide except for granting or removing the Primary Owner role.
* A **Primary Owner** has the same access as an Owner and is additionally protected so that an organization can never be left without one. Only a Primary Owner can promote another user to Primary Owner or demote an existing one.

An organization must always have at least one active Primary Owner and may have up to three. Keeping more than one is recommended so that you are never locked out if a single Primary Owner is unavailable.

## Changing a user's role

Use the **Role** dropdown on a user's row to move them between User, Owner, and Primary Owner. The change applies immediately, and a user who is promoted to Owner can open the admin portal as soon as they refresh.

The following safeguards apply and the dropdown will refuse the change if any of them would be violated.

* You cannot change your own role. To be promoted or demoted, ask another Owner or Primary Owner to make the change for you.
* Only a Primary Owner can grant or remove the Primary Owner role. An Owner can freely move people between User and Owner, but any change that crosses into or out of Primary Owner must be made by a Primary Owner.
* You cannot demote the organization's only active Primary Owner. Promote a second person to Primary Owner first, then demote the original.
* You cannot promote a deactivated user to Primary Owner. Reactivate them first.
* You cannot add a fourth Primary Owner. Demote one of the existing Primary Owners first if you need to make room.

<Warning>
  If your organization uses directory provisioning with a group-to-role mapping, be aware that the next sync will re-apply the mapped role and may overwrite a manual change you make here. To make a permanent role change for a provisioned user, update their group membership in your identity provider instead.
</Warning>

## Assigning a seat tier

Use the **Seat tier** dropdown to move a user onto a different tier or back to **Unassigned**. An unassigned user has no model access at all, which is the appropriate state for someone who should keep their account but should not consume any Claude usage.

The dropdown lists Anthropic-managed tiers first, each labeled *Managed by Anthropic*, followed by your self-managed tiers with a short summary of their model count and spend caps. If a tier has no seats remaining it appears marked **(at capacity)** and cannot be selected, unless the user is already on it.

Changing a user's tier takes effect on their very next request. If you move someone to a tier with a different set of allowed models, any model that is no longer in their tier's allowlist becomes unavailable to them immediately.

<Warning>
  If your organization uses directory provisioning with a group-to-tier mapping, the next sync will re-apply the mapped tier. For provisioned users, adjust their directory group membership rather than changing the tier here.
</Warning>

## Resetting a user's limits

Every seat tier sets a rolling **5-hour** and **7-day** spend limit for each user. When a user reaches either limit, further requests are refused until the window rolls forward.

If a user on a self-managed tier has hit a limit and you want them to continue working immediately, use **Reset usage limits** in the **…** menu on their card. This clears both of their current windows so their next request is admitted. The reset does not refund or alter any credits that have already been consumed, and it does not change anything shown on the [Analytics](/docs/government/org-admin/analytics) page; it only clears the per-user counter that enforces the limit.

<Warning>
  The reset button is disabled for users on Anthropic-managed tiers because those limits are set by Anthropic and are not yours to waive. Additionally, if a user moved off an Anthropic-managed tier within the last seven days, the reset button is temporarily unavailable for them and the tooltip tells you when it becomes available again.
</Warning>

## Deactivated users

Accounts are deactivated through your directory's SCIM provisioning rather than from this page. A deactivated user cannot sign in and does not occupy a seat. Deactivating a user releases their seat immediately, and reactivating them later will attempt to place them back on a seat using the same automatic assignment logic described on the [Seats](/docs/government/org-admin/seats) page.

Deactivated users keep their role, but a deactivated Primary Owner does not count toward the "at least one" rule or the limit of three. You must always have at least one *active* Primary Owner.

## Things to know

* Claude for Government has exactly three organization roles: **User**, **Owner**, and **Primary Owner**. There are no additional roles such as Billing or Developer. Tenant administrator access is a separate tenant-level membership managed on the [Admins](/docs/government/tenant-admin/admins) page, not an organization role.

government/overview First recorded · 90 lines, first recorded

# Claude for Government administrator guide ## How your deployment is organized ### Tenant ### Organizations ### Users ## Billing accounts ## The three views ### A note on tenant administrators ## How people get access ## Where to go next

The first capture of this source. The page was already there, and this is what it said.

# Claude for Government administrator guide

> Set up and manage Claude for Government for your agency: how tenants, organizations, users, seats, and credits fit together.

> **Who this guide is for:** Administrators who set up and manage Claude for Government for their agency.

> **Find your section:**
>
> | If you are…                 | Start with                                                    |
> | --------------------------- | ------------------------------------------------------------- |
> | A tenant administrator      | [Tenant administration](/docs/government/tenant-admin/overview)    |
> | An organization owner       | [Organization administration](/docs/government/org-admin/overview) |
> | Any user                    | [Your account](/docs/government/account/overview)                  |
> | Anyone using Claude Desktop | [Use Claude Desktop](/docs/government/desktop/plugins)             |

This guide covers the portals used to manage Claude for Government: how access, seats, and usage are organized, and who is responsible for each part.

If you just want to use Claude for Government, you don't need this guide. You can simply sign in and start a conversation, and come back here when you need to manage other people's access or understand why something is configured the way it is.

## How your deployment is organized

Claude for Government is organized as a three-level hierarchy:

**Tenant** → **Organizations** → **Users**

### Tenant

The tenant is the top level, and it represents your agency's overall deployment. There is exactly one tenant per agency, and it holds the things that are shared across everyone: your connection to your identity provider for single sign-on, automatic user provisioning (where your directory system creates and updates accounts for you), the list of verified email domains, and the pool of credits and seats issued to you by Anthropic.

The tenant is managed by a short list of **tenant administrators**. They create organizations, decide how seats are divided among them and what spend caps are set, and set policies that apply across the whole agency.

### Organizations

An organization is a group of users who share a pool of seats and a set of policies, with its own spend caps. You might create one organization for each bureau, office, or program, or you might run the whole agency as a single organization.

Most agencies start with a single organization. You would create more when you need any of the following:

* Separate billing accounts so one group's usage never draws down another group's balance.
* Separate usage reporting for each bureau or program.
* Different product settings, seat tiers, or access rules for different parts of your agency.

Each organization has its own owners, its own members, its own seat assignments, and its own configuration. The organizations all share the tenant's single sign-on connection, so you configure identity once and every organization uses it.

### Users

A user is a single person. Every user belongs to exactly one organization, and two properties control what they can do:

* A user's **role** determines what they can manage. Most people have the **User** role, which means they use Claude but don't administer anything. **Owners** and **Primary Owners** manage the organization: they manage members' roles and seats, and adjust organization-level settings.
* A user's **seat tier** determines how much they can use Claude. A seat tier is a named bundle of usage limits (for example, how much Claude usage a person gets in a given period). A user with no seat assigned can sign in and see their account, but they can't send messages until an owner assigns them a seat.

A user never belongs to more than one organization at a time. Moving a person between organizations keeps the same account; their role and seat assignment are managed separately in the new organization.

## Billing accounts

A **billing account** is where your agency's credits and seats live. Anthropic sets up one or more billing accounts with your agency, and each one holds a prepaid credit balance (a dollar amount that is drawn down as people use Claude) and a pool of seats (a fixed number of seats in each tier).

Every organization is linked to exactly one billing account, and usage by that organization draws directly from the account's balance. Several organizations can share the same billing account, or each organization can have its own. Tenant administrators divide each billing account's seat pool among the organizations it funds, and can set per-organization spend caps to control how much any one organization draws from a shared balance.

## The three views

The portal has three views. Which ones you can reach depends on your role, and you switch between them using the link in the page footer.

| View                                                     | Who has it                                    | What it's for                                                                                                                                                                                       |
| -------------------------------------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [**Tenant**](/docs/government/tenant-admin/overview)          | Tenant administrators                         | Creating organizations, configuring identity and access (single sign-on, provisioning, and routing rules), distributing seats, setting spend caps, and managing who else is a tenant administrator. |
| [**Organization admin**](/docs/government/org-admin/overview) | Organization owners and tenant administrators | Managing users and seats, setting usage tiers, viewing analytics, and configuring organization-level settings.                                                                                      |
| [**Account**](/docs/government/account/overview)              | Everyone                                      | Viewing your own profile, checking your usage limits, and managing where you're signed in.                                                                                                          |

When you sign in, you land on the most relevant view for you. Organization owners land on the organization admin view, and everyone else lands on their account view. This includes tenant administrators who are not also an organization owner; they start on their account view and can use the **Switch to admin view** link in the page footer, and from there switch to the tenant view.

### A note on tenant administrators

Being a tenant administrator is separate from the role you hold inside an organization. Roles (User, Owner, and Primary Owner) control what you can do within a single organization, while tenant administrator status is granted by adding someone to the tenant's **Admins** list and controls access to the settings that sit above every organization. The two are independent: an organization owner is not automatically a tenant administrator, and a tenant administrator does not automatically hold any particular role inside any organization.

> **For tenant administrators:** Because the tenant sits above every organization, you can also open the organization admin view and act on behalf of any organization in the tenant, even ones you don't belong to. When the tenant has more than one organization, an organization switcher appears at the top of the admin view so you can choose which one you're managing.

## How people get access

Users reach your deployment in one of two ways, both of which are configured by a tenant administrator on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page:

* **Single sign-on.** The user enters their agency email address and is redirected to your identity provider (for example, Microsoft Entra, Okta, or ADFS). When they return authenticated, Claude for Government evaluates your tenant's routing rules to decide which organization they belong in.
* **Directory provisioning.** If your identity provider supports SCIM, which is a standard way for directory systems to keep accounts in sync with other applications, you can connect it so that your directory pushes users and group memberships to Claude for Government automatically. Routing rules then place each provisioned user in an organization based on their group membership.

Routing rules are the only way in. A new person who does not match any rule cannot sign in until a rule is added that covers them. Routing rules are also re-evaluated each time an existing member signs in, so a rule change can move someone to a different organization the next time they sign in.

## Where to go next

* Read [**Tenant administration**](/docs/government/tenant-admin/overview) if you're a tenant administrator managing the overall deployment.
* Read [**Organization administration**](/docs/government/org-admin/overview) if you're an owner managing a single organization.
* Read [**Your account**](/docs/government/account/overview) if you want to understand your own profile, usage, and sessions.

government/security/security-and-data-handling First recorded · 187 lines, first recorded

# Security and data handling ## Claude Desktop ### Sandbox and isolation ### Code in Claude Desktop ### Network egress, required domains, and proxies ### Approvals and Auto mode ### Connectors ### Telemetry and logging ### Data storage and retention ### Web search and web fetch ### Chat and Cowork differences ## More information

The first capture of this source. The page was already there, and this is what it said.

# Security and data handling

> Answers for agency security review: sandbox isolation, network egress and required domains, approvals, connector credentials, telemetry, and where data is stored.

> **Who this is for:** Security, compliance, and IT reviewers who are assessing Claude for Government for their agency, and administrators who need to explain the product's runtime behavior.

The answers on this page cover the Claude Desktop application in Claude for Government and address the security and data-handling questions that come up most often during agency security review. Claude Desktop offers three ways to work with Claude: **Chat** for simple conversations, **Cowork** for longer tasks with a local workspace folder, and **Code** for software development. Each answer states what is specific to Claude for Government (the FedRAMP High boundary, the defaults Anthropic applies for government tenants, and the relevant admin portal control), then links to the Claude Desktop documentation for the underlying mechanism. For assurance materials such as the security architecture overview, SOC 2 report, and penetration testing summary, request access through the [Anthropic Trust Center](https://trust.anthropic.com).

## Claude Desktop

The sections below cover the Claude Desktop application. For the admin portal and the Compliance API, see the [Organization administration](/docs/government/org-admin/overview) and [Tenant administration](/docs/government/tenant-admin/overview) sections.

### Sandbox and isolation

In Cowork, and for the file-analysis steps in Chat, the Claude Desktop application runs shell commands and model-written code inside a dedicated local virtual machine. In Claude for Government, this sandbox is always the execution path for the code and shell commands that Claude runs in Chat and Cowork. Code sessions run on the workstation itself rather than in the virtual machine, as described under [Code in Claude Desktop](#code-in-claude-desktop). For the detailed threat model and isolation design, request the security architecture overview through the [Anthropic Trust Center](https://trust.anthropic.com).

<AccordionGroup>
  <Accordion title="What does the sandbox isolate, and what runs outside it?">
    The sandbox virtual machine runs the shell commands and model-written code of Cowork sessions and of the file-analysis steps in Chat. The agent loop, built-in file tools, web fetch, and the connector client run in the Claude Desktop application on the user's device and are governed by separate controls: per-action approval prompts, administrator-set per-tool policies, and the network egress allowlist applied when each tool runs. Code sessions also run outside the virtual machine, as described under [Code in Claude Desktop](#code-in-claude-desktop). For a deeper description of the layered controls inside and outside the virtual machine, see the security architecture overview available through the [Anthropic Trust Center](https://trust.anthropic.com).
  </Accordion>

  <Accordion title="What can the sandbox reach on the host?">
    The sandbox sees the workspace folders the user has attached to the session, its own scratch area, and read-only reference material bundled by the application (such as skill and plugin directories). It does not see the rest of the user's filesystem. File-read and file-write tools default to those same attached folders, and prompt the user before reading or writing outside them; see [Approvals and Auto mode](#approvals-and-auto-mode). Administrators can restrict which local folders users may attach with **Allowed workspace folders** on the [Config](/docs/government/config/settings#allowed-workspace-folders) page; the desktop client then refuses folders outside that list in both the workspace picker and Claude's file tools. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access) for how folder scoping is enforced.
  </Accordion>

  <Accordion title="How are attached folders made available to the sandbox?">
    When a user attaches a local folder to a Cowork session, the entire folder is made available to that session's sandbox as a filesystem mount, so changes Claude makes are written directly to the folder on disk. A mapped network drive on Windows is an exception: Claude's host-side file tools can read, write, and search it, but shell commands in the sandbox cannot reach network shares, so a task that runs a script or build against those files must copy them to a local folder first (see [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access#network-drives-on-windows)). Files the user attaches individually to a conversation are copied or hard-linked into a per-conversation uploads directory and mounted read-only; where the filesystem hard-links, edits to the original file while the conversation is open can be visible to it. The allowed-folders setting is a policy control enforced by the desktop application. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access).
  </Accordion>

  <Accordion title="Which file types need the sandbox in Chat?">
    Some attachment types, such as Excel and PowerPoint, need a conversion step that runs inside the sandbox. Enabling **Advanced file analysis in Chat** under **Product availability** on the [Config](/docs/government/config/settings#product-availability) page lets Claude run code against attachments in an offline sandbox, including that conversion. You do not need to make Cowork available to get this capability. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat) for how Chat handles file attachments.
  </Accordion>
</AccordionGroup>

### Code in Claude Desktop

Code sessions use Claude Code built into the desktop application and run on the user's workstation itself, not in the virtual machine. The shell commands Claude runs during a Code session execute on the workstation's own operating system under the user's own account.

On macOS, those shell commands run inside an operating-system-level sandbox that the application builds from your organization's **Allowed network hosts** and **Allowed workspace folders** settings on the [Config](/docs/government/config/settings#allowed-network-hosts) page. The sandbox is in place whenever either setting restricts access, which the default configuration does. A user can exempt specific commands from this sandbox in a Claude Code settings file, and an exempted command runs outside the sandbox under the permission mode the user selects for the session.

On Windows, there is no operating-system-level sandbox for Code sessions. Shell commands run directly on the device under the permission mode the user selects for the session and under your agency's own endpoint and network controls. The **Allowed network hosts** and **Allowed workspace folders** settings do not confine what those commands can reach or change.

On both operating systems, the application starts a Code session only in a folder that **Allowed workspace folders** permits when that setting is configured. Administrators can also require a prompt on every shell command, in every permission mode, with the **Require approval for each command** sub-setting on the **Shell commands** card of the [Config](/docs/government/config/settings#tool-and-connector-cards) page.

Code sessions in Claude for Government run on the local workstation only, and the environment options for Windows Subsystem for Linux (WSL) and SSH remote hosts are not available. Commands that belong to Claude Code's terminal interface, such as `/sandbox`, are not part of Code sessions in the desktop application. See [how your configuration reaches Code sessions](/docs/third-party/claude-desktop/code). If your agency also deploys Claude Code's own managed settings to the same devices, those settings take precedence over the macOS sandbox policy described above unless they opt in to merging, as that page explains.

### Network egress, required domains, and proxies

The desktop application and the sandbox honor the operating system's proxy settings, and a single allowlist controls outbound network access from Claude's tools. You manage the allowlist with the **Allowed network hosts** setting on the [Config](/docs/government/config/settings#allowed-network-hosts) page.

<AccordionGroup>
  <Accordion title="What does the egress allowlist control?">
    The allowlist governs outbound network access from the shell commands and package installs of Cowork sessions, which run in the sandbox virtual machine, from the sandboxed shell commands of Code sessions on macOS (see [Code in Claude Desktop](#code-in-claude-desktop)), and from the host-side web fetch tool. It does not govern web search (which routes through the Claude for Government service) or connector traffic (covered under [Connectors](#connectors) below). When the list is empty or unset, the only hosts reachable from those tools are the Claude for Government service address and, if you have set a **Telemetry endpoint (Claude Desktop)** on the [Config](/docs/government/config/settings#telemetry-endpoint-claude-desktop) page, that collector's host, which the application adds to the allowlist automatically. Package installs and page fetches to any other host fail. The list accepts exact hostnames, wildcard patterns such as `*.example.com`, or `*` to allow all outbound traffic. See [Web search and web fetch](/docs/third-party/claude-desktop/web-tools) for the full allowlist semantics.
  </Accordion>

  <Accordion title="Which domains does Claude Desktop need to reach?">
    For configuration and model inference, the application reaches the Claude for Government service hostname provided to your agency during onboarding. Sign-in happens in the user's default browser, which must reach that same hostname, the Claude for Government sign-in service (a separate host that your Anthropic representative provides), and your agency's identity provider; see the network prerequisites in [Connect Claude Desktop to Claude for Government](/docs/government/deploy-desktop/configure#before-you-begin). Anthropic-bound telemetry endpoints are not contacted in Claude for Government. Allow `downloads.claude.ai` for the sandbox virtual machine image and the Claude Code command-line tool, which are fetched at session start (not required if your agency uses the offline installer variant that bundles both), and `www.claudeusercontent.com` for the artifact preview frame. For automatic application updates, the required hosts depend on how your agency distributes the client; see the network-requirements table in [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) and confirm the update hosts for your deployment before finalizing your allowlist.
  </Accordion>

  <Accordion title="Does Claude for Government depend on claude.ai or anthropic.com?">
    The core product does not. Configuration and model inference go through the dedicated Claude for Government service hostname, and sign-in goes through that hostname, the separate Claude for Government sign-in service, and your agency's identity provider, none of which are under either domain. Blocking `*.claude.ai` and `*.anthropic.com` leaves sign-in and inference working. Blocking `*.claude.ai` also blocks `downloads.claude.ai`, which prevents Cowork and Code sessions from starting and Advanced file analysis in Chat from running, unless the offline installer variant was used.
  </Accordion>

  <Accordion title="Does blocking claude.ai affect Claude for Government?">
    Blocking `claude.ai` does not affect sign-in or inference; neither uses any host under that domain. A personal Claude account cannot sign in to Claude for Government, and a Claude for Government account cannot sign in to `claude.ai`, so there is no shared sign-in surface to restrict. If you allow automatic application updates, keep the update hosts listed in the network-requirements table reachable.
  </Accordion>

  <Accordion title="Is web fetch always checked against the allowlist?">
    Yes. Every web page fetch is checked against your egress allowlist before the request is made, and redirects are re-checked against the allowlist on each hop. See [Web search and web fetch](/docs/third-party/claude-desktop/web-tools). Do not rely on this allowlist alone to restrict access to your private network; see **Allowed network hosts** on the [Config](/docs/government/config/settings#allowed-network-hosts) page.
  </Accordion>

  <Accordion title="Can all traffic route through a single proxy?">
    Yes. Both the desktop application and the sandbox honor the operating system's proxy settings, including PAC URLs, and route all outbound traffic through your proxy. TLS inspection at your proxy should work; validate this in your environment before rollout. See [Proxy support](/docs/third-party/claude-desktop/telemetry#proxy-support) for details. Web search requests pass through your proxy to the Claude for Government service, and the service's onward call to the search provider originates from inside the FedRAMP High boundary.
  </Accordion>
</AccordionGroup>

### Approvals and Auto mode

By default, Claude for Government prompts the user for file writes outside the attached workspace, connector actions, and each web search. In Cowork, shell commands run without a prompt because they run inside the sandbox virtual machine. Web page fetches run without a prompt in both Chat and Cowork and are checked against the egress allowlist described above. Administrators can require a prompt on every shell command or fetch with the **Require approval** sub-settings on the [Config](/docs/government/config/settings#tool-and-connector-cards) page. In Chat, every shell command prompts regardless. The reduced-approval option in Claude for Government is Auto mode, which is off by default and can be enabled through device managed configuration (it is not a setting on the Config page). Cowork does not offer a Bypass Permissions mode.

<AccordionGroup>
  <Accordion title="Can write and send actions be gated behind approval?">
    Yes. Administrators can set each built-in and connector tool to **ask** (approval required on every call), **allow** (pre-approved), or **blocked** (removed entirely), and users cannot override those settings. For the Microsoft 365 connector, certain irreversible write tools (sending or forwarding mail, and creating or updating calendar events) are fixed to **ask** and cannot be changed to **allow**. See the [Configuration reference](/docs/third-party/claude-desktop/configuration) for the per-tool policy options.
  </Accordion>

  <Accordion title="Can Auto mode be disabled when a sensitive connector is attached?">
    Auto mode can be disabled by policy, but not conditionally based on which connector is attached. The Auto mode policy, delivered through device managed configuration, controls whether users see Auto mode in the Cowork and Code permission selectors, and it defaults to off in Claude for Government. You can combine that policy with per-tool policies (setting a sensitive connector's tools to **ask** or **blocked**) to achieve a similar effect.
  </Accordion>

  <Accordion title="Can individual shell commands be allowlisted enterprise-wide?">
    No. Policy controls whole tools (shell, file read, web fetch, and so on) but not individual commands within a tool. In Chat, each shell command prompts the user with no standing approval. For analyses that take many steps, Cowork runs shell commands in the sandbox without prompting; you make Cowork available to members under **Product availability** on the [Config](/docs/government/config/settings#product-availability) page.
  </Accordion>

  <Accordion title="Can users suppress approval prompts with an Always allow choice?">
    For most tools, users who see an approval prompt can choose **Always allow**, which suppresses that prompt for them going forward. Administrators can remove that option by setting the tool's policy to **ask**, which forces a fresh prompt on every call. The create-artifact prompt and code execution in Chat are exceptions: neither offers a standing approval. See the [Configuration reference](/docs/third-party/claude-desktop/configuration) for the full tool-policy options.
  </Accordion>

  <Accordion title="Why does Chat prompt on every analysis step?">
    Chat is designed for user-guided interaction, so each analysis step (including opening an attachment in the sandbox) runs as a shell command with a one-time Allow or Deny prompt and no standing approval. For analyses that take many steps, Cowork runs the same work in the same sandbox without a prompt on each shell command. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat).
  </Accordion>
</AccordionGroup>

### Connectors

In Claude for Government, connectors fall into three main categories: built-in tools (Web search, Web fetch, and Shell commands), the built-in Microsoft 365 connector, and connectors an administrator adds on the Connectors card of the [Config](/docs/government/config/settings#tool-and-connector-cards) page.

<AccordionGroup>
  <Accordion title="Where do connectors run, and where are tokens stored?">
    Connectors are called from the desktop application, outside the sandbox. The built-in Microsoft 365 connector and administrator-added connectors call their endpoints directly from the user's device, through the system proxy where one is configured. OAuth tokens for both are stored encrypted on each user's device using operating system encryption (macOS Keychain on Mac, DPAPI on Windows). For administrator-added connectors, the bearer header entered on the Config page is delivered to each user's desktop. A plugin package can include skills, slash commands, sub-agents, and hooks, which run on the member's machine. The Config page asks the administrator to confirm trust before adding a plugin that declares components that can run code on the member's machine, for example hooks or an MCP server. A plugin's declared local MCP server is disabled in Claude for Government and does not run, and a connector declared inside a plugin package does not become available as an organization connector unless the plugin was delivered through device management. End users cannot add their own connectors. End users can upload their own plugin files in Claude Desktop; a user-uploaded plugin's skills, commands, sub-agents, and hooks run on that user's machine, and any connector it declares does not become available as an organization connector. Administrators distribute plugins to members on the Config page with a per-plugin choice of automatic installation or member opt-in. See [Connectors](/docs/government/connectors/overview) and the Plugins card under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards).
  </Accordion>

  <Accordion title="Do connectors follow the sandbox egress allowlist?">
    No. The built-in Microsoft 365 connector calls Microsoft Graph directly from the user's device; see the [Microsoft 365 connector](/docs/government/connectors/microsoft-365) page. Administrator-added connectors connect directly from the user's device to the address configured for that connector. Both pass through the system proxy where one is configured. Web search is a built-in tool rather than a connector and routes through the Claude for Government service; see [Web search and web fetch](#web-search-and-web-fetch) below.
  </Accordion>

  <Accordion title="Can artifacts be blocked from calling connectors?">
    Artifacts honor the same per-tool approval policy as Claude's direct connector calls: tools set to **blocked** are refused and tools set to **ask** require user confirmation. There is no single switch to disable artifact-to-connector calls while keeping connectors available to Claude directly.
  </Accordion>
</AccordionGroup>

### Telemetry and logging

In Claude for Government, Anthropic-bound error and usage telemetry is always disabled. The OpenTelemetry export to your own collector is a separate setting and sends data only to the endpoint you configure.

<AccordionGroup>
  <Accordion title="Is there an inline DLP or inspection point?">
    No. Claude for Government does not include an inline content-inspection or DLP gate. The available inspection points are your own network proxy, which sees all endpoint traffic, and the desktop's OpenTelemetry export, which sends tool-call metadata (tool name, connector, outcome, duration, and approval status) to your collector for after-the-fact review. You set the OpenTelemetry endpoint with **Telemetry endpoint (Claude Desktop)** on the [Config](/docs/government/config/settings#telemetry-endpoint-claude-desktop) page. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry).
  </Accordion>

  <Accordion title="What is logged for connector actions and outbound requests?">
    Chat, Cowork, and Code sessions write a local audit log to the user's disk recording tool invocations, permission decisions, and file operations; that log never leaves the device. The desktop can also export OpenTelemetry events to a collector you specify: tool name, connector, outcome, duration, and approval status are sent. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for what the export can include. Server-side, the [Compliance API](/docs/government/org-admin/compliance-api) records identity and configuration events but never tool calls or conversation content.
  </Accordion>
</AccordionGroup>

### Data storage and retention

In Claude for Government, conversation content stays on the user's device. Model requests are proxied through the Claude for Government service to the model endpoint inside the FedRAMP High boundary, and the service records only per-request metadata, not content.

<AccordionGroup>
  <Accordion title="Can Anthropic view conversations?">
    No. Chat transcripts are stored only on the user's workstation, and the Claude for Government service does not log request or response bodies. Inference requests pass through the service to the model endpoint but are not retained. See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for where conversation content is stored.
  </Accordion>

  <Accordion title="Where on the device is conversation content stored?">
    Conversation content lives under the owner-only application data directory (`%LOCALAPPDATA%\Claude-3p` on Windows, `~/Library/Application Support/Claude-3p` on macOS). User-visible outputs such as artifacts are written separately to the user files directory (default `~/Claude`). See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for the full list of what each location holds.
  </Accordion>

  <Accordion title="Where are files added to a project stored, and are they indexed?">
    A project in Claude for Government is stored in the application data directory on the user's own device, together with any instructions, links, and folder references the user adds to it. Files added to a project stay on the user's local disk; there is no service-side project store, and files are not vectorized or indexed. Claude reads them directly from disk on demand with its file tools. Content Claude reads from those files is handled like the rest of the conversation: inference requests pass through the Claude for Government service to the model endpoint but are not retained. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access).
  </Accordion>

  <Accordion title="Can the local data location be changed for backup or sync?">
    No. The location is fixed to the per-user application data directory, and the application avoids the roaming profile because the sandbox image cache can be large. Chat history exists only on the device that created it, so back up the application data directory through your endpoint management tools if you need to preserve it. Artifacts and project folders are separate locations on the same device; see the question above. See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for the folder layout.
  </Accordion>
</AccordionGroup>

### Web search and web fetch

<AccordionGroup>
  <Accordion title="How does web search reach the internet?">
    Web search is operated by Anthropic inside the Claude for Government FedRAMP High boundary, and the search provider's API is the one case where traffic egresses that boundary. Before search is enabled, an administrator must acknowledge a disclosure covering this data flow when enabling the **Web search** card on the [Config](/docs/government/config/settings#tool-and-connector-cards) page. By default, users approve each query before it is sent, and Claude transforms it into a generic, de-identified search request and shows the user the exact text. Anthropic has a zero-data-retention agreement with the search provider. The [Web search and web fetch](/docs/third-party/claude-desktop/web-tools) page covers how web search is configured in other Claude Desktop deployments; the Claude for Government search path described here is specific to this deployment.
  </Accordion>

  <Accordion title="How do administrators enable web search?">
    Web search is built in and does not require obtaining a separate connector. An organization owner opens the [Config](/docs/government/config/settings#tool-and-connector-cards) page, finds the **Web search** card, turns it on, and acknowledges the data-flow notice. The **Require approval for each search** setting is on by default.
  </Accordion>

  <Accordion title="Why does Chat's web fetch fail with an empty allowlist?">
    Chat includes a web fetch tool, and every fetch is checked against the same egress allowlist that governs Cowork. With the allowlist empty or unset, a fetch to anything other than the Claude for Government service address (or, when configured, the **Telemetry endpoint (Claude Desktop)** collector host) returns an error. Add hosts to **Allowed network hosts** on the [Config](/docs/government/config/settings#allowed-network-hosts) page to let Chat fetch from them, or turn off the **Web fetch** card on the same page if you prefer Claude not to see the tool. See [Web search and web fetch](/docs/third-party/claude-desktop/web-tools).
  </Accordion>
</AccordionGroup>

### Chat and Cowork differences

<AccordionGroup>
  <Accordion title="Are projects available in both Chat and Cowork?">
    Yes. Chat and Cowork share one list of projects, and users can start a Chat conversation or a Cowork session inside a project. A project in Claude for Government is stored only on the user's device. There is no service-side project store, and projects are not shared between users. A Chat conversation inside a project does not gain access to the project's folders, while Cowork sessions in a project use the same execution model as the rest of Cowork. Chat conversations in a project can read the project's [memory](/docs/third-party/claude-desktop/data-storage#memory) but cannot add to or change it. See [Data storage and retention](#data-storage-and-retention) for where project contents are stored.
  </Accordion>

  <Accordion title="Are artifacts available in Chat?">
    Yes. Artifacts are available in both Chat and Cowork. Claude creates an artifact by calling a tool when the output suits an interactive view, and the artifact opens in a side panel next to the conversation. Artifacts do not depend on the sandbox, so they remain available in Chat even when **Advanced file analysis** is disabled.
  </Accordion>
</AccordionGroup>

## More information

Assurance materials including the security architecture overview, SOC 2 Type 2 report, and penetration testing summary are available on request through the [Anthropic Trust Center](https://trust.anthropic.com).

government/tenant-admin/admins First recorded · 40 lines, first recorded

# Admins ## How tenant admin access works ## The admin list ## Adding a tenant administrator ## Removing a tenant administrator ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Admins

> Use this page to view, add, and remove the people who can use the tenant admin portal.

> **Who this is for:** Tenant administrators who manage who else has tenant-level administrative access.

Use this page to view, add, and remove the people who can use the tenant admin portal.

## How tenant admin access works

**Tenant administrator** is a specific membership list, separate from any role someone holds inside an organization. Being on this list grants access to every page in the tenant admin portal: creating organizations, configuring sign-in and provisioning, writing routing rules, distributing seats, setting spend caps, and setting tenant-wide configuration. It also lets the person open any organization's admin view and act on that organization's behalf.

Tenant admin membership is not tied to any organization role. Adding someone here doesn't make them an owner of any organization, and making someone an organization owner doesn't put them on this list.

> **For organization owners:** Being an organization's owner does not make you a tenant administrator, and being a tenant administrator doesn't grant any particular role inside an organization. The two are independent.

## The admin list

The table lists every current tenant administrator with their email and which organization they belong to. A tenant administrator doesn't have to belong to any organization; those rows show *No organization*. This is common for the initial administrator Anthropic sets up during onboarding.

## Adding a tenant administrator

In the **Add admin** section, start typing a name or email address and select the person from the results, then click **Grant admin**. The change takes effect immediately; the next time that person loads the portal, the tenant admin view is available to them.

The search covers organization owners across every organization in your tenant, plus any existing tenant staff who don't belong to an organization. The person must already exist in your tenant, meaning they have signed in at least once or have been provisioned through your directory.

## Removing a tenant administrator

Click **Remove** next to a name to revoke their tenant admin access. The change takes effect immediately. The person keeps their account and whatever organization role they have; only the ability to open this portal is removed.

<Warning>
  You can't remove the last remaining tenant administrator. The button is disabled when only one is left. This protects your tenant from losing all administrative access.
</Warning>

## Things to know

* Adding tenant administrators is self-service and does not require any action from Anthropic. See [Adding a tenant administrator](#adding-a-tenant-administrator) above.
* You cannot remove yourself from the list. If your own access needs to be removed, ask another tenant administrator to do it.
* There is no upper limit on the number of tenant administrators, but because the access is broad, keep the list as short as your operational needs allow.
* If the only person on this list leaves your agency or loses account access, contact Anthropic to have a new tenant administrator appointed.

government/tenant-admin/configuration First recorded · 21 lines, first recorded

# Config at the tenant level ## What is specific to the tenant level

The first capture of this source. The page was already there, and this is what it said.

# Config at the tenant level

> Set tenant-wide defaults for product behavior, lock settings so organizations can't change them, and preview how a change affects each organization.

> **Who this is for:** Tenant administrators who set and enforce product settings across every organization in their tenant.

Use this page to set tenant-wide defaults for product behavior, lock settings so organizations can't change them, and preview how a change would affect each organization.

The Config page works the same way at the tenant and organization levels, with the same list of settings. See [How Config works](/docs/government/config/overview) for the levels model, locks, groups, comparing across levels, and looking up one person's settings, and [Available settings](/docs/government/config/settings) for what each setting does. This page covers only what is specific to the tenant level.

## What is specific to the tenant level

**Previewing impact across organizations.** After you change a setting here, a **Preview impact** button appears next to **Save changes**. It shows every organization with its current effective value and what it would become after your change. See [Previewing impact](/docs/government/config/overview#previewing-impact). This button does not appear at the organization level.

**Two settings that only tenant administrators can change.** [Let organizations manage their own seat tiers](/docs/government/config/settings#let-organizations-manage-their-own-seat-tiers) and [Compliance API](/docs/government/config/settings#compliance-api) are always read-only for organization owners, regardless of whether they are locked.

**Group priority order.** You set the priority order between directory groups on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page by dragging the groups into the order you want. Organization owners see this order for reference but cannot change it. See [When someone belongs to more than one group](/docs/government/config/overview#when-someone-belongs-to-more-than-one-group).

**Managing any organization's config.** As a tenant administrator you can open any organization's Config page and act on that organization's behalf, using the scope bar above the settings list. Organization owners see only their own organization.

**Resetting a tenant setting** removes only the tenant's value. Organization values are unaffected and remain in effect once your value is gone.

government/tenant-admin/credits First recorded · 56 lines, first recorded

# Billing ## How billing works ## What the page shows ## Setting a spend cap ## When you can't set caps ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Billing

> Use this page to see each billing account's balance and to set per-organization spend caps.

> **Who this is for:** Tenant administrators who monitor billing-account balances and set spend caps on organizations.

Use this page to see each billing account's balance and to set spend caps that limit how much any one organization can draw from it.

<Note>
  The **Billing** tab appears in the navigation only when credits apply to your tenant, which means at least one organization can use credits or there is a credit balance on any billing account in your tenant. If neither is true, the tab is hidden and **Seats** appears on its own in the navigation. This page is still reachable from a direct link and shows a short explanation. The tab appears automatically once Anthropic configures billing for your tenant.
</Note>

## How billing works

A **billing account** is a funding pool that Anthropic sets up for your tenant. It holds a dollar balance of credit, and Anthropic adds credit to the account as part of your agency's procurement. Each organization is linked to exactly one billing account, and several organizations may share the same one.

Usage by any organization draws directly from its billing account's balance. Because organizations share the balance, one organization's usage can reduce what is available to the others on the same account. To control that, you can set a **spend cap** on each organization.

A spend cap limits how much one organization can spend from its billing account in a rolling window. It is a policy limit, not a transfer of money. Nothing moves when you set or change a cap, and the billing account's balance is always the ultimate limit regardless of what caps are set.

Spend caps apply to usage on self-managed seat tiers. Usage on Anthropic-managed seat tiers is covered by the seat price rather than drawn from the account balance, so it is not counted against a cap.

## What the page shows

<Note>
  Billing account cards only appear once Anthropic has set up at least one billing account for your tenant. Until then, the page shows a message asking you to contact Anthropic.
</Note>

Each billing account appears as its own card showing:

* The **available balance**, which is the credit remaining in the account. Every organization on the account draws from this one balance.
* How many organizations the account funds.
* A **Spend caps** section listing each organization on the account with its current caps.

If every organization on an account uses only Anthropic-managed seat tiers, a banner explains that the balance and spend caps do not limit usage right now. They take effect once an organization starts using self-managed tiers.

## Setting a spend cap

In a billing account's **Spend caps** section, click an organization's row to expand the editor, enter a dollar amount for the **5-hour cap**, the **7-day cap**, or both, and click **Save caps**.

* Leave a cap blank for no limit on that window. The billing account's balance is still the ultimate limit.
* Both caps apply at the same time. An organization's usage is refused once either cap is reached, until that window rolls forward.
* Amounts can be from \$0 to \$1,000,000,000, and you can use cents.
* A cap of \$0 pauses the organization. Requests billed to the account are refused until you raise or clear the cap.

Changes take effect immediately. Raising or clearing a cap admits the organization's next request. Lowering a cap below the organization's current window usage refuses its next request until the window rolls forward.

## When you can't set caps

If an account is **deactivated**, its organizations' requests are refused and you cannot edit caps. Contact Anthropic to move the organizations to an active account.

## Things to know

* Spend caps are set by tenant administrators. Organization owners can see their own caps on their organization's Billing page, but cannot change them.
* Adding credit to a billing account is arranged with Anthropic as part of your agency's procurement. There is no form on this page to add credit.
* An organization that hits a spend cap does not affect other organizations on the same account. An account running out of balance affects every organization on it.

government/tenant-admin/identity-and-access First recorded · 200 lines, first recorded

# Identity and access ## Status banners ## Domains ## Single sign-on ### Registering in your identity provider ### Connecting with OIDC ### Connecting with SAML ### Attribute mapping (advanced) ## SCIM provisioning ### SCIM secret token ## Directory groups ## Routing rules ### When rules move people ### Sign-in rules ### Provisioning rules (SCIM) ### Adding and removing rules ## Preview routing ## Unplaced users ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Identity and access

> Connect single sign-on, manage SCIM provisioning, and write the routing rules that place users into organizations.

> **Who this is for:** Tenant administrators who connect the deployment to their agency's identity provider and control which organization each person belongs to.

Use this page to connect single sign-on, manage the SCIM provisioning token, write the routing rules that place users into organizations, preview how a specific person would be routed, and review people who haven't been placed yet.

Identity and access are configured once here and shared by every organization in your tenant. The page is laid out top to bottom in the order you'll usually work through it: connect single sign-on, optionally connect directory provisioning, then write routing rules, then use the preview and the waiting lists to confirm everyone is being placed where you expect.

## Status banners

Three banners can appear at the top of the page:

* **Still being provisioned** appears while Anthropic is finishing initial setup of your tenant. Sign-in is disabled for everyone until provisioning completes, but you can configure everything on this page in the meantime so that it takes effect as soon as the tenant goes live.
* **No routing rules configured** appears when no routing rules exist. Until at least one rule is added, no new person can sign in.
* **Last SCIM push** shows when your directory most recently pushed an update. It appears only after your directory has completed at least one sync.

## Domains

Claude for Government routes users to your tenant by the domain of their email address, so at least one domain must be registered before anyone can sign in. The **Domains** section lists every domain registered to your tenant, along with whether it is verified and whether it was registered by Anthropic or by you.

Domains that Anthropic registered on your behalf during onboarding are already verified. To add one yourself, enter the domain in the **Claim a domain** field and click **Claim**. You will be shown a DNS TXT record to publish on that domain; once the record is live, click **Verify now** and the domain becomes active.

Until at least one domain is verified, the Single sign-on section's Connect button and the SCIM provisioning section's **Generate token** button are both unavailable, and each section shows a banner explaining why. Existing tenant administrators can still sign in by email link during this time.

## Single sign-on

Every user signs in through your agency's identity provider (for example, Microsoft Entra, Okta, or ADFS). You register Claude for Government as an application in your identity provider, then enter your provider's connection details here. Once connected, every sign-in is redirected to your provider.

<Note>
  You need at least one verified domain before you can connect single sign-on. Until then, the Connect button is unavailable and a banner prompts you to verify a domain first. If single sign-on was already connected before your last domain was removed, the existing connection stays editable.
</Note>

The card header shows a **Connected (OIDC)**, **Connected (SAML)**, or **Not configured** badge so you can see the current state at a glance. Only one protocol is active at a time. Use the **OIDC** and **SAML** tabs to switch between the two forms; saving one replaces the other.

### Registering in your identity provider

Copy the following values from the card into your identity provider when you create the application there:

* **Redirect URI / ACS URL** is where your identity provider sends the user back after authentication. The same value is used whether you choose OIDC (where it's called the Redirect URI) or SAML (where it's called the Assertion Consumer Service URL).
* **SP Entity ID / Audience** is the unique identifier your identity provider uses to recognize this application. Providers label this field differently; it may appear as Identifier, Entity ID, or Audience URI.

For SAML, a **More values your IdP may ask for** expander below these fields lists the remaining details some providers request: the Name ID format, whether assertions and requests are signed, and the default RelayState.

After you save a SAML connection, an **SP metadata URL** appears alongside these values. Most identity providers can import this address to fill in the other values automatically if you need to reconfigure.

### Connecting with OIDC

If your identity provider supports OpenID Connect, fill in the OIDC section:

* **Client ID** is the application ID your identity provider assigned when you registered the app.
* **Client secret** is the secret your identity provider generated for that application. It is stored securely and never shown again after you save.
* **Authorization URL**, **Token URL**, **Issuer**, and **JWKS URL** are your identity provider's OIDC endpoints. Most providers show these on the application's overview or endpoints page, and some providers publish all four together on an OpenID Connect discovery document.

### Connecting with SAML

If your identity provider uses SAML, fill in the SAML section instead:

* **IdP metadata XML** is the federation metadata document for your identity provider. Download the XML file from your provider (in Microsoft Entra it's under Single sign-on → SAML → Federation Metadata XML; in ADFS it's under Endpoints) and paste the full document into the field. The metadata is read from what you paste; it is never fetched from a URL.

Once SAML is active, the card shows the Entity ID and SSO URL extracted from your metadata so you can confirm the connection is pointing where you expect.

### Attribute mapping (advanced)

Both the OIDC and SAML sections include an **Attribute mapping** panel that's collapsed by default. Open it if the email, first-name, or last-name fields arrive under different names than the defaults. Each field offers a short list of common names for your chosen protocol; you can pick one or type your own. For OIDC the defaults are the standard `email`, `given_name`, and `family_name` claims; for SAML the defaults cover the common attribute names most providers use. Leave a field blank to use its default.

<Warning>
  Saving a new single sign-on configuration takes effect immediately and applies to everyone, including you. Before saving, confirm you can authenticate with the new provider in another browser window so that you don't lock yourself out.
</Warning>

## SCIM provisioning

SCIM is the standard protocol identity providers use to push users and groups to a connected service automatically, so that accounts are created, updated, and deactivated in step with your agency's directory. Connecting SCIM is optional; without it, users are created the first time they sign in.

<Note>
  You need at least one verified domain before you can generate a SCIM token. Until then, **Generate token** is unavailable and a banner prompts you to verify a domain first.
</Note>

* **SCIM base URL** is the address your identity provider pushes user and group updates to. A copy button sits next to it. You'll paste this value into your identity provider's provisioning settings (Okta and Microsoft Entra call this the *Tenant URL*).

### SCIM secret token

Your identity provider authenticates to the SCIM address with a bearer token that you generate here. Click **Generate token** to create one, then paste the value into your identity provider's *Secret Token* (or equivalent) field.

<Warning>
  The full token value is shown **only once**, immediately after you create it. Copy it into your identity provider before clicking Done. If you lose the value, generate a new token and revoke the old one.
</Warning>

The token table lists every token with its created date, a short hint (the last few characters) so you can tell them apart, and a status of **Active** or **Revoked**. You can keep more than one token active at a time, which lets you rotate without an outage: generate a new token, update your identity provider to use it, confirm a sync succeeds, and then revoke the old one. Revoking a token takes effect immediately.

Once a token is active and your directory completes its first sync, the provisioning-rule list and the **Synced, not routed** waiting list become available further down the page.

## Directory groups

Once your identity provider has pushed groups over SCIM, they appear here with their member counts. Drag the groups into the order you want; this priority is used for group-level configuration on the [Config](/docs/government/config/overview#group-specific-settings) page.

## Routing rules

A **routing rule** is an instruction of the form "if a person matches this condition, place them in this organization." Routing rules are the **only** way a new person gets into your deployment; there is no default organization and no fallback.

Before any rule runs, the sign-in flow first checks that the person's email domain is one of your tenant's **verified domains** (listed in the Domains section above). An address outside your verified domains never reaches your tenant at all, regardless of what rules you've written.

There are two separate rule lists, because there are two ways a person can arrive:

* **Sign-in rules** run each time a person signs in through single sign-on. They apply on every sign-in, not just the first one, so changing a sign-in rule can move an existing member to a different organization the next time that person signs in.
* **Provisioning rules** run when your directory creates or updates someone through SCIM. They match on synced directory groups, and changes take effect at the next directory sync.

### When rules move people

Because sign-in rules run every time, a rule change has these effects on people who already exist:

* If a person now matches a rule that points to a different organization, they are moved on their next sign-in. Their active sessions and API keys are revoked as part of the move, so they land cleanly in the new organization.
* If a person no longer matches any rule (for example, you removed the only rule that covered them), they keep their current organization and can still sign in. The no-match refusal applies only to people who have never been placed.
* If a person's account is managed by your directory (that is, it was created or linked through SCIM), sign-in rules do **not** move them. Directory-managed accounts are moved only by provisioning rules, so that your directory remains the single source of truth for where they belong.

Because the Claude desktop app stores conversations on each person's own device, a move does not affect desktop chat history.

<Tip>
  When you add or edit a rule that would move people, a confirmation dialog shows how many existing members would be affected and a sample of their email addresses. Review that list before confirming.
</Tip>

> **For organization owners:** A member being moved out of your organization by a rule change loses their seat and role in your organization. Their account itself is kept, and they are reseated in the destination organization according to its available seats.

### Sign-in rules

Each sign-in rule reads as a sentence, for example *"Anyone with email domain `example.gov` → place in OEO."* A rule matches on one of the following:

* An **email domain** rule matches the domain of the user's email address exactly. You choose from your tenant's verified domains; you cannot type an arbitrary domain. Subdomains are not matched automatically, so `sub.example.gov` needs its own rule if you want it routed.
* An **identity provider (IdP) group** rule matches a value in the group membership list that your identity provider includes in the sign-in token. You type the exact value your provider sends, and matching is exact and case-sensitive.

Rules are evaluated from top to bottom, and the first match wins. When you have more than one rule, drag the handle next to a rule (or focus the handle and press the up or down arrow key) to reorder the list. Only one rule can exist for any given condition. If you pick a domain or group that already has a rule, a message below the form shows which organization it currently routes to and asks you to remove that rule first.

Each rule shows a status line with diagnostics:

* **Last matched** (or **Never matched**) tells you when the rule most recently placed or moved someone.
* A **matches broadly** badge marks a domain rule that sits above one or more group rules. Because it matches everyone on that domain, group rules below it can never win for those users; move it lower if that's not what you intended.
* A **target deactivated** badge means the rule points at an organization that has been deactivated. The rule is skipped during evaluation.
* A **stale value** badge means the condition refers to something that no longer exists, such as a domain removed from your verified list. The rule is skipped during evaluation.

### Provisioning rules (SCIM)

<Note>
  This section only appears when SCIM is connected (you have an active SCIM token or your directory has synced groups) or when provisioning rules already exist.
</Note>

Provisioning rules match on **directory groups** that your identity provider has synced, and decide which organization a user is placed in when your directory provisions or updates them. You choose groups from the synced list; a group that hasn't synced yet won't appear in the picker.

Provisioning rules work the same way as sign-in rules: they're an ordered list, the first match wins, and only one rule can exist per group. Because your directory re-evaluates placement on each sync, reordering or removing provisioning rules can move already-placed users at the next sync. You'll be asked to confirm before reordering.

### Adding and removing rules

To add a rule, choose the match type (for sign-in rules), pick or type the value, choose the target organization, and click **Add rule**. New rules are added at the bottom of the list; reorder after adding if you need a different priority.

To remove a rule, click **Remove** next to it and confirm. Removing the last sign-in rule is called out specifically: no new person can sign in until another rule is added, and existing members keep their current organization until another rule covers them.

## Preview routing

Enter an email address (and, optionally, a comma-separated list of IdP groups) to see exactly how that person would be routed, without changing anything. The preview runs the same evaluation that real sign-in and provisioning use, so what you see here is what will actually happen.

The result shows one panel for sign-in and a separate panel for directory provisioning.

<Note>
  The directory provisioning panel only appears when SCIM is connected for your tenant.
</Note>

Each panel shows whether the person would be placed (and in which organization) or refused, and it lists every rule in order with the outcome for each: **matched**, **no match**, or **target deactivated**. If the email's domain isn't one of your tenant's verified domains, the preview explains that sign-in would never reach this tenant at all, and no rules are evaluated.

<Tip>
  Editing any rule clears the preview result automatically so you never read a verdict that's out of date. Re-run the preview after making changes.
</Tip>

## Unplaced users

The unplaced-users lists collect people who have arrived but aren't in an organization yet. There are two kinds of entry:

* **Rejected sign-ins** are people from one of your verified domains who tried to sign in but matched no rule and were turned away. Each entry shows who tried, when they last tried, how many times, and which IdP groups their sign-in token carried. These records are kept so you can see who's trying and failing to get in.
* **Synced, not routed** entries are people your directory has provisioned through SCIM who don't yet match any provisioning rule. They exist in the sync but have not been placed in an organization, so they cannot sign in.

<Note>
  The Rejected sign-ins list only appears when at least one sign-in has been turned away. The Synced, not routed list appears inside the provisioning-rules card and only when at least one provisioned user is waiting without a matching rule.
</Note>

For rejected sign-ins you can do the following:

* Click **Test in preview** to load that person's email and recorded groups into the preview, so you can see exactly which rule would cover them before you add one.
* Click **Clear** to delete the record, or **Clear all** to remove every entry. Clearing does not block the person; a fresh entry appears if they try again.

For synced, not routed entries, add a provisioning rule that covers their group. They'll be placed automatically at the next directory sync; there is nothing to clear.

Once a person is successfully placed (by signing in through a matching rule or by the next directory sync), their entries in these lists are cleaned up automatically.

## Things to know

* Keep the DNS TXT record in place while you are using Claude for Government.
* There is no local break-glass account or stored password. When single sign-on is unavailable, Primary Owners and tenant administrators can request an emailed single-use sign-in link from the sign-in page.
* SCIM provisioning is configured entirely from this page, with no action needed from Anthropic. Use **Generate token** under [SCIM provisioning](#scim-provisioning) on this page to create a bearer token, then enter it along with the SCIM base URL shown there into your identity provider's provisioning settings.
* If two administrators reorder the same rule list at the same time, the second save is rejected with a message that the rules changed in another session. The list refreshes so you can review the current order and try again.
* A user who was previously deactivated cannot regain access by matching a rule; they are refused with a deactivated-user reason instead.
* For users managed by your directory, the email address shown in Claude for Government is kept in step with your directory. The sign-in token's email is ignored for those users so that a provider that sends different values in different fields (a common quirk in Microsoft Entra) does not bounce the address back and forth.

government/tenant-admin/organizations First recorded · 49 lines, first recorded

# Organizations ## How organizations work ## The organization list ## Adding an organization ### After you add an organization ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Organizations

> Use this page to see every organization in your tenant, open any organization's admin view, and create new organizations.

> **Who this is for:** Tenant administrators who create and oversee the organizations within their agency's deployment.

Use this page to see every organization in your tenant, open any organization's admin view, and create new organizations.

## How organizations work

An **organization** is a workspace that holds a set of users, a set of seats, its own spend caps, and its own product settings. Users always belong to exactly one organization, and each organization is linked to exactly one **billing account** (the credit and seat pool that funds it).

Organizations share the tenant's sign-in and provisioning setup. You configure single sign-on once on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page and every organization uses the same connection. What differs between organizations is who belongs to each one, and that is decided by the routing rules on that same page rather than here.

## The organization list

Each organization appears with its name and ID. Clicking an organization's name opens its organization admin view. When you do this you are acting as an administrator of that organization, and you can manage its users, seats, and settings exactly as one of its own owners would.

<Tip>
  Which organization a user joins isn't controlled on this page. That's set by the routing rules on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page.
</Tip>

## Adding an organization

Expand the **Add organization** section to create a new organization. You'll provide the following:

* **Name** is what the organization will be called. Leading and trailing spaces are trimmed, and the name can be up to 256 characters. There is no uniqueness requirement, so you can create two organizations with the same name, but you generally shouldn't.
* **Primary owner email** is the email address of the person who will be the new organization's first administrator. This person becomes the Primary Owner and can immediately manage the organization's users and settings. They do **not** become a tenant administrator; tenant-level access is granted separately on the [Admins](/docs/government/tenant-admin/admins) page.
* **Billing account** determines where the organization's credits and seats come from. Choose an existing billing account from the list; the new organization draws from that account's credit balance and seat pool alongside any other organizations already on it. Only billing accounts that are active and tenant-managed appear in the list.

<Note>
  If the list is empty, your tenant has no active tenant-managed billing accounts yet. Contact Anthropic to have one set up.
</Note>

### After you add an organization

The new organization appears in the list immediately and you can click through to its organization admin view. A few follow-up steps are usually needed before people can use it:

* Add a routing rule on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page so that the right people are placed in the new organization when they sign in or are provisioned. Until a rule targets the new organization, nobody will land there automatically.
* Give it seats on the [Seats](/docs/government/tenant-admin/seats) page. A newly created organization starts with no seats distributed to it.
* If you want to limit how much the new organization can spend from its billing account, set a spend cap on it on the [Billing](/docs/government/tenant-admin/credits) page. This is optional. With no cap, the account's balance is the only limit.

> **For organization owners:** Being named the primary owner of a new organization does **not** make you a tenant administrator. Tenant admin access is granted separately on the [Admins](/docs/government/tenant-admin/admins) page.

## Things to know

* You cannot delete an organization from this page. If an organization is no longer needed, contact Anthropic to have it deactivated. Routing rules that target a deactivated organization stop matching, and users in a deactivated organization cannot sign in until it is reactivated or they are moved.
* Organization names can be changed later from the organization's own admin view.
* There is no fixed limit on the number of organizations you can create, but each one adds a row to your seat distribution and configuration surfaces, so create only as many as you need to keep administration manageable.

government/tenant-admin/overview First recorded · 62 lines, first recorded

# Tenant administration ## Tenants and organizations ## Who can use this portal ## Getting set up for the first time ## Pages in this portal

The first capture of this source. The page was already there, and this is what it said.

# Tenant administration

> Manage the settings that apply across your whole agency: organizations, identity and sign-in, and how seats are distributed and spend caps are set.

> **Who this portal is for:** Tenant administrators who manage their agency's overall Claude for Government deployment across every organization. If you manage a single organization, see the [Organization administration](/docs/government/org-admin/overview) guide instead.

The tenant admin portal is where you manage the things that apply across every team using the service: identity, organization routing, seats, spend caps, and tenant-wide product settings.

## Tenants and organizations

Your **tenant** is your agency's top-level account. Within your tenant you create one or more **organizations**, which are separate workspaces for different teams, bureaus, or programs. All organizations in your tenant share the same sign-in setup, so one connection to your identity provider covers everyone. What differs between organizations is who belongs to each one, how many seats each one is allocated and what spend caps are set on it, and which product settings each one can adjust for itself.

Funding flows through **billing accounts**, which are credit and seat pools that Anthropic sets up with your agency. Every organization is linked to exactly one billing account, and several organizations may draw from the same one. The [Seats](/docs/government/tenant-admin/seats) page is where you divide each billing account's seat pool among its organizations, and the [Billing](/docs/government/tenant-admin/credits) page is where you see each account's balance and set per-organization spend caps.

There are two admin portals:

* The **tenant admin** portal (this one) is where you create organizations, connect your identity provider, decide which organization each user lands in, distribute seats and set spend caps, and set tenant-wide policy. Only tenant administrators can see it.
* The **organization admin** portal is where each organization's own owners manage that organization's users, seats, and settings. As a tenant administrator, you can open any organization's admin view from the [Organizations](/docs/government/tenant-admin/organizations) page, or you can use the **Switch to org view** link at the bottom of every tenant admin page.

## Who can use this portal

Only **tenant administrators** can open the tenant admin portal. Tenant administrators are a specific list of people that are managed on the [Admins](/docs/government/tenant-admin/admins) page, and this list is separate from any role someone holds inside an organization.

> **For organization owners:** Owning an organization does *not* make you a tenant administrator. If you need tenant-level access, ask an existing tenant administrator to add you on the [Admins](/docs/government/tenant-admin/admins) page.

Every page of this portal requires tenant administrator access. If you follow a link in this guide without tenant access, you'll be turned away with a permission error.

## Getting set up for the first time

The [setup wizard](/docs/government/tenant-admin/setup-wizard) walks you through all of this step by step.

If your tenant has just been created, work through the pages in this order:

1. **[Identity and access](/docs/government/tenant-admin/identity-and-access).** Connect single sign-on so that people can authenticate with their agency credentials, optionally connect SCIM provisioning so that your directory syncs users and groups automatically, and add at least one routing rule so that users are placed in an organization when they sign in. Until a rule exists, nobody else can sign in.
2. **[Seats](/docs/government/tenant-admin/seats) and [Billing](/docs/government/tenant-admin/credits).** Distribute seats from your billing account to the organizations that will use them, and optionally set spend caps.
3. **[Admins](/docs/government/tenant-admin/admins).** Add at least one more tenant administrator so that you are not the only person with tenant-level access.

<Warning>
  There is a short setup period after Anthropic first creates your tenant. During that period, a banner appears on the Identity and access page and nobody at your agency can sign in yet, including people who would normally be routed to an organization. You can still use that time to configure your single sign-on connection and routing rules, and they will start working automatically as soon as the setup period ends.
</Warning>

## Pages in this portal

The navigation groups the pages into three sections.

**Organizations and identity**

* The **[Organizations](/docs/government/tenant-admin/organizations)** page lets you see every organization in your tenant, open any organization's admin view, and create new organizations.
* The **[Identity and access](/docs/government/tenant-admin/identity-and-access)** page lets you connect single sign-on (using either the OIDC or SAML protocol, whichever your identity provider supports), manage the SCIM provisioning token, write the routing rules that place users into organizations, preview how a specific person would be routed, and review people who haven't been placed yet.

**Seats and billing**

* The **[Seats](/docs/government/tenant-admin/seats)** page lets you distribute the seats in each billing account's pool to the organizations that account funds.
* The **[Billing](/docs/government/tenant-admin/credits)** page shows each billing account's balance and lets you set spend caps that limit how much each organization can draw from it.

**Settings**

* The **[Config](/docs/government/tenant-admin/configuration)** page lets you set product settings that apply to every organization, and optionally lock them so organizations can't override them.
* The **[Admins](/docs/government/tenant-admin/admins)** page lets you manage who has access to this tenant admin portal.
* The **[Readiness](/docs/government/tenant-admin/readiness)** page shows what is blocking your organizations from using Claude and where each item is resolved.

The [setup wizard](/docs/government/tenant-admin/setup-wizard) is not a page in this list; you reach it through the **Resume setup** banner that appears above the navigation until your tenant is fully set up.

government/tenant-admin/readiness First recorded · 50 lines, first recorded

# Readiness ## How the checklist is presented ## Tenant-level checks ## Organizations ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Readiness

> Use this page to see everything that is blocking your organizations from using Claude, and to find the one place where each blocker is resolved.

> **Who this is for:** Tenant administrators who are setting up a deployment, or who need to find out why users in any organization are unable to use Claude.

Use this page to see everything that is blocking your organizations from using Claude, and to find the one place where each blocker is resolved.

A deployment is ready when a user in each organization can sign in, be placed in that organization, hold a seat, and send a message to a model. This page runs that check for the whole tenant and lists every step that is complete, blocked, or waiting on someone. You would normally work through it once during initial setup and then return whenever the **Settings** menu shows a notification dot, which appears whenever anything on this page needs attention.

## How the checklist is presented

Each step sits on a vertical track with a status marker.

* A **green check** means the step is complete. The label is struck through and you can ignore it.
* A **filled circle** marks the step you should act on next. It expands to show why it is blocked and offers an **Open** button that takes you to the page where the fix is made.
* A **clock** means the step is blocked but you are not the person who can clear it. A line underneath tells you whether it is waiting on Anthropic, on an organization owner, or on the owner of a shared billing account.
* A **hollow circle** is a step still to come. It stays collapsed until the steps ahead of it are cleared.

Below a divider is an **Optional** section. These items do not stop anyone from using Claude, but the page surfaces them because they usually matter, such as setting up SCIM provisioning or reviewing sign-in attempts that were turned away.

Use **Refresh** at the top right after you make a change elsewhere to see the updated state without leaving the page.

## Tenant-level checks

These are the items that appear in the top card. They cover the things every organization in your tenant depends on.

* **Activate the tenant** appears on its own when Anthropic has not yet finished provisioning your tenant, or when the tenant has been deactivated. Nothing else can be configured until this clears, and only Anthropic can clear it, so the page shows a waiting state.
* **Fund the billing account** checks that at least one billing account linked to an active organization has a positive balance. This is advisory because the blocking state is shown on each organization's own readiness check. Funding is arranged with Anthropic.
* **Configure the seat pool** checks that at least one billing account has a seat pool set. This is also advisory. Without a pool, seat allocations on the [Seats](/docs/government/tenant-admin/seats) page are accepted without any cap. The pool is configured by Anthropic as part of your contract.
* **Register a domain** is required. Claude for Government routes users to your tenant by the domain of their email address, so until at least one domain is registered nobody can start a new sign-in. Use **Open Identity and access** to go to the [Identity and access](/docs/government/tenant-admin/identity-and-access) page and add one.
* **Set up SCIM provisioning** is optional. SCIM lets your directory push users and groups into Claude for Government automatically. If you plan to use it, generate a provisioning token on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page.
* **Add a routing rule** is required. Routing rules decide which organization each user joins when they sign in. Until at least one rule points at an active organization, every new sign-in is turned away. Use **Open Identity and access** to add a rule. If your tenant has no active organizations yet, the button instead opens the [Organizations](/docs/government/tenant-admin/organizations) page so you can create one first.
* **Review sign-in failures** is an optional summary of people who tried to sign in and were turned away. The description tells you how many need a routing rule, how many need their email domain registered, and how many conflict with an existing account. Use **Open Identity and access** to resolve them.

If your tenant has a single organization, that organization's own checks (credits, spend caps, seats, seat tiers, and products) appear directly in this card below the tenant-level items, so you can work through the whole deployment from one list.

## Organizations

When your tenant has more than one organization, a second card lists each one with a one-line summary: **Ready**, a named blocker with **(fix available)**, or a named blocker with who it is waiting on. The marker beside each row uses the same colors as the checklist above.

Expanding a row loads that organization's full checklist inline. The steps are the same ones described on the [organization Readiness page](/docs/government/org-admin/readiness), and any buttons you click here act on that organization, not the one you are currently viewing in the organization admin portal. This lets you clear an organization's blockers without switching context.

Deactivated organizations appear here with their reactivation status. An organization whose billing account is retired cannot be reactivated until the account has settled and Anthropic has assigned a new one, so those rows show a waiting state instead of a button.

## Things to know

* Every **Open** button goes to the page where the fix belongs, with the right organization already selected when one applies. You make the change there and return here to see it reflected.
* When a step is something only Anthropic can do, such as funding a billing account or reactivating an organization, the page shows **Waiting on Anthropic**. Contact your Anthropic representative to move it forward.
* Hover the help icon next to any step's label for a one-line explanation of what the check looks for.

government/tenant-admin/seats First recorded · 56 lines, first recorded

# Seats ## How seats are organized ## What the page shows ## Changing an organization's seats ## How seats affect new users ## When you can't edit ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Seats

> Use this page to divide each billing account's seat pool among the organizations that account funds.

> **Who this is for:** Tenant administrators who distribute purchased seats to the organizations in their deployment.

Use this page to divide each billing account's seat pool among the organizations that account funds.

## How seats are organized

A **seat** is what entitles one person to use Claude. Every seat belongs to a **seat tier**, which is a named level of access that determines how much a person in that seat may use (for example, different usage limits per tier).

Seats live in **billing accounts**, which are the credit and seat pools Anthropic sets up with your agency. Anthropic grants each billing account a pool of seats, broken down by tier. Every organization is linked to exactly one billing account, and on this page you divide each account's pool among the organizations it funds. For each tier, the totals you hand out across those organizations can't exceed what's in the pool.

Seat distribution is a two-step process. On this page you give each organization a number of seats per tier. Organization owners then assign those seats to individual people in the organization admin portal.

## What the page shows

<Note>
  Billing account cards only appear once Anthropic has set up at least one billing account for your tenant. Until then, the page shows a message asking you to contact Anthropic.
</Note>

Each billing account appears as its own card, and each card contains the following:

* The **seat pool** table shows each seat tier with the pool size, how many seats have been distributed across organizations, and how many remain. A negative **Remaining** number (shown in red) means the pool was reduced after seats were distributed; contact Anthropic to adjust the pool, or reduce some organizations' allocations.
* The **organizations** section lists every organization funded by this account, and each one has a number field per tier showing its current allocation.

## Changing an organization's seats

Edit the number fields next to an organization's name and click **Save**. Saving replaces that organization's allocation across all tiers at once. Changes take effect immediately: newly added seats are available for the organization's owners to assign right away.

The save will be rejected in a few cases:

* If the totals you entered across all of an account's organizations would exceed the pool for any tier, you'll see an error explaining which tier is over.
* If you try to reduce a tier below the number of people (and service accounts) already seated on it in that organization, you'll see an error. Ask the organization's owners to unassign people from that tier first, then reduce the allocation.
* Similarly, you cannot remove a tier from an organization entirely (by setting it to zero) while anyone is still seated on it there.

## How seats affect new users

When a new person is placed in an organization (by a routing rule on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page), they're automatically given a seat if one is free. Tiers are filled in a fixed order, so the first tier is filled before the next is started. If every tier the organization has is completely full, the new person is placed in the organization without a seat. They can sign in and see the portal, but cannot send messages to Claude until an owner assigns them a seat or you distribute more seats here.

An organization that has no seat allocation at all is treated as uncapped. New users can join and use Claude, but this is unusual; normally every active organization has at least one tier allocated.

## When you can't edit

You'll see a note instead of the editor in a few situations:

* If the billing account is **deactivated**, its seats can't be redistributed. Contact Anthropic to move its organizations to an active account.
* If the account is **managed by one organization's administrators** rather than by tenant administrators, you won't be able to edit it here; the owning organization controls its own distribution.
* If the account has **no seat pool yet**, contact Anthropic to set one up.

## Things to know

* Reducing an organization's allocation never unassigns anyone automatically. The reduction is refused until enough people have been moved off the tier.
* You can freely move seats between organizations on the same billing account by lowering one and raising another, as long as neither change violates the rules above. You may need to save the reduction first to free the pool, then save the increase.
* Seat pools are set by Anthropic. If you need more seats in a tier, or a new tier added, contact Anthropic.

government/tenant-admin/setup-wizard First recorded · 104 lines, first recorded

# Tenant setup wizard ## Step 1: Welcome ## Step 2: Domains ## Step 3: Single sign-on ## Step 4: Provisioning (optional) ## Step 5: Organizations ## Step 6: Seats and spend caps ## Step 7: Routing ## Steps 8 and 9: Seat tiers and Products (single-organization tenants only) ## Final step: Finish ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Tenant setup wizard

> Walk through the guided setup that takes a brand new tenant from first sign-in to ready for users.

> **Who this is for:** Tenant administrators who have just been given access to a new Claude for Government deployment and need to get it ready for the rest of their agency.

When Anthropic first hands over your tenant, only you and any other administrators invited by email can sign in. The setup wizard walks you through the handful of things that need to be in place before everyone else can use Claude: a verified email domain, a connection to your identity provider, at least one organization, seats for that organization, and a routing rule that places people in it. Until setup is complete, a **Resume setup** banner appears at the top of the tenant and organization admin pages so you can pick up where you left off.

The wizard has a step list on the left and the current step on the right. Completed steps are ticked, and you can click any step in the list to jump to it. Every step has a **Continue later** link at the bottom that takes you back to the tenant admin portal; nothing is lost, and the **Resume setup** banner brings you back when you are ready. Steps marked **Optional** in the list can be skipped without blocking sign-in.

## Step 1: Welcome

The first step is a read-only summary of what Anthropic has already set up for you: your tenant's name, any email domains that Anthropic verified on your behalf during provisioning, and how many organizations already exist. There is nothing to fill in here. It is simply a chance to confirm that the tenant name is what you expect before you continue.

If a detail looks wrong (for example, the tenant name is misspelled), contact Anthropic before going further, because the tenant name cannot be changed from the portal.

## Step 2: Domains

Claude for Government looks at the domain of a person's email address to decide which tenant they belong to, so at least one verified domain must be registered before anyone else can sign in. The table at the top of this step lists the domains already on your tenant, along with whether each one is verified and whether it was added by Anthropic or by you.

If Anthropic already verified the domain you plan to use, you can move straight on to the next step. To add another domain, type it into the **Claim a domain** field and click **Claim**. You will be shown a DNS TXT record to publish on that domain. Once the record is live, click **Verify now** next to the pending claim and the domain becomes active. DNS changes can take anywhere from a few minutes to an hour to propagate, so try again shortly if verification does not succeed on the first attempt.

For more detail on how domains work and how to remove one later, see the [Domains section of the Identity and access page](/docs/government/tenant-admin/identity-and-access#domains).

## Step 3: Single sign-on

This step connects Claude for Government to your agency's identity provider (for example, Microsoft Entra, Okta, or ADFS) so that everyone signs in with their existing agency credentials. A **Connected** or **Not connected** badge next to the heading shows the current state.

This step is unavailable until you have verified at least one domain on the previous step. A banner on this step says so, because sign-in routes people to your tenant by the domain of their email address.

Setting this up is a two-way exchange:

1. Copy the values shown on this step and register a new application in your identity provider using them. **Redirect URI / ACS URL** is where your provider sends the user back after authentication (providers call it the Redirect URI for OIDC, or the Assertion Consumer Service URL for SAML). **SP Entity ID / Audience** is the identifier your provider uses to recognize this application.
2. Choose the **OIDC** or **SAML** tab to match what your provider supports, then fill in the form with the values your provider gives you for the new application. For OIDC these are the Client ID, Client secret, Authorization URL, Token URL, Issuer, and JWKS URL. For SAML this is a single IdP metadata XML document: paste the federation metadata from your provider, and the Entity ID and SSO URL are read from it and shown back to you once connected.
3. Save the form. The badge changes to **Connected** once the connection has been verified.

After you save a SAML connection, an **SP metadata URL** appears with the other values; most providers can import it to fill in the values automatically if you need to reconfigure.

Until single sign-on is connected, only owners who were invited directly by email can sign in. The full field reference for both protocols is on the [Identity and access](/docs/government/tenant-admin/identity-and-access#single-sign-on) page.

## Step 4: Provisioning (optional)

This step is optional. If your identity provider supports SCIM, which is a standard way for directory systems to push users and group memberships into other applications, you can connect it here so that accounts are created automatically rather than at first sign-in.

Like single sign-on, this step is unavailable until you have verified at least one domain on Step 2.

Copy the **Tenant URL** shown on this step into your identity provider's SCIM connector, then click **Generate token** and paste the token into the connector's secret token field. The token is shown only once, so copy it before closing the page. If you need to rotate it later, generate a new one and revoke the old one with the **Revoke** button.

You do not have to finish the provider-side setup before moving on. Once your provider has pushed at least one group, you can come back to the Routing step (or the [Identity and access](/docs/government/tenant-admin/identity-and-access#scim-provisioning) page) and add rules that place people by group membership.

## Step 5: Organizations

An organization is a workspace with its own members, its own seat allocation, its own spend caps, and its own settings. You need at least one before you can route anyone anywhere, and many agencies only ever need one. You would add more if different bureaus or programs need separate usage reporting, separate budgets, or different product settings.

Any organizations that already exist are listed at the top. To create one, fill in the **Add organization** form:

* **Name** is the display name shown throughout the portal.
* **Primary Owner email** is the person who will manage this organization's members and seats. They will be invited by email and land in the organization admin view when they sign in.
* **Billing account** is the account this organization draws from for seats and billed usage. Several organizations can share one account if they should be funded from a single budget.

Click **Add** and the new organization appears in the list. You can create as many as you need now and add more later from the [Organizations](/docs/government/tenant-admin/organizations) page.

## Step 6: Seats and spend caps

This step lets you give each organization seats and, optionally, a spend cap.

Seats control how many people in each organization can use Claude. The table shows each organization with a seat-count field for the first seat tier. Enter the number of seats each organization should have and save. For per-tier control, use the full [Seats](/docs/government/tenant-admin/seats) page after setup.

Each organization's usage spends directly from its billing account's balance, and you can add a spend cap to limit how much any one organization can use in a rolling window. Caps are optional. If you leave them blank, the billing account's balance is the only limit. You can adjust both seats and caps later from the tenant [Seats](/docs/government/tenant-admin/seats) and [Billing](/docs/government/tenant-admin/credits) pages.

## Step 7: Routing

Routing rules decide which organization a person lands in when they sign in. A new person who does not match any rule cannot sign in at all, so you need at least one rule that covers your users. A single rule that maps your main email domain to your main organization is enough to get started.

Each rule reads like a sentence: a condition on the left, an arrow, and the target organization on the right. To add one, use the form at the bottom:

* In the **If** field, choose **Anyone with email domain** to match on the domain of the person's email address, or **Anyone with IdP group** to match on a group claim from your identity provider.
* In the second field, pick the domain or type the group name.
* In the **Then place in** field, pick the organization.
* Click **Add rule**.

Rules run from top to bottom and the first match wins, so drag more specific rules above broader ones. Rules that match directory groups pushed over SCIM are managed on the full [Identity and access](/docs/government/tenant-admin/identity-and-access#routing-rules) page, which also has a preview tool for testing where a specific email address would land.

## Steps 8 and 9: Seat tiers and Products (single-organization tenants only)

If your tenant has exactly one organization, the wizard includes two extra steps so that you can finish the organization-level setup without switching portals. You will only see these two steps in the step list if your tenant has a single organization. Tenants with more than one organization skip straight to the Finish step, and each organization's owner completes these two steps in their own [organization setup wizard](/docs/government/org-admin/setup-wizard) instead.

* **Seat tiers** lists the seat tiers available to the organization. A seat tier bundles together which Claude models a user may access and how much they may spend. Anthropic-managed tiers are set up for you during provisioning; if your organization is allowed to create self-managed tiers, you can add one here. See the organization [Seat tiers](/docs/government/org-admin/seat-tiers) page for the full editor.
* **Products** lets you choose which Claude products the organization's members can sign in to, for example Claude Desktop, Claude Code, and Claude for Microsoft 365. This is optional, and a product that is not available on your deployment is shown grayed out with a note to contact Anthropic.

## Final step: Finish

The last step shows a live readiness checklist. Each row is something that has to be in place before people can sign in, and it is ticked or crossed out as soon as you complete it. Items under the **Optional** heading do not block sign-in.

If anything required is still outstanding, a yellow banner tells you so, and the button at the bottom reads **Continue later** so you can come back. Once every required item is ticked, the button changes to **Go to tenant** and your deployment is ready. As colleagues sign in they will start appearing on each organization's Users page.

There is no separate "mark complete" action. The wizard reads the live state of your tenant, so if something changes later (for example, you remove your only routing rule), the **Resume setup** banner reappears on the tenant admin pages until the checklist is satisfied again.

## Things to know

* You can leave the wizard at any point using **Continue later**. Everything you have entered is saved, and the **Resume setup** banner on the tenant and organization admin pages brings you back to where you left off.
* Every step in the wizard edits the same settings as the matching page in the full tenant admin portal. You can use either one, and changes made in one place show up in the other.
* Steps tick automatically when the underlying condition is met. The **Provisioning** and **Products** steps are optional and never block the Finish step.
* Single sign-on and at least one routing rule are the two things that actually gate sign-in for everyone else. If you only have a few minutes, do those two first and come back for the rest.

government/tenant-admin/tenant-restrictions First recorded · 100 lines, first recorded

# Tenant restrictions ## How it works ## Configure your network proxy ## Header format ### Finding your tenant ID ## What a blocked user sees ## How invalid headers are handled ## Verifying the configuration ## Things to know

The first capture of this source. The page was already there, and this is what it said.

# Tenant restrictions

> Restrict which Claude for Government tenants can be reached from your agency's network by having your network proxy inject an allowlist header.

> **Who this is for:** IT and network administrators who operate their agency's outbound web proxy or secure web gateway and want to prevent users on that network from signing in to Claude for Government with a different agency's account.

Tenant restrictions let you limit which Claude for Government tenants can be reached from your network. Your network appliance adds a header to every outbound request listing the tenants you allow, and Claude for Government refuses any request that authenticates as a tenant not on that list.

This is useful when people on your network may hold accounts in more than one agency's tenant (for example, a contractor who supports several agencies) and you need to ensure that work done from your network stays within your own tenant.

There is nothing to enable on the Claude for Government side. The restriction is activated entirely by the presence of the header on the request, so it takes effect the moment your proxy begins injecting it and only for traffic that passes through that proxy.

## How it works

Your agency's network appliance (a forward proxy, secure web gateway, or similar device that can inspect and modify HTTPS traffic) injects an `Anthropic-Allowed-Tenant-Ids` header on every request it forwards to Claude for Government. The header value is a comma-separated list of tenant IDs.

On each request, Claude for Government compares the authenticated user's tenant against the list in the header. When the header is present and the user's tenant is not on the list, the request is refused. When the header is absent, no restriction applies.

The check covers every way a user can reach Claude for Government:

* The web application, including the tenant and organization admin portals
* The desktop application
* Claude Code
* The Claude for Microsoft 365 add-ins
* Direct API calls
* SCIM directory provisioning and the [Compliance API](/docs/government/org-admin/compliance-api)

The same check applies at sign-in, so a user signing in to a tenant that is not on the list sees the refusal at the sign-in screen rather than after authentication completes.

<Note>
  A tenant restriction can only narrow access. A user still needs valid credentials for a tenant on the list; the header never grants access to a tenant the user does not already belong to.
</Note>

## Configure your network proxy

Configure your appliance to do both of the following on every request to your Claude for Government domains:

1. **Remove** any `Anthropic-Allowed-Tenant-Ids` header that arrived from the client.
2. **Set** a single `Anthropic-Allowed-Tenant-Ids` header to your allowlist value.

<Warning>
  Your appliance must remove the incoming header before setting its own. If the appliance only appends, ordinary traffic still works, so the misconfiguration is not obvious. A client that supplies its own value can then reach the server with both values, which either bypasses the restriction or causes that client's requests to fail, depending on how the appliance merges the two. Most secure web gateway products have a distinct "set" or "overwrite" action that removes and replaces in one step; use that rather than "append" or "add".
</Warning>

Apply the rule to requests for the Claude for Government domains provided to you during onboarding, as well as your agency's own custom domain if you have one. Because Claude for Government is served over HTTPS, your appliance must perform TLS inspection for these hosts so that it can add the header to the encrypted request.

Requests that do not pass through your appliance (for example, from a device that is off your network) do not carry the header and are not restricted. Pair this feature with your existing controls that ensure managed devices route through the appliance.

## Header format

The header name is `Anthropic-Allowed-Tenant-Ids`. Header names are not case-sensitive, so your appliance may send the name in any casing.

The value is one or more tenant IDs separated by commas. A tenant ID has the form `umb_` followed by a lowercase UUID with dashes. The `umb_` prefix is optional, and whitespace around each ID is ignored. The UUID must be lowercase; an uppercase or mixed-case value is rejected as invalid.

```text theme={null}
Anthropic-Allowed-Tenant-Ids: umb_00000000-0000-4000-8000-000000000000
```

For more than one tenant, separate the IDs with commas:

```text theme={null}
Anthropic-Allowed-Tenant-Ids: umb_00000000-0000-4000-8000-000000000000, umb_11111111-1111-4111-8111-111111111111
```

### Finding your tenant ID

Anthropic provides your tenant ID during onboarding. If you do not have it on hand, contact Anthropic support and ask for the tenant ID for your deployment.

## What a blocked user sees

A user who tries to sign in to a tenant that is not on your allowlist sees a refusal page titled **This account isn't permitted from this network**, with guidance to sign in with an authorized account or contact their IT administrator.

A user who is already signed in when the restriction takes effect, or whose application makes a request in the background, receives an error in the product reading **Your organization restricts which accounts can be used from this network. Contact your IT administrator.** Direct API calls return HTTP 403 with the error code `tenant_restriction_violation` and the message `Access restricted by network policy. Contact your IT administrator.`

The refusal does not tell the user which tenants are permitted. Keep a record of your allowlist alongside your proxy configuration so that your help desk can answer user questions without inspecting the appliance.

## How invalid headers are handled

Claude for Government rejects malformed headers so that a misconfigured proxy fails visibly rather than silently allowing everything through. A request is rejected with HTTP 400 and the error code `tenant_restriction_header_invalid` when any of the following is true:

* The header is present but empty, or contains only whitespace or commas.
* Any value in the list is not a valid tenant ID.
* The list contains more than 64 tenant IDs.
* The request carries more than one `Anthropic-Allowed-Tenant-Ids` header.

A request with no `Anthropic-Allowed-Tenant-Ids` header at all is not restricted.

## Verifying the configuration

You can confirm the restriction is working before rolling it out broadly.

To confirm a block, temporarily set the proxy's allowlist to a tenant ID you do not own (any validly formatted ID works), then sign in to your own tenant from a browser that routes through the proxy. You should see the **This account isn't permitted from this network** refusal page. A direct API request in the same configuration should return HTTP 403 with the error code `tenant_restriction_violation`.

To confirm normal access, set the proxy's allowlist to your real tenant ID and repeat the request. It should succeed.

To confirm the appliance is overwriting rather than appending, have the test client send its own `Anthropic-Allowed-Tenant-Ids` header with your real tenant ID while the proxy's allowlist is set to an ID you do not own. The request should still return 403 (the proxy's value wins), not 400 (two headers reached the server) or 200 (the client's value reached the server).

## Things to know

* Personal Claude accounts use `claude.ai`, which is a separate host from the Claude for Government service. A personal account cannot sign in to Claude for Government, and a Claude for Government account cannot sign in to `claude.ai`. The header-based restriction on this page applies only to Claude for Government traffic; it does not govern access to `claude.ai`.

index First recorded · 383 lines, first recorded

# Welcome

The first capture of this source. The page was already there, and this is what it said.

# Welcome

> Connect Claude to your tools, teach it how your team works, and put it to work in Slack, on your desktop, in Microsoft 365, or through the Claude API.

<div className="home-landing">
  <section className="hl-hero">
    <div className="hl-hero-inner">
      <p className="hl-eyebrow">Claude.ai documentation</p>
      <h1 className="hl-hero-title">What do you want to do with Claude?</h1>

      <div className="hl-chips">
        <a className="hl-chip" href="/docs/docs/connectors/overview"><span className="hl-chip-task">Connect my apps and data</span> <span className="hl-chip-name" translate="no">Connectors</span></a>
        <a className="hl-chip" href="/docs/docs/skills/overview"><span className="hl-chip-task">Teach Claude to do tasks my way</span> <span className="hl-chip-name" translate="no">Skills</span></a>
        <a className="hl-chip" href="/docs/docs/cowork/overview"><span className="hl-chip-task">Give Claude a goal and check back</span> <span className="hl-chip-name" translate="no">Cowork</span></a>
        <a className="hl-chip" href="/docs/docs/claude-tag/overview"><span className="hl-chip-task">Put Claude to work in my Slack</span> <span className="hl-chip-name" translate="no">Claude Tag</span></a>
        <a className="hl-chip" href="/docs/docs/claude-science/overview"><span className="hl-chip-task">Analyze literature and data</span> <span className="hl-chip-name" translate="no">Claude Science</span></a>
        <a className="hl-chip" href="/docs/docs/office-agents/overview"><span className="hl-chip-task">Draft decks, emails, and docs</span> <span className="hl-chip-name" translate="no">Claude for M365</span></a>
      </div>

      <p className="hl-hero-note">To start a chat or get back to your chats, open <a href="https://claude.ai">claude.ai</a>.</p>
      <a className="hl-hero-more" href="#products">Browse all products <svg className="hl-arrow hl-arrow-down" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></a>
    </div>
  </section>

  <div className="hl-main">
    <section className="hl-section hl-products" id="products">
      <h2 className="hl-sr-only">All products</h2>

      <div className="hl-grid">
        <a className="hl-card" href="/docs/docs/connectors/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M12 22v-5" />

            <path d="M9 8V2" />

            <path d="M15 8V2" />

            <path d="M18 8v5a4 4 0 0 1-4 4h-4a4 4 0 0 1-4-4V8Z" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Connectors</span><span className="hl-card-desc">Give Claude access to your tools and data in Google Drive, GitHub, Slack, Microsoft 365, or any MCP server.</span></span>
          <span className="hl-card-cta">Browse connectors <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/skills/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M9.937 15.5A2 2 0 0 0 8.5 14.063l-6.135-1.582a.5.5 0 0 1 0-.962L8.5 9.936A2 2 0 0 0 9.937 8.5l1.582-6.135a.5.5 0 0 1 .962 0L14.063 8.5A2 2 0 0 0 15.5 9.937l6.135 1.581a.5.5 0 0 1 0 .964L15.5 14.063a2 2 0 0 0-1.437 1.437l-1.582 6.135a.5.5 0 0 1-.962 0z" />

            <path d="M20 3v4" />

            <path d="M22 5h-4" />

            <path d="M4 17v2" />

            <path d="M5 18H3" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Skills</span><span className="hl-card-desc">Teach Claude how to do something your way with reusable instructions, scripts, and resources it loads when relevant.</span></span>
          <span className="hl-card-cta">Learn about skills <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/plugins/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M15.39 4.39a1 1 0 0 0 1.68-.474 2.5 2.5 0 1 1 3.014 3.015 1 1 0 0 0-.474 1.68l1.683 1.682a2.414 2.414 0 0 1 0 3.414L19.61 19.39a1 1 0 0 1-1.68-.474 2.5 2.5 0 1 0-3.014 3.015 1 1 0 0 1 .474 1.68l-1.683 1.682a2.414 2.414 0 0 1-3.414 0L8.61 19.61a1 1 0 0 0-1.68.474 2.5 2.5 0 1 1-3.014-3.015 1 1 0 0 0 .474-1.68L2.707 13.707a2.414 2.414 0 0 1 0-3.414Z" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Plugins</span><span className="hl-card-desc">Bundle skills, connectors, and more into shareable packages for Cowork and Claude Code.</span></span>
          <span className="hl-card-cta">Explore plugins <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/cowork/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <rect width="20" height="14" x="2" y="3" rx="2" />

            <path d="M8 21L16 21" />

            <path d="M12 17L12 21" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Cowork</span><span className="hl-card-desc">Hand Claude a goal on your desktop and come back to completed work, from polished documents to organized files and synthesized research.</span></span>
          <span className="hl-card-cta">Get Cowork <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/claude-tag/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M14 9a2 2 0 0 1-2 2H6l-4 4V4a2 2 0 0 1 2-2h8a2 2 0 0 1 2 2z" />

            <path d="M18 9h2a2 2 0 0 1 2 2v11l-4-4h-6a2 2 0 0 1-2-2v-1" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Claude Tag</span><span className="hl-card-desc">Add Claude to Slack channels as a teammate your whole team can see, steer, and hand work to.</span></span>
          <span className="hl-card-cta">Set up Claude Tag <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/claude-science/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M14 2v6a2 2 0 0 0 .245.96l5.51 10.08A2 2 0 0 1 18 22H6a2 2 0 0 1-1.755-2.96l5.51-10.08A2 2 0 0 0 10 8V2" />

            <path d="M6.453 15h11.094" />

            <path d="M8.5 2h7" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Claude Science</span><span className="hl-card-desc">Run literature reviews, data analyses, and computational workflows in a desktop research workbench.</span></span>
          <span className="hl-card-cta">Set up Claude Science <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/office-agents/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <rect width="7" height="7" x="3" y="3" rx="1" />

            <rect width="7" height="7" x="14" y="3" rx="1" />

            <rect width="7" height="7" x="14" y="14" rx="1" />

            <rect width="7" height="7" x="3" y="14" rx="1" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Claude for M365</span><span className="hl-card-desc">Use Claude inside Word, Excel, PowerPoint, and Outlook, with answers based on your organization's documents.</span></span>
          <span className="hl-card-cta">Set up Claude for M365 <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/third-party/claude-desktop/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M17.5 19H9a7 7 0 1 1 6.71-9h1.79a4.5 4.5 0 1 1 0 9Z" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title">Claude on third-party platforms</span><span className="hl-card-desc">Get the full Claude Desktop experience, including Cowork, with model inference through Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, or a gateway you operate.</span></span>
          <span className="hl-card-cta">Deploy Claude Desktop <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>

        <a className="hl-card" href="/docs/docs/government/overview">
          <svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M3 22L21 22" />

            <path d="M6 18L6 11" />

            <path d="M10 18L10 11" />

            <path d="M14 18L14 11" />

            <path d="M18 18L18 11" />

            <path d="M12 2 20 7 4 7Z" />
          </svg>

          <span className="hl-card-body"><span className="hl-card-title" translate="no">Claude for Government</span><span className="hl-card-desc">Set up and manage Claude for your agency, with tenant, organization, seat, and credit administration.</span></span>
          <span className="hl-card-cta">Manage Claude for Government <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
        </a>
      </div>

      <p className="hl-changelogs"><strong className="hl-changelogs-label">What's new:</strong> the <a href="/docs/docs/cowork/changelog">Cowork changelog</a>, the <a href="/docs/docs/claude-science/changelog">Claude Science changelog</a>, and the <a href="/docs/docs/third-party/claude-desktop/configuration-changelog">Claude Desktop configuration changelog</a>.</p>
    </section>

    <section className="hl-section hl-disambig">
      <h2 className="hl-h2">Which product do you need?</h2>
      <p className="hl-lede">Start from what you're trying to do:</p>

      <div className="hl-rows">
        <a className="hl-row" href="/docs/docs/connectors/overview">
          <span className="hl-row-q">“I want Claude to see my files, Slack messages, calendar, or codebase”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name" translate="no">Connectors</span><span className="hl-row-note">access to your tools and data</span></span>
        </a>

        <a className="hl-row" href="/docs/docs/connectors/microsoft/365">
          <span className="hl-row-q">“I want Claude to read my Outlook mail and OneDrive files”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name">Microsoft 365 connector</span><span className="hl-row-note">your Microsoft 365 data in chat, not the Office apps</span></span>
        </a>

        <a className="hl-row" href="/docs/docs/office-agents/overview">
          <span className="hl-row-q">“I want to turn a document into a slide deck”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name" translate="no">Claude for M365</span><span className="hl-row-note">drafting decks, docs, and email inside the Office apps</span></span>
        </a>

        <a className="hl-row" href="/docs/docs/skills/overview">
          <span className="hl-row-q">“I want Claude to do this task the way my team does it”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name" translate="no">Skills</span><span className="hl-row-note">instructions and scripts for a task</span></span>
        </a>

        <a className="hl-row" href="/docs/docs/plugins/overview">
          <span className="hl-row-q">“I want to share a ready-made setup with my whole team”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name" translate="no">Plugins</span><span className="hl-row-note">bundled skills and connectors for Cowork and Claude Code</span></span>
        </a>

        <a className="hl-row" href="/docs/docs/claude-tag/overview">
          <span className="hl-row-q">“I want my whole channel to see and steer Claude’s work”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name" translate="no">Claude Tag</span><span className="hl-row-note">Claude in your team’s Slack</span></span>
        </a>

        <a className="hl-row" href="/docs/docs/third-party/claude-desktop/overview">
          <span className="hl-row-q">“I want Claude to run through my own cloud provider”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name">Claude on third-party platforms</span><span className="hl-row-note">Claude Desktop through your cloud provider</span></span>
        </a>

        <a className="hl-row" href="/docs/docs/connectors/building/mcp">
          <span className="hl-row-q">“I want to build or publish a connector”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M5 12h14" />

            <path d="m12 5 7 7-7 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name" translate="no">MCP</span><span className="hl-row-note">build on the open protocol and submit to the directory</span></span>
        </a>

        <a className="hl-row" href="https://code.claude.com/docs" target="_blank" rel="noopener noreferrer">
          <span className="hl-row-q">“I’m using Claude Code in my terminal”</span>

          <svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M7 7h10v10" />

            <path d="M7 17 17 7" />
          </svg>

          <span className="hl-row-a"><span className="hl-row-name" translate="no">Claude Code<span className="hl-sr-only" translate="yes"> (opens in a new tab)</span></span><span className="hl-row-note">Claude in your terminal and IDE</span></span>
        </a>
      </div>
    </section>

    <section className="hl-section hl-getstarted">
      <div className="hl-gs-col">
        <h2 className="hl-h2">Create an account</h2>

        <div className="hl-steps">
          <div className="hl-step"><span className="hl-step-num">1</span><span className="hl-step-text">Go to <a href="https://claude.ai" target="_blank" rel="noopener noreferrer">claude.ai<span className="hl-sr-only"> (opens in a new tab)</span></a></span></div>
          <div className="hl-step"><span className="hl-step-num">2</span><span className="hl-step-text">Select <strong>Continue with Google</strong> or enter your email address</span></div>
          <div className="hl-step"><span className="hl-step-num">3</span><span className="hl-step-text">Follow the prompts to complete registration</span></div>
        </div>

        <div className="hl-tip">
          <svg className="hl-tip-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
            <path d="M15 14c.2-1 .7-1.7 1.5-2.5 1-.9 1.5-2.2 1.5-3.5A6 6 0 0 0 6 8c0 1 .2 2.2 1.5 3.5.7.7 1.3 1.5 1.5 2.5" />

            <path d="M9 18h6" />

            <path d="M10 22h4" />
          </svg>

          <div className="hl-tip-text">
            <p>All plans have access to the <a href="/docs/docs/connectors/directory">Connectors Directory</a>. Free plans can also add one <a href="/docs/docs/connectors/custom/remote-mcp">custom connector</a>. Compare <a href="https://claude.com/pricing" target="_blank" rel="noopener noreferrer">Claude plans and pricing<span className="hl-sr-only"> (opens in a new tab)</span></a>.</p>
            <p>Claude for Government access is set up by your agency's administrators, so you don't need to create an account. See the <a href="/docs/docs/government/overview">Claude for Government guide</a>.</p>
          </div>
        </div>
      </div>

      <div className="hl-gs-col">
        <h2 className="hl-h2">Building with Claude</h2>

        <div className="hl-dev-list">
          <a className="hl-dev-card" href="https://platform.claude.com" target="_blank" rel="noopener noreferrer">

Cut at 300 lines. The page has the rest.

office-agents/connectors-and-skills First recorded · 55 lines, first recorded

# Connectors and Skills ## Connectors ## Skills ## Related

The first capture of this source. The page was already there, and this is what it said.

# Connectors and Skills

> Extend Claude for Excel, PowerPoint, Word, and Outlook with external context and reusable task recipes.

Connectors and Skills work the same way across Claude for Excel,
PowerPoint, Word, and Outlook. Both are enabled in your Claude settings.

<Note>
  Connectors and Skills are available when you sign in with your Claude
  account directly. When connecting through a third-party platform such
  as Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM
  gateway, these capabilities may not be available. See the feature
  comparison in
  [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
  for the current status by connection mode.
</Note>

## Connectors

Connect external tools to give Claude context beyond what's in the file
or email you have open. In any Claude for M365 add-in, click the **+** button below
the chat input and select **Connectors** to see available options.

Common connectors used with Claude for M365 include S\&P Global, LSEG, and
Daloopa for financial data, plus any custom connectors your
organization has enabled.

<Warning>
  Custom connectors can introduce security risks. Before enabling one,
  review [Get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp)
  for guidance on what to consider.
</Warning>

## Skills

Skills you've enabled in your Claude settings are available in all
Claude for M365 add-ins. Claude applies relevant Skills automatically
based on what you're doing.

You can also invoke a Skill directly: type `/` in the sidebar to see
Skills available for the app you're in, then select one, such as
`/deck-check` in PowerPoint. Skills that aren't relevant to the current
app are excluded from this list.

See [Use Skills in Claude](https://support.claude.com/en/articles/12512180-use-skills-in-claude)
for details on enabling and managing Skills.

## Related

See the per-app guides for setup and feature details.

* [Use Claude for Excel](/docs/office-agents/excel)
* [Use Claude for PowerPoint](/docs/office-agents/powerpoint)
* [Use Claude for Word](/docs/office-agents/word)
* [Use Claude for Outlook](/docs/office-agents/outlook)

office-agents/data-storage First recorded · 229 lines, first recorded

# Data storage and retention ## Every Claude add-in shares one store ## What Claude for M365 stores ## Sign-in and credentials ## Where the data sits on Windows ## Where the data sits on macOS ## What chat history is keyed to ## Data retention ## What leaves the device ## Export a user's data before a device is rebuilt ## Related

The first capture of this source. The page was already there, and this is what it said.

# Data storage and retention

> Where Claude for M365 stores chat history, skills, and credentials on each user's device, why reinstalling or switching add-ins keeps that data, and how long it is kept.

Claude for M365 stores chat history, uploaded skills, connector registrations,
and sign-in credentials on each user's own device, in the browser storage of
the webview that Office provides. Anthropic holds no copy of this data, and
nothing syncs between devices or browsers.

A device that is rebuilt, reimaged, or handed to someone else loses this data
unless you export it first.

## Every Claude add-in shares one store

Users run more than one Claude add-in over time: the per-app store listings, an
enterprise sideload, or a custom manifest that points the add-in at your own
cloud. All of them are served from `https://pivot.claude.ai`, and browser
storage is keyed to that address. They
therefore read and write the same store on a given device.

<img src="https://mintcdn.com/claude-ai/eVVCEXIWAP0OYny8/images/office-agents/data-storage/storage-shared.png?fit=max&auto=format&n=eVVCEXIWAP0OYny8&q=85&s=ce3348a4909a88501ddad9de36cfd151" alt="Separate Claude add-in installs, each with its own add-in ID, all served from pivot.claude.ai and sharing one store that holds five IndexedDB databases and local storage" width="2506" height="856" data-path="images/office-agents/data-storage/storage-shared.png" />

The reason is the ordinary web rule. Office reads the manifest, finds the
`<SourceLocation>` URL, and opens it in an embedded browser. From that point the
browser behaves as any browser does: it hands storage to the page's address,
meaning its scheme, host, and port. The add-in's ID, version, and display name
never enter the lookup, so a manifest is closer to a bookmark than to a
container. Deleting a bookmark does not delete the site's cookies.

Two consequences follow:

* A query string is not part of an address. A third-party manifest is built for
  one organization and carries that organization's configuration in a query
  string, so no two are alike. All of them still land in the same store as every
  other install.
* Changing the address does create a new, empty store. Serving the add-in from a
  different host, a different port, or over `http` instead of `https` gives it
  somewhere else to read and write. The previous store still exists, but nothing
  reads it.

The table below gives the result for each change users and administrators
actually make.

| Change                                                                         | Result                                                                                                                                                                      |
| ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Uninstall and reinstall the same add-in                                        | Data intact                                                                                                                                                                 |
| Move to a different store listing, or to one published with a new ID           | Data intact. A new listing means a new add-in ID, not new storage                                                                                                           |
| Move from a sideloaded manifest to a store listing, or the reverse             | Data intact                                                                                                                                                                 |
| Swap the standard manifest for the custom third-party manifest, or the reverse | Storage intact, but the history list changes, because the connection mode change is an identity change. See [what chat history is keyed to](#what-chat-history-is-keyed-to) |
| Run a store install and a sideloaded manifest at the same time                 | Shared storage. Two entries in Office, one history. Remove one to avoid confusion                                                                                           |
| Bump the manifest version, or issue a new ID to clear an Admin Center cache    | Data intact                                                                                                                                                                 |
| Serve the add-in from a different host or port, or over `http`                 | A new empty store                                                                                                                                                           |
| Rebuild, reimage, or wipe the profile on the device                            | Data destroyed. Export first                                                                                                                                                |

## What Claude for M365 stores

The add-in uses five IndexedDB databases and one local storage store, all inside
the signed-in user's operating system profile. The table below lists each one
and what it is scoped to.

| Store                           | Contents                                                                          | Scoped to                                        |
| ------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------ |
| `claude-chat-history`           | Conversation transcripts, titles, timestamps, and the contents of attached files  | One user, one organization, one Office app       |
| `claude-local-skills`           | Skills the user uploaded, including any templates bundled with them               | The device profile, not the individual user      |
| `claude-mcp-gateways`           | Client registrations for connectors the user has authorized                       | The connector's address, not the individual user |
| `claude-mail-style`             | Claude for Outlook only: learned writing style, draft preferences, and scratchpad | One user                                         |
| `claude-office-snipped-results` | Working scratch for long conversations, cleared at the start of every session     | Nothing, transient                               |
| Local storage                   | Settings, onboarding and terms flags, and the active sign-in profile              | The browser profile                              |

Conversations and the Outlook writing style guide are scoped to the
individual user. Uploaded skills and connector registrations are scoped to the
storage location instead, so anyone who reaches the same store shares them. The
Windows and macOS sections below describe what splits a store on each platform.

This only applies where people share a single operating system account. That
arrangement already shares the browser profile, saved sessions, and local files
between them, so the guidance is the same as for any browser-based tool: give
each person their own operating system account.

Claude for M365 also writes one value into the Office document itself: an opaque
identifier that lets the add-in recognize the same file after a rename or a Save
As. It holds no user information and no conversation content, and it travels
with the file if the document is shared.

## Sign-in and credentials

Every store above holds only content, with one exception. Local storage also
holds the signed-in user's identity: the credential the add-in presents to the
model endpoint you configured. Cloud provider sign-ins use short-lived tokens
that the add-in renews automatically. A gateway token or API key that you
configure yourself is held until you change it.

This sits in the browser profile unencrypted, in the same way a saved web
session does. The boundary protecting it is the operating system account:
another account on the same machine cannot read it, and disk encryption covers
the device at rest. Where the deployment signs in to a cloud provider, the
credential is obtained on the device and used from the device. A gateway token
or API key that you issue centrally is distributed to every user's device, so
treat it as you would any other shared secret.

<Warning>
  An export of a user's add-in data contains these credentials as well as
  conversation text, because the export copies local storage. Treat an export
  folder as a secret, or delete the local storage folder from it before the export
  leaves the device. A rebuilt machine signs in again regardless.
</Warning>

## Where the data sits on Windows

On Windows the store is split by signed-in Office account. Local storage is one
database for the whole browser profile rather than one per address, which is the
main difference from macOS.

<img src="https://mintcdn.com/claude-ai/eVVCEXIWAP0OYny8/images/office-agents/data-storage/storage-windows.png?fit=max&auto=format&n=eVVCEXIWAP0OYny8&q=85&s=f07c4d2142ac466c8b26b3520e15b8fe" alt="Windows layout: the webview2 folder contains one folder per signed-in Office account, each holding an IndexedDB folder named after the add-in address and a Local Storage folder shared by every address" width="2506" height="1148" data-path="images/office-agents/data-storage/storage-windows.png" />

If chat history looks missing on Windows, check the signed-in Office account
before anything else. Signing back in to the original account restores the
history with nothing to copy or repair.

## Where the data sits on macOS

On macOS the store is split by Office app instead. Each app runs in its own
sandbox container, so Excel, Word, PowerPoint, and Outlook always keep separate
histories, and local storage sits inside the folder for a single address.

<img src="https://mintcdn.com/claude-ai/eVVCEXIWAP0OYny8/images/office-agents/data-storage/storage-macos.png?fit=max&auto=format&n=eVVCEXIWAP0OYny8&q=85&s=4653f674b1a4b6466e35f4df36f7c6d9" alt="macOS layout: each Office app has its own container holding one folder per address, each with an IndexedDB SQLite file and a per-address LocalStorage SQLite file" width="2506" height="1028" data-path="images/office-agents/data-storage/storage-macos.png" />

Office on the web behaves differently again. The add-in runs in a cross-origin
frame, so browsers treat its storage as third-party. Tracking prevention,
policies that block third-party cookies, and similar controls partition or evict
it. Browsers evict third-party storage on their own schedule, so treat chat
history on Office on the web as temporary.

## What chat history is keyed to

Sharing a store is not the same as sharing a history list. Each conversation is
stored against a user identity, an organization, and the Office app it was
created in. The list shows only the conversations that match all three for the
session in use.

When users sign in with a Claude account, that account is the identity. In
third-party platform deployments there is no Claude account, so the identity
comes from the Microsoft Entra ID sign-in already present in Office, as a
one-way hash of the directory object ID. Nothing about the user is stored in
readable form, and the hash is not sent to Anthropic.

Office builds without support for nested app authentication cannot supply the
Entra ID sign-in the add-in reads. On those builds Claude for M365 falls back to
a per-installation identifier. Conversations still persist on that device; they
are tied to the installation rather than to the directory account.

The table below gives the result for each case.

| Situation                                                                                           | Result                                                                                                                                                                                   |
| --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A user signs out of Claude and signs back in                                                        | The same conversations. Signing out does not change the identity                                                                                                                         |
| A different person signs in to Office on that device                                                | They see their own conversations, not the previous user's. On Office builds that fall back to a per-installation identifier, both people resolve to the same identity and share one list |
| The same person opens the add-in on a second device                                                 | No conversations. Storage is per device and does not sync                                                                                                                                |
| A user's organization changes, such as joining or leaving a team plan                               | Earlier conversations stop appearing. They remain on disk under the previous organization                                                                                                |
| A deployment moves between a Claude account sign-in and a third-party platform, in either direction | Earlier conversations stop appearing. They remain on disk under the previous identity, and the add-in has no path to reach them                                                          |

Changing connection mode is not a data loss event, because nothing is deleted,
but it is an identity change and the history list follows the identity.

One store derives identity differently from chat history. The Outlook writing
style guide has no per-installation fallback. On Office builds where the Entra
ID identity cannot be read, it falls back to a single shared key, so one learned
writing style is shared by everyone using that browser profile.

## Data retention

Claude for M365 bounds local storage in two ways, and users can clear it
themselves at any time.

| Store                           | Retention                                                                                                                  |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `claude-chat-history`           | The 50 most recent conversations per user, per organization, per Office app. Older conversations are deleted automatically |
| Any store                       | When the browser profile runs out of storage quota, the oldest conversations are deleted to make room                      |
| `claude-office-snipped-results` | Cleared at the start of every session                                                                                      |
| Everything else                 | Kept until the user deletes it or the browser profile is wiped                                                             |

Users clear their own conversations from the add-in's settings. Under "Chat
history", "Delete all" removes every saved conversation for that user in that
Office app and starts a new chat.

There is no expiry by age and no administrator-configurable retention window.
Claude for M365 also does not inherit custom data retention settings configured
for your organization. If your policy requires a retention limit on this data,
the practical control is the device profile lifecycle, such as roaming-profile
cleanup or reimaging, rather than a setting in the add-in.

## What leaves the device

The table below covers each category and its destination, so you can scope a
review to the paths that carry content off the endpoint.

| Data                                                                                        | Where it goes                                                                                                                                                                                                             |
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Conversation text, attachments, and the document content Claude is asked to work with       | The model endpoint your deployment is configured for. In third-party platform deployments that is your own Vertex AI, Bedrock, Azure, or gateway endpoint                                                                 |
| Chat history, uploaded skills, connector registrations, and the Outlook writing style guide | Nowhere. Local only, no sync, no server-side backup                                                                                                                                                                       |
| Sign-in credentials                                                                         | Only to the identity provider they belong to                                                                                                                                                                              |
| Usage telemetry sent to Anthropic                                                           | Counts, durations, and error categories. Anthropic's collector is allowlist-filtered, so it excludes conversation text, document contents, file names, and the names of your connectors and their tools                   |
| Telemetry sent to a custom OpenTelemetry collector you configure                            | The full audit trail, including prompt content and tool inputs and outputs. That path bypasses the allowlist filter by design. See [Audit and observability](/docs/office-agents/enterprise-readiness#audit-and-observability) |

## Export a user's data before a device is rebuilt

The `claude-for-msft-365-install` plugin includes read-only export scripts for
macOS and Windows. They read Office's storage and write only to the folder you
name, and running them with no arguments reports what was found without copying
anything. See
[Deploy the add-in for your organization](/docs/office-agents/third-party-platforms#deploy-the-add-in-for-your-organization)
for installation, then run `/claude-for-msft-365-install:export-data`.

Export before any of the following:

* A device is rebuilt, reimaged, or handed to another person.
* Anyone clears the Office add-in cache on Windows. The storage sits inside the
  same `Wef` folder as the manifest cache, so deleting that folder destroys chat
  history along with the manifest.
* Roaming-profile or FSLogix cleanup runs against the user's profile.
* A browser policy such as `ClearBrowsingDataOnExit` is applied to the device.

## Related

The pages below cover the deployment and security topics that reference this
data.

* [Security, admin auditability, and analytics](/docs/office-agents/enterprise-readiness)
* [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)

office-agents/dictation First recorded · 62 lines, first recorded

# Use dictation in Claude for M365 ## Use dictation ## How it works ## Why dictation is not available with third-party authentication

The first capture of this source. The page was already there, and this is what it said.

# Use dictation in Claude for M365

> Speak your prompts instead of typing them in Claude for Excel, PowerPoint, Word, and Outlook.

Dictation lets you speak prompts instead of typing them. Click the
microphone icon in the chat input, speak, and see your words appear in
the composer in real time.

<Note>
  Dictation requires the desktop version of Excel, PowerPoint, Word, or
  Outlook. It is not available in Office on the web because browser-hosted
  add-ins cannot access the microphone. On the web, use your operating
  system's built-in dictation or your Office application's dictation
  feature instead.

  Dictation is also available only for organizations using direct Claude
  authentication. It is not supported when Claude for M365 connects through
  a third-party platform such as Amazon Bedrock, Google Cloud Vertex AI,
  Azure AI Foundry, or an LLM gateway. See
  [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
  for platform support details.
</Note>

## Use dictation

<Steps>
  <Step title="Start listening">
    Click the microphone icon on the right side of the chat input. The
    placeholder changes to "Listening..." and the button highlights.
  </Step>

  <Step title="Speak your prompt">
    Words appear in the composer as you talk.
  </Step>

  <Step title="Stop or send">
    Click the microphone again to stop, or press Enter to stop and send
    in one step.
  </Step>
</Steps>

To select a different microphone, hover over the microphone icon and
click the arrow that appears.

## How it works

When you start dictating, the add-in streams your audio to Anthropic's
transcription service, the same infrastructure that powers dictation in
the Claude apps. The transcribed text displays in real time in the
composer.

Nothing is transcribed on your device. Audio is streamed to Anthropic,
which uses a contracted speech-to-text subprocessor to generate the
transcript. Audio is not retained after transcription; only the
resulting text remains in your composer.

## Why dictation is not available with third-party authentication

In third-party environments, Claude for M365 does not send prompts to
Anthropic directly. Spoken audio is effectively a prompt, so dictation
is not offered there. Use your operating system's built-in dictation or
your Office application's dictation feature instead.

office-agents/enterprise-readiness First recorded · 102 lines, first recorded

# Security, admin auditability, and analytics ## Security architecture ## Audit and observability ## Usage analytics ## Spend tracking ## Related

The first capture of this source. The page was already there, and this is what it said.

# Security, admin auditability, and analytics

> Security architecture diagrams, OpenTelemetry audit, usage analytics, and spend tracking for enterprise admins deploying Claude for M365.

Enterprise administrators deploying Claude for Excel, PowerPoint, Word,
and Outlook can review the security architecture for their chosen deployment
mode and connect audit logs, usage analytics, and spend tracking to
existing enterprise tooling.

## Security architecture

The Trust Center publishes architecture diagrams that show how user
prompts, document content, and responses flow between the Office
add-ins, Claude, and your infrastructure. Review the diagram that
matches your deployment mode before rollout.

* **Anthropic first-party**: users sign in with their Claude accounts
  and requests go directly to Claude. See the
  [first-party architecture overview](https://trust.anthropic.com/resources?s=e3n7pvyjnxjyahmdmqujcx\&name=claude-for-excel,-powerpoint,-word:-architecture-overview-%28anthropic-first-party%29).
* **Third-party platforms**: requests route through Amazon Bedrock, Google
  Cloud Vertex AI, Azure AI Foundry, or an LLM gateway. The companion
  third-party architecture diagram is listed alongside the first-party
  one in the [Trust Center resources](https://trust.anthropic.com/resources?s=e3n7pvyjnxjyahmdmqujcx);
  filter for "Claude for Excel, PowerPoint, Word".
  [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
  has per-mode request-flow diagrams for the [LLM gateway](/docs/office-agents/third-party-platforms#llm-gateway)
  and [Bedrock, Vertex AI, or Foundry direct](/docs/office-agents/third-party-platforms#bedrock-vertex-ai-or-foundry-direct)
  paths, plus deployment guidance.

## Audit and observability

Forward Claude for M365 activity to your existing observability stack with
a custom OpenTelemetry collector endpoint. When a custom collector is
configured, spans are exported unfiltered to that endpoint and include
the full audit trail: session identifiers, surface, tool inputs and
outputs, prompt content, and document references. Treat the endpoint as
containing prompt and document content when scoping access controls
and retention.

Only spans sent to Anthropic's own collector are allowlist-filtered to
strip sensitive attributes; that path is bypassed entirely when a
custom endpoint is set.

The add-in exports its telemetry from each user's browser: the taskpane
at `https://pivot.claude.ai` posts directly to the custom collector
endpoint, so every export is a cross-origin request and the endpoint
must support CORS. The endpoint must answer the `OPTIONS` preflight
with `Access-Control-Allow-Origin` covering `https://pivot.claude.ai`
and `Access-Control-Allow-Headers` covering `Content-Type` plus any
headers you configure for the export, such as `Authorization`. It must
also return the same `Access-Control-Allow-Origin` header on the `POST`
response. The [CORS requirements for an LLM gateway](/docs/office-agents/third-party-platforms#cors-requirements)
describe the same browser behavior in more detail.

Managed OTLP ingest endpoints such as Grafana Cloud are designed for
server-to-server export and generally do not answer browser CORS
preflights, so the browser blocks the export before it sends any
authentication header. Point the collector endpoint at an OpenTelemetry
Collector that you run, configure the `cors` block on its OTLP HTTP
receiver, and have the collector forward to your backend. The collector
makes the authenticated call to your backend, so no credential needs to
appear in the export headers, which reach every signed-in user's
browser.

See [Configure a custom OpenTelemetry collector for Claude for M365](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents)
for the manifest parameters and endpoint requirements.

<Note>
  The usage analytics and spend tracking sections below apply when users
  sign in with their Claude accounts directly. When connecting through a
  third-party platform such as Amazon Bedrock, Google Cloud Vertex AI,
  Azure AI Foundry, or an LLM gateway, usage and spend are tracked through
  your cloud provider's billing console and your gateway's logging instead.
</Note>

## Usage analytics

Pull Claude for M365 usage into your own BI or reporting pipeline through
the Claude Enterprise Analytics API. The API exposes per-user,
per-surface, and per-organization aggregates.

See [Claude Enterprise Analytics API reference guide](https://support.claude.com/en/articles/13703965-claude-enterprise-analytics-api-reference-guide)
for endpoints, request shapes, and aggregation windows.

## Spend tracking

Download CSV exports of Team and Enterprise plan usage from the usage
analytics dashboard in your admin console. Exports include per-seat
and per-surface spend, making them suitable for chargeback and
financial reconciliation.

See [View usage analytics for Team and Enterprise plans](https://support.claude.com/en/articles/12883420-view-usage-analytics-for-team-and-enterprise-plans)
for the steps to generate and download a report.

## Related

The pages below cover deployment paths and plugins relevant to
enterprise admins.

* [Data storage and retention](/docs/office-agents/data-storage)
* [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
* [Install financial services plugins for Cowork](/docs/office-agents/fsi-plugins)

office-agents/excel First recorded · 289 lines, first recorded

# Use Claude for Excel ## What you can do ## Get started with Claude for Excel ### Supported versions ### Install for yourself ### Deploy to your organization ### Connect through a third-party platform ## Key features ### Understand complex models ### Update values safely ### Build templates and models ### Debug errors ### Native Excel operations ## Connectors and Skills ## Set persistent instructions ## Work across M365 apps ## Context and session management ## Models available ## Data handling ## Current limitations ### Unsupported versions ## Prompt injection risk ## Best practices

The first capture of this source. The page was already there, and this is what it said.

# Use Claude for Excel

> An Excel add-in that integrates Claude into your spreadsheet workflow, for Pro, Max, Team, and Enterprise plans.

Claude for Excel is an add-in that brings Claude into Excel. Ask questions
about open workbooks, adjust assumptions while preserving formula
relationships, debug errors, and build or populate models, all without
leaving Excel.

<Note>
  Claude for Excel is generally available to Pro, Max, Team,
  and Enterprise plans.
</Note>

## What you can do

With Claude for Excel, you can:

* Ask questions about your workbook and get answers with cell-level
  citations.
* Adjust assumptions while keeping formula relationships intact.
* Identify and resolve errors and their root causes.
* Generate new spreadsheet models or populate existing templates.
* Work across multi-tab workbooks.
* Pull external context through connectors such as S\&P Global, LSEG,
  and Daloopa.
* Apply enabled Skills automatically while you work.

## Get started with Claude for Excel

### Supported versions

Claude for Excel runs on the following Excel builds.

* Excel on the web
* Excel on Windows with a Microsoft 365 subscription, build 16.0.13127.20296 or later
* Excel on Mac, version 16.46 or later, build 21011600 or later

### Install for yourself

<Steps>
  <Step title="Open the marketplace listing">
    Go to the [Claude for Microsoft 365 listing on Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/office/WA200010725?tab=Overview).
  </Step>

  <Step title="Install the add-in">
    Select "Get it now" to install.
  </Step>

  <Step title="Sign in">
    Open Excel, activate the add-in, and sign in with your Claude account.
  </Step>
</Steps>

### Deploy to your organization

Organization admins can deploy Claude for Excel through the Microsoft 365
Admin Center.

<Steps>
  <Step title="Allow Office Store access">
    In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go
    to Settings, Org Settings, User owned apps and services, and turn on
    ["Let users access the Office Store"](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-addins-in-the-admin-center).
  </Step>

  <Step title="Open Integrated apps">
    Go to Settings, Integrated apps, Add-ins.
  </Step>

  <Step title="Find the add-in">
    Search for "Claude for Microsoft 365" in Microsoft AppSource.
  </Step>

  <Step title="Deploy">
    Assign the add-in to your organization or to specific users or
    groups. Share [Microsoft's deployment guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-deployment-of-add-ins)
    with your team for activation steps.
  </Step>
</Steps>

<Note>
  If your organization uses Microsoft Entra Privileged Identity
  Management (PIM) for admin roles, the Integrated apps page does not
  recognize roles activated through PIM, so deployment fails. This is a
  [known Microsoft issue](https://learn.microsoft.com/en-us/office/dev/add-ins/resources/resources-office-add-in-known-issues),
  tracking ID 11126536. To work around it, deploy from an admin account
  with the required role assigned as permanently active rather than
  PIM-eligible. See
  [Microsoft's troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/microsoft-365/admin/miscellaneous/cannot-deploy-add-in-integrated-apps-menu).
  Individual users can still
  [install the add-in themselves](#install-for-yourself).
</Note>

After deployment, users can activate the Claude add-in from Tools,
Add-ins on Mac or Home, Add-ins on Windows, sign in, and start working.

For environments where "Let users access the Office Store" is disabled,
deploy using the custom manifest XML file instead. Download the
[Excel manifest XML file](https://pivot.claude.ai/manifest-excel.xml),
then follow
[Deploy with a custom manifest](/docs/office-agents/word#deploy-with-a-custom-manifest)
for the upload steps. The flow is identical apart from which manifest
file you upload in Step 1.

### Connect through a third-party platform

If your organization routes AI traffic through Amazon Bedrock, Google Cloud
Vertex AI, Azure AI Foundry, or an LLM gateway, your admin can deploy
the add-in without individual Claude accounts. See
[Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms).

## Key features

### Understand complex models

Ask Claude to trace assumptions, explain formulas, or walk through how a
number was derived. Answers include cell-level citations you can click
to navigate to the referenced cell.

Example prompts:

* "Walk me through how the revenue number in cell C42 is calculated."
* "What assumptions drive the gross margin forecast?"

### Update values safely

Claude updates cell values while keeping formula relationships intact,
so downstream cells recompute correctly.

Example prompts:

* "Change the discount rate to 8% and update dependent calculations."
* "Flex the growth rate from 5% to 10% and show me the impact on terminal
  value."

### Build templates and models

Populate an existing template or generate a new model from a natural
language description.

Example prompts:

* "Populate this LBO template with a \$500M purchase price and 6x
  leverage."
* "Build a three-statement model from this trial balance."

### Debug errors

Locate the root cause of calculation errors and suggest fixes.

Example prompts:

* "Find the source of the #REF! error in the summary tab."
* "Trace why cell H15 is returning #DIV/0."

### Native Excel operations

Claude can sort, filter, edit pivot tables, apply conditional
formatting, and create data validation dropdowns. Ask for these
directly.

## Connectors and Skills

Claude for Excel supports connectors for pulling external context into
your workbook, and Skills for applying reusable task recipes. See
[Connectors and Skills](/docs/office-agents/connectors-and-skills) for
details.

## Set persistent instructions

Open Settings in the add-in sidebar and use the Instructions field to
set preferences that
apply to every conversation in Excel. Instructions are useful for
formatting conventions such as "format numbers with thousand separators"
or "always bold column headers", currency or locale preferences, or
recurring context about your workflow.

Instructions you set in Excel only apply to Excel. They are separate
from Instructions you set in PowerPoint or Word.

## Work across M365 apps

Claude for Excel shares context with Claude for PowerPoint, Word, and
Outlook, so a single conversation can span your open workbook,
presentation, document, and inbox. See
[Work across M365 apps](/docs/office-agents/work-across-apps).

## Context and session management

The add-in handles long sessions and protects against accidental
overwrites for you.

* **Auto-compaction**: longer conversations are automatically compacted
  into new conversations to avoid running out of context. See
  [Understanding usage and length limits](https://support.claude.com/en/articles/11647753-understanding-usage-and-length-limits).
* **Overwrite protection**: Claude warns you before overwriting existing
  data to avoid accidental data loss.

Your use of Claude for Excel is associated with your existing Claude
account and is subject to the same usage limits.

## Models available

Claude for M365 offers a curated subset of the Claude models: the ones
that work best for Office tasks, so the list you see in the add-in can
be shorter than what you see in Claude.ai. Your organization's model
access settings also apply, and a model appears here only if your role
permits it. See
[Manage model access for your organization](https://support.claude.com/en/articles/15694740-manage-model-access-for-your-organization)
for how those settings interact with each product. If you connect
through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an
LLM gateway, the available models come from that platform and your
admin's configuration instead of your Claude.ai model access settings.
See [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
for details.

## Data handling

Inputs and outputs are deleted on the backend within 30 days of receipt
or generation, except in cases outlined in
[How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data).
Data is cached for a number of hours after deletion so users can access
context in recently closed workbooks.

Chat history is stored locally in your browser using IndexedDB.
Conversations are not stored on Anthropic's servers, are not synced
across devices, and can be cleared from Settings at any time.
Reinstalling the add-in or switching between Claude add-ins does not
remove it. See [Data storage and retention](/docs/office-agents/data-storage)
for where it sits on disk and how long it is kept.

Claude for Excel does not inherit custom data retention settings your
organization might have set. Activity is not included in Enterprise
audit logs or the Compliance API.

## Current limitations

Claude for Excel is not recommended for:

* Final client deliverables without human review.
* Audit-critical calculations without verification.
* Models containing highly sensitive or regulated data without proper
  controls.

Unsupported capabilities:

* Data tables.
* Macros and VBA operations.

### Unsupported versions

The add-in does not run on these Excel versions.

* Excel 2016 and 2019 perpetual or volume license.
* Excel on iPad. The add-in requires SharedRuntime support, which iPad
  does not provide.
* Excel on Android.
* Older builds of Microsoft 365 Excel below the SharedRuntime threshold.

## Prompt injection risk

<Warning>
  Only use Claude for Excel with trusted spreadsheets. Files from external
  sources can contain hidden instructions that manipulate the add-in into
  extracting data, modifying records, or performing destructive actions.
</Warning>

External files such as downloaded templates, vendor files, and data
imports can contain prompt injections that try to trick Claude into
taking unintended actions. Testing has identified scenarios where Claude for
Excel can be manipulated to extract sensitive information, modify
critical data, or perform destructive actions if allowed to act without
verification.

When Claude proposes a risky operation, you are asked to confirm before
it runs. Review confirmations carefully, especially for files from
external sources.

## Best practices

Follow these guidelines to use Claude for Excel safely and effectively.

* Always review changes before finalizing your work.
* Start with a trusted copy of the workbook before asking Claude to edit
  widely.
* Be specific about what you want changed.
* Verify that outputs match your organization's standards and your own
  judgment.