One read of Claude Documentation

 
     **The gateway MUST validate `iss` AND `aud`, not just the signature.** Signature + issuer alone accepts *any* token from the same tenant, including tokens issued to unrelated apps. In `id_token` mode the audience is the `clientId`:
 
-    ```yaml theme={null} theme={null} theme={null} theme={null}
+    ```yaml theme={null} theme={null} theme={null} theme={null} theme={null}
     # LiteLLM example — `audience` is REQUIRED, not optional
     general_settings:
       litellm_jwtauth:

 
     **Extended context** (`supports1m`) is a capability assertion you make about your deployment; only set it for models you've confirmed support the 1M-token window:
 
-    ```json theme={null} theme={null} theme={null} theme={null}
+    ```json theme={null} theme={null} theme={null} theme={null} theme={null}
     [{"name": "claude-sonnet-5", "supports1m": true}, "claude-opus-4-8"]
     ```
 
     **Default to 1M context** (`prefer1m`) makes the 1M-context variant the default picker selection when this entry is the default model (the first entry); users can still switch to the standard variant, and an explicit user pick is always kept. No effect without `supports1m`. Under dynamic discovery (no explicit list), the equivalent flat key in the **Models** group applies instead:
 
-    ```json theme={null} theme={null} theme={null} theme={null}
+    ```json theme={null} theme={null} theme={null} theme={null} theme={null}
     [{"name": "claude-opus-4-8", "supports1m": true, "prefer1m": true}]
     ```
 
     **Display label** (`labelOverride`) is for IDs the picker can't derive a friendly name from (Bedrock ARNs, gateway routing aliases). Display-only; `name` is still what the app sends:
 
-    ```json theme={null} theme={null} theme={null} theme={null}
+    ```json theme={null} theme={null} theme={null} theme={null} theme={null}
     [{"name": "arn:aws:bedrock:us-east-1:123:application-inference-profile/abc", "labelOverride": "Claude Opus (Prod)"}]
     ```
 
     **Tier mapping** (`anthropicFamilyTier`) tells the app which Claude tier (`haiku`/`sonnet`/`opus`/`fable`/`mythos`) an entry stands in for, so bare tier aliases (e.g. in Code sessions) resolve to your model. `isFamilyDefault: true` picks the winner when several entries share a tier:
 
-    ```json theme={null} theme={null} theme={null} theme={null}
+    ```json theme={null} theme={null} theme={null} theme={null} theme={null}
     [{"name": "us.anthropic.claude-opus-4-8", "anthropicFamilyTier": "opus"}]
     ```
 

   <Accordion title="orgPluginSettings details">
     Applies `toolPolicy` locks to MCP servers that arrive via the org-plugins directory, keyed by server name. Either shape is accepted; when hand-authoring a profile, use the legacy record shape until your fleet floor parses the canonical array form:
 
-    ```json theme={null} theme={null} theme={null} theme={null}
+    ```json theme={null} theme={null} theme={null} theme={null} theme={null}
     {"mcpServers": {"internal-search": {"toolPolicy": {"delete_document": "blocked"}}}}
     ```
 

 Each [`managedMcpServers`](#managedmcpservers) entry can carry a `toolPolicy` that locks the approval state per tool:
 
 * `"allow"` — the tool runs without prompting.
-* `"ask"` — the user approves every call; no standing grants are offered.
+* `"ask"` — the user approves every call; no session-scoped or standing grants are offered.
 * `"blocked"` — the tool is removed from Claude's session; connector settings show it as blocked by your organization.
 
-Tools with no policy entry stay user-controlled (built-in connectors apply default policies to some tools — see the reference above): the user is prompted and can approve once or grant a standing approval, depending on the tool and your organization's settings. Full prompt options require version 1.22209.0 or later; earlier third-party builds offered only per-call approval. The reference above also documents an `"ask-session"` value; its once-per-session behavior is not yet functional in shipped builds, so don't rely on it yet. Managed policies take precedence over user grants, and enforcement happens in the desktop host process, not only in the prompt UI. A deny-by-default posture — `"*": "blocked"` plus exact `"allow"` entries for approved tools — works from an upcoming release, which also supersedes the Code-session wildcard-precedence note in the reference above. See the [`managedMcpServers` reference](#managedmcpservers) for wildcard matching, precedence rules, and built-in connector defaults.
+Tools with no policy entry stay user-controlled (built-in connectors apply default policies to some tools — see the reference above): the user is prompted and can approve once, approve for the rest of the task (offered for tools that can modify data), or grant a standing approval unless [`mcpPersistentAlwaysAllowEnabled`](#mcppersistentalwaysallowenabled) is `false`. Full prompt options require version 1.22209.0 or later; earlier third-party builds offered only per-call approval. The reference above also lists an `"ask-session"` value; it is accepted for compatibility and behaves exactly as `"ask"`. Managed policies take precedence over user grants, and enforcement happens in the desktop host process, not only in the prompt UI. A deny-by-default posture — `"*": "blocked"` plus exact `"allow"` entries for approved tools — is supported, including in Code sessions (where an allowed tool still gets Claude Code's own approval prompt). See the [`managedMcpServers` reference](#managedmcpservers) for wildcard matching, precedence rules, and built-in connector defaults.