GitHub Copilot 添加服务器到服务器身份验证

GitHub 为使用 Copilot SDK 构建的应用程序引入了服务器到服务器身份验证，为自动化工作负载提供了一种无需依赖已登录的开发人员凭据即可访问 Copilot 的方法。

该功能于 10 月 27 日以公开预览版形式发布，使用组织上安装的 GitHub 应用程序。该应用程序获得一个短期安装令牌，并且 Copilot 的使用归属于拥有该安装的组织并对其进行计费。组织的模型政策、预算和支出控制也适用于应用程序发出的请求。

这改变了团队在内部服务、存储库自动化或面向客户的开发人员工具中嵌入 Copilot 的运营模式。身份验证现在可以代表工作负载本身，而不是碰巧授权的任何员工。

从用户凭据到应用程序身份

许多代理集成都是从个人访问令牌或与单个开发者关联的其他凭据开始的。这在原型期间可能很方便，但当集成成为持久服务时，就会产生问题。员工角色变更、凭据过期或被吊销以及审核记录可能会使自动化活动看起来像人工活动。

GitHub 的新路径使用颁发给 GitHub 应用程序的安装令牌。安装令牌的有效期很短，其范围取决于应用的安装和权限，这使得它们比长期用户凭据更适合无人值守的工作负载。

这种区别对于治理很重要。组织可以识别负责 Copilot 消耗的应用程序，而不是将每个请求都归因于名义操作员。 GitHub 在 AI 使用情况 CSV 报告中包含 app_client_id 字段，允许所有者在分析过程中区分应用程序的使用情况。

对于为开发者团队构建AI API控制平面的团队，这是一种有用的身份模式：人类用户、自动化帐户和已部署的应用程序不应共享无法区分的凭据或结算记录。

以这种方式验证的请求会消耗组织的 Copilot 津贴，并受其现有模型政策、预算和支出控制的约束。这让管理员可以决定应用程序可以使用哪些模型以及组织允许多少 AI 总支出。

这也意味着应用所有者无法将服务器到服务器的访问视为独立的容量池。繁忙的集成可以从与其他符合条件的 Copilot 活动相同的组织预算中提取。团队需要监控自动消耗以及交互式使用，并决定事件、重试和意外请求循环应如何影响共享限制。

当前预览版不支持为每个应用或安装设置单独的预算。 app_client_id 字段可以帮助进行追溯归因，但按应用程序报告并不等于强制执行特定于应用程序的硬性上限。需要隔离的组织在自动化工作负载之前可能仍然需要自己的计量层或AI API团队支出控制。

采用该功能的开发者必须创建 GitHub 应用程序，将其安装在相关组织上，并用应用程序的凭据交换安装令牌。然后，应用程序在通过 Copilot SDK 调用时使用该短期令牌。因此，部署系统必须处理令牌颁发和续订，而不是无限期地存储静态开发者令牌。

操作记录应保留GitHub应用程序身份和为每个请求收费的组织。这对于为多个组织提供服务的平台尤其重要：为一个安装颁发的令牌不得重复用于路由另一客户的工作负载，并且应根据正确的租户协调使用情况导出。

该模型也会影响离职。删除一名开发人员不再需要禁用组织拥有的集成，同时卸载 GitHub 应用程序或更改其权限可以提供对应用程序本身的更直接的控制。实际结果是劳动力身份和工作负载身份之间的更清晰分离。

服务器到服务器身份验证仍然是公共预览版，因此GitHub可能会在正式发布之前更改其合同。 GitHub尚未宣布支持通过此身份验证路径进行企业级安装或个人帐户。

缺乏每个应用的预算是最直接的控制差距。组织可以查看哪个应用程序产生了使用情况，但他们尚无法为每个应用程序或安装分配独立的 Copilot 预算。随着公司在一个组织下部署多个编码代理、审查服务和存储库自动化，这一点变得更加重要。

即使有这样的限制，该版本仍为机器生成的 Copilot 流量建立了更清晰的所有权模型。身份验证、政策和计费现在附加到已安装的应用程序及其组织，为持久自动化创建了比借用的开发人员凭据更可靠的基础。