What this read moved
1–3 of 3government/security/security-and-data-handling Changed · +3 / -7 lines
from line 92
9292
9393### Approvals and Auto mode
9494
95By default, Claude for Government prompts the user for connector actions, for each web search, and, in Cowork, when Claude asks to add another folder to the session. In Chat and Cowork, Claude's file tools do not write outside the attached folders and the session's working folder, as described under [Sandbox and isolation](#sandbox-and-isolation). 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 for each command** and **Require approval for each fetch** 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.
95By default, Claude for Government prompts the user for connector actions, for each web search, and, in Cowork, when Claude asks to add another folder to the session. In Chat and Cowork, Claude's file tools do not write outside the attached folders and the session's working folder, as described under [Sandbox and isolation](#sandbox-and-isolation). 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 for each command** and **Require approval for each fetch** sub-settings on the [Config](/docs/government/config/settings#tool-and-connector-cards) page. In Chat on Claude Desktop versions earlier than 2.110.0, 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.
9696
9797<AccordionGroup>
9898 <Accordion title="Can write and send actions be gated behind approval?">
from line 106
106106 </Accordion>
107107
108108 <Accordion title="Can individual shell commands be allowlisted enterprise-wide?">
109 Not in Chat or Cowork. Administrators can turn the built-in **Web search**, **Web fetch**, and **Shell commands** tools on or off, or require approval on every use, but cannot allowlist individual commands within those tools. 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. Code sessions follow Claude Code's own permission rules, which your agency can set in a Claude Code managed-settings file. See [Code in Claude Desktop](#code-in-claude-desktop).
109 Not in Chat or Cowork. Administrators can turn the built-in **Web search**, **Web fetch**, and **Shell commands** tools on or off, or require approval on every use, but cannot allowlist individual commands within those tools. In Chat, an approval for a shell command covers that one command, 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. Code sessions follow Claude Code's own permission rules, which your agency can set in a Claude Code managed-settings file. See [Code in Claude Desktop](#code-in-claude-desktop).
110110 </Accordion>
111111
112112 <Accordion title="Can users suppress approval prompts with an Always allow choice?">
113 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 on the Config page. Turning on the **Require approval for each search**, **Require approval for each fetch**, or **Require approval for each command** sub-setting on the **Web search**, **Web fetch**, or **Shell commands** card forces a fresh prompt on every use of that tool. A connector tool that an administrator has switched on under **Tool policy** also prompts on each use, without an **Always allow** choice. The Microsoft 365 connector's read tools keep each user's own choice, and its write actions never offer **Always allow**. The create-artifact prompt and code execution in Chat are exceptions: neither offers a standing approval. See [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards) and [Connectors](/docs/government/connectors/overview) for the available settings.
114 </Accordion>
115
116 <Accordion title="Why does Chat prompt on every analysis step?">
117 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).
113 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 on the Config page. Turning on the **Require approval for each search**, **Require approval for each fetch**, or **Require approval for each command** sub-setting on the **Web search**, **Web fetch**, or **Shell commands** card forces a fresh prompt on every use of that tool. A connector tool that an administrator has switched on under **Tool policy** also prompts on each use, without an **Always allow** choice. The Microsoft 365 connector's read tools keep each user's own choice, and its write actions never offer **Always allow**. The create-artifact prompt is an exception: it offers no standing approval. See [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards) and [Connectors](/docs/government/connectors/overview) for the available settings.
118114 </Accordion>
119115</AccordionGroup>
120116
third-party/claude-desktop/admin-console Changed · +28 / -1 lines
### Choose how users authenticate to your provider #### When a helper script is the right choice #### Managed MCP servers that need authentication
from line 97
9797| **Appearance** | Banner text and colors, end-user attribution, and whether the app shows feature announcements and configuration deprecation warnings |
9898| **Plugins** | The [plugin marketplaces](#plugin-marketplaces) that users' apps fetch, and how each one installs |
9999
100The console stores no API keys, tokens, or secrets, and refuses them anywhere in the configuration, including in request headers and MCP server settings. Users authenticate to your provider with an interactive sign-in, a cloud credential profile, or a [credential helper](/docs/third-party/claude-desktop/credential-helper) on the device, and a managed MCP server that needs a secret takes the path of a helper script that exists at the same path on every device.
100The console stores no API keys, tokens, or secrets, and refuses them anywhere in the configuration, including in request headers and MCP server settings. Users authenticate to your provider on the device, as described under [Choose how users authenticate to your provider](#choose-how-users-authenticate-to-your-provider).
101101
102102Most of these settings can also differ per group of users, on the **Permission policies** page under **People**, as described under [Per-group permission policies](#per-group-permission-policies).
103
104### Choose how users authenticate to your provider
105
106<Tip>
107 Choose an interactive sign-in wherever your provider offers one. It is the recommended credential kind for a deployment managed from the console. Users sign in inside the app with their own accounts, and there is no shared credential to distribute to devices or rotate.
108</Tip>
109
110The console never holds a provider credential. The **Credential kind** field on the **Connection** page tells Claude Desktop how each user's device obtains one, and offers the kinds your provider supports: **Interactive sign-in** in the app, **Workforce Identity** (Google Cloud's Agent Platform only), **Cloud vendor profile** (an AWS profile or Google Cloud credentials file already on the device), or **Helper script** (a [credential helper](/docs/third-party/claude-desktop/credential-helper) on the device). Static API keys and bearer tokens aren't offered, because the console refuses to store them. The same **Connection** settings go to every user, so a credential kind that depends on something present on each device works only if your device management puts it there.
111
112| Provider | Recommended credential kind | Credential fields on the **Connection** page | What users do at first launch |
113| ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
114| [LLM gateway](/docs/third-party/claude-desktop/gateway#single-sign-on-with-your-identity-provider) | **Interactive sign-in** with your identity provider | **Gateway SSO IdP (OIDC)** with your identity provider's issuer URL and the client ID of the application you registered for Claude Desktop | The app shows a **Sign in to your organization** button that opens your identity provider's sign-in page in the browser. After sign-in, the app sends that user's token to your gateway on every request, and your gateway validates it. |
115| [Amazon Bedrock](/docs/third-party/claude-desktop/bedrock#in-app-aws-sign-in) | **Interactive sign-in** through IAM Identity Center | **AWS SSO start URL**, **AWS SSO region**, **AWS SSO account ID**, and **AWS SSO role name** | The app shows a **Sign in with AWS** page and the user approves in the browser. No AWS CLI is needed. |
116| [Google Cloud's Agent Platform](/docs/third-party/claude-desktop/vertex#in-app-google-sign-in), users with Google accounts | **Interactive sign-in** with Google | **Vertex OAuth client ID** and **Vertex OAuth client secret** from a Desktop-app OAuth client in your own Google Cloud project. Google doesn't treat a Desktop-app client secret as confidential, so the console accepts it. | The app shows a **Sign in with Google** page and the user approves Google's consent screen in the browser |
117| [Google Cloud's Agent Platform](/docs/third-party/claude-desktop/vertex#in-app-workforce-identity-sign-in), users who sign in with another identity provider | **Workforce Identity** | **Workforce Identity audience** and **Workforce Identity IdP (OIDC)** with your identity provider's issuer URL and client ID | The app shows a **Sign in** page and the user signs in to your identity provider in the browser. No Google identity is needed. |
118| [Microsoft Foundry](/docs/third-party/claude-desktop/foundry#in-app-entra-id-sign-in) | **Interactive sign-in** with Microsoft Entra ID | **Entra ID tenant ID** and **Entra ID client ID**, and optionally **Entra ID sign-in flow** | The app shows a **Sign in with Microsoft** page and the user signs in with a device code, in the browser, or through the operating system's account picker |
119| [Bedrock Mantle](/docs/third-party/claude-desktop/mantle) | **Helper script**, because Mantle has no interactive sign-in | **Helper script** with the absolute path of a script that prints the bearer token | The app shows no sign-in page and runs the script whenever it needs a token |
120
121Tokens from these sign-ins are stored only on the user's device. The linked provider pages cover setup at the provider, network egress, and session lifetime for each option.
122
123#### When a helper script is the right choice
124
125Choose **Helper script** for Bedrock Mantle, or when the credential for your gateway or provider can only come from tooling that runs on the device, such as an internal secret broker. The console stores the script's path, not the script, and the same path goes to every device in the organization. Install the script at that absolute path on every device through your software distribution, in a location that users can't modify, for example `/usr/local/bin/corp-cred-helper` on a macOS fleet or `C:\Program Files\Corp\cred-helper.cmd` on a Windows fleet. Claude Desktop runs the script under the user's operating-system account, so anything that differs per user, such as reading that user's home folder or keychain, belongs inside the script.
126
127#### Managed MCP servers that need authentication
128
129A managed MCP server that supports OAuth needs nothing on the device. Set **OAuth** on the server's entry on the **Connectors** page to **Auto-register (dynamic client registration)** or **Bring your own client**, and Claude Desktop signs each user in through the browser, as described under [OAuth sign-in](/docs/third-party/claude-desktop/extensions#oauth-sign-in). For a server that needs a secret, such as a confidential OAuth client secret, a request header that carries a token, or environment variables for a local server, enter the absolute path of a helper script on the device that prints it, in the **Client secret helper script**, **Headers helper script**, or **Environment helper script** field. The [`managedMcpServers` schema](/docs/third-party/claude-desktop/configuration#managedmcpservers) describes each script's output format. Install that script at the same absolute path on every device, as with the inference helper script.
103130
104131### Localhost base URLs
105132
government/config/settings Changed · +1 / -1 lines
from line 172
172172
173173The **Web fetch** card controls whether Claude can fetch web pages in Claude Desktop. It is on by default, and fetches are subject to the Allowed network hosts list above. A **Require approval for each fetch** sub-setting sits below the toggle. Turning it on asks the member to approve every page fetch before it runs; when it is off (the default), each member chooses whether to approve fetches or allow them automatically.
174174
175The **Shell commands** card controls whether Claude can run shell commands during tasks in Claude Desktop. It is on by default, and turning it off also turns off Advanced file analysis in Chat. A **Require approval for each command** sub-setting sits below the toggle. Turning it on asks the member to approve every shell command before it runs; when it is off (the default), each member chooses whether to approve commands or allow them automatically. Chat always asks before each command regardless of this setting.
175The **Shell commands** card controls whether Claude can run shell commands during tasks in Claude Desktop. It is on by default, and turning it off also turns off Advanced file analysis in Chat. A **Require approval for each command** sub-setting sits below the toggle. Turning it on asks the member to approve every shell command before it runs; when it is off (the default), each member chooses whether to approve commands or allow them automatically. On Claude Desktop versions earlier than 2.110.0, Chat asks before each command regardless of this setting.
176176
177177The **Microsoft 365** card lets members reach your agency's Microsoft 365 content, including SharePoint, OneDrive, Outlook, and Teams, from Claude Desktop. Each member signs in with their own Microsoft account. Enter the **Tenant ID** and **Client ID** from an application you register in Microsoft Entra, choose the **Azure cloud** your Microsoft tenant is in, and select which Microsoft Graph permissions to allow under **Access**. The connector is off while Tenant ID and Client ID are both blank. See [Set up the Microsoft 365 connector](/docs/government/connectors/microsoft-365) for the full walkthrough.
178178