allowedProviders：限制本机可用的 API 提供商
同一台开发机上，有人走官方 Anthropic API，有人设 ANTHROPIC_BASE_URL，还有人切 Bedrock / Vertex——对个人方便，对合规与账单边界却是隐患。CLI 2.1.285 增加托管设置 allowedProviders：限制某台机器允许使用的 API 提供商，从而减少非预期的外部调用。
它管的是「可以连哪类后端」，不是「可以用哪个模型 ID」。模型白名单仍看 availableModelsMatch 一类配置。
能管住什么
changelog 列出的提供商范围包括（以当前版本为准）：
- Anthropic API
- 自定义端点（custom endpoint）
- Amazon Bedrock
- Mantle
- Google Vertex AI
- Foundry
- Claude Platform on AWS
- Cloud gateway
写成托管策略后，机器上的 Claude Code 只能走名单内的提供商；名单外的配置即使本机写了环境变量，也应被拦住，而不是静默外呼。
典型使用场景
- 企业笔记本只许走公司网关：
allowedProviders只放自定义端点 / Cloud gateway，禁止直连公有云控制台账号。 - 云厂商专机：某批机只许 Bedrock 或只许 Vertex，避免开发者临时改
BASE_URL把流量打到别处。 - 外包 / 共享机房：缩小「这台机器理论上能打到哪些 LLM 后端」的攻击面与误配面。
- 与模型管控叠用：提供商白名单 + 模型 exact / deny，两层一起收。
个人自用、且只有一个官方账号时，未必需要开；有 MDM / managed-settings 的团队收益最大。
和相近设置怎么分工
| 设置 | 管什么 |
|---|---|
| allowedProviders | 允许哪些提供商 / 通道类型 |
| availableModels / exact / deny | 允许哪些模型 ID |
| 沙箱 / 权限模式 | 本机文件与命令能不能跑 |
| 网关相关环境变量 | 具体 URL、提示头等怎么连（仍须落在 allowedProviders 内） |
常见误区：以为关掉某个模型 ID 就等于禁止走 Bedrock——其实提供商仍可切换；要锁通道，用 allowedProviders。
落地时注意
- 走托管设置通道（MDM / managed-settings 文件等），不要只写进可被用户随意改的项目本地文件就当「策略已生效」。
- 先盘点现网：团队是否已有 Bedrock、Vertex、自建网关；名单过窄会导致「升级后全员起不来」。
- 变更要可回滚：收紧前留应急提供商，并在发布说明里写清「本机只许 X」。
- 和代理文档对齐：国内兼容网关若映射为「自定义端点」或「Cloud gateway」，名单里要用对条目名，避免名实不符。
具体 JSON 字段名与枚举值以当前 CLI / 托管文档为准；升级后用最小会话验证：名单内能聊、名单外应失败且提示清晰。
小结
- 2.1.285 新增托管设置
allowedProviders，限制本机可用的 API 提供商。 - 覆盖 Anthropic API、自定义端点、Bedrock、Mantle、Vertex、Foundry、Claude Platform on AWS、Cloud gateway 等。
- 与模型白名单互补：一个锁通道，一个锁模型。
有多通道环境的团队，升级后优先评估是否写入托管策略，再谈个人偏好配置。