Copilot app 支持 BYOK 后，团队别只忙着接模型；endpoint、key、数据路由、模型分工、审计回退要先写清。

BYOK 最容易让团队误判的一点是：以为接上自己的模型，就等于数据边界也自然清楚了。

GitHub 在 2026-06-23 的 Changelog 里说明，GitHub Copilot app 支持 bring your own key。团队可以在 Copilot app 里添加 OpenAI、Azure OpenAI、Microsoft Foundry、Anthropic、LM Studio、Ollama 或 OpenAI-compatible endpoint。添加后，provider 的模型会出现在 model picker 里。GitHub 还说明，keys 存在本地 OS keychain，并且不会被 UI 读回。

这对工程团队很有吸引力。

但 BYOK 不是“随便接一个模型”。它会把 endpoint、密钥、数据路由、模型选择和审计责任带进本地 agent 工作流。

先写 5 个边界。

一、endpoint 边界

第一条不是选模型，而是写清 endpoint。

你要知道：

• 这个 endpoint 属于谁的云账号或内网网关。
• 是否允许访问外部网络。
• 是否有区域或 tenant 限制。
• 是否支持日志脱敏和访问审计。

如果只是“先填一个能跑的地址”，后面排查数据流向会非常痛苦。

二、key 边界

GitHub 说明 key 存在本地 OS keychain，这比明文配置安全。

但团队仍然要写清：

• 谁有权新增 provider。
• key 是否来自个人账号还是团队账号。
• key 泄露后如何轮换。
• 离职或设备丢失时如何吊销。

不要让 BYOK 变成每个开发者都自己接一套不可审计的密钥。

三、数据路由边界

BYOK 的价值之一，是把 inference route 到自己的 cloud account、tenant 或 internal gateway。

但要落到规则：

| 数据类型 | 可用模型/网关 | 禁止事项 | | --- | --- | --- | | 公共代码 | Copilot-hosted 或团队 provider | 不带入私有凭据 | | 内部业务代码 | 企业网关或指定 cloud tenant | 不发到个人 key | | 客户/生产数据 | 脱敏样本或禁止进入 agent | 不直接复制真实数据 | | 安全问题 | 指定安全审查模型和日志 | 不绕过审计 |

没有这张表，团队很容易只讨论“哪个模型强”，却没人管“哪些数据能去哪”。

四、模型分工边界

GitHub 的说明里提到，你可以把 frontier model 和 local/self-hosted model 混用。

这很实用，但也要写分工：

• 复杂设计和跨文件推理用高能力模型。
• 本地执行、敏感代码草稿和低风险批处理用本地或自托管模型。
• 安全审查、发布变更、权限修改必须固定到经过批准的模型和流程。

不要让 model picker 变成“今天谁顺手就选谁”。

五、审计和回退边界

最后一条是很多团队会漏掉的：

如果 BYOK provider 出错，如何回退？

至少写清：

• 哪些任务可以自动切回 Copilot-hosted model。
• 哪些任务必须停止等待人工确认。
• provider 响应、失败原因、模型选择是否需要记录。
• 什么时候需要复盘成本、质量和数据边界。

BYOK 上线不是一次性配置，而是持续治理。

工具和资源建议

• GitHub Copilot app BYOK：用于接企业、云端或本地模型 provider。
• OS keychain：确认 key 不进入 repo、日志或配置明文。
• 模型路由表：按数据类型和任务类型决定 provider。
• 回退规则：provider 不可用时，哪些任务能切换，哪些必须停止。

今天就做这一步

如果你们准备给 Copilot app 接 BYOK，不要先讨论“接哪个模型”。先写一页边界：endpoint 属于谁，key 谁管理，哪些数据能去哪，哪些任务用哪个模型，失败时怎么审计和回退。