Copilot SDK 支持服务间认证：Read-only 权限也能花掉组织额度

把智能体放到后台服务里，认证就不该一直依赖某位开发者保持登录。但换成应用身份之后，谁可以调用、费用记到哪里、失控时如何停下来，都需要重新确认。

GitHub 在北京时间 2026 年 10 月 28 日凌晨宣布，Copilot 支持组织安装 GitHub App 的服务间认证，目前是公开预览。使用 Copilot SDK 构建的服务可以持短期安装令牌代表组织发起请求，不再依赖已登录用户的凭据。一个容易误读的细节是，所需权限名为 Read-only，但它依然允许应用消耗组织的 AI 额度。

应用身份与费用归属一起改变

本次支持的流程是给 GitHub App 添加组织级 Copilot Requests 权限，设为 Read-only，将应用安装到目标组织，再把安装访问令牌交给 Copilot SDK。

请求归属于拥有这次安装的组织，费用也由该组织承担。模型能否使用，仍受组织的 Copilot 模型策略约束；预算和支出控制也继续生效。管理员指南面向 Copilot Business 和 Enterprise 的组织所有者，不能把这项能力当作所有个人套餐的通用后台调用接口。

这里既改变认证来源，也改变归账方式。如果原服务之前使用开发者自己的登录凭据，迁移后不能只检查请求是否成功，还应确认报告中的组织和应用归属符合预期。

Read-only 是该 API 权限的名称，不是“不会改变任何状态或产生费用”的保证。它授权应用发起会消耗额度的模型请求。审查应用时，需要同时看它能读取什么、能执行什么，以及被允许花费谁的额度。

企业安装与组织安装不能混用

几天前 GitHub 宣布企业级 GitHub Apps 安装正式可用，主要扩展企业治理和管理接口。此次 Copilot 服务间认证使用的是组织安装，二者不是同一条权限路径。

当前管理员文档明确排除了个人账号安装和企业级安装。即使某个应用已经装到企业、能够管理企业设置，也不能直接把那份安装令牌拿来当作组织的 Copilot 身份。

使用场景	认证与权限入口	需要区分的规则
GitHub Actions 之外的服务或 CI	组织安装的 GitHub App，Copilot Requests 为 Read-only	组织需支持该安装令牌认证方式
组织仓库中的 GitHub Actions 工作流	内置 GITHUB_TOKEN，copilot-requests: write	适用 Actions 专属策略和预算路径
已登录用户发起请求	用户认证	依照用户的 Copilot 访问与归属处理

SDK 文档对 GitHub Actions 推荐使用内置 token，无需额外创建 GitHub App 或保存一份长期认证秘密。但它要求组织启用 Allow use of Copilot CLI billed to the organization 策略。组织安装 App 的服务间认证路径则不要求开启这个策略。

不能因为两条路径都能代表组织调用，就把权限名称、策略开关和计费方式混成一套配置。尤其不要为排查服务间认证失败，先把所有 CLI 和 Actions 策略都打开。

令牌要传到真正使用它的运行时

组织安装令牌在一小时后过期。创建令牌时，官方示例使用的权限字段是：

{
  "permissions": {
    "organization_copilot_requests": "read"
  }
}

取得令牌只是前半段。SDK 与运行时如何连接，决定凭据应当传到哪里。

官方 TypeScript 示例使用显式的 gitHubToken 配置，并关闭已登录用户凭据的自动发现。下面是同样用途的配置片段，不包含真实凭据，也不是完整可直接运行的服务：

import { CopilotClient, RuntimeConnection } from "@github/copilot-sdk";

const token = process.env.INSTALLATION_TOKEN;
if (!token) throw new Error("INSTALLATION_TOKEN is required");

const client = new CopilotClient({
  connection: RuntimeConnection.forStdio(),
  gitHubToken: token,
  useLoggedInUser: false,
});

useLoggedInUser: false 不只是禁止读取本机登录状态。文档说明，它会关闭自动凭据发现，包括环境变量中的 token。因此，不能只在宿主进程里设置 COPILOT_GITHUB_TOKEN，又关闭自动发现，却不传 SDK 的显式 token 选项。

连接已有运行时 URI 时，文档要求把 COPILOT_GITHUB_TOKEN 配置在运行时进程上。宿主进程与运行时进程可能不在同一个容器或机器上，不能默认前者的环境变量会自动传给后者。

这也是排查“本机能用，部署后未认证”的一个具体方向：确认究竟哪个进程发送请求、实际读取哪份配置，以及有没有意外回退到个人身份。调试时只记录必要的身份标识和状态，不要输出完整 token 或环境变量清单。

长期服务不能只在启动时取一次 token

一小时有效期意味着，服务运行时间超过令牌寿命后必须更新认证。应用注册凭据与短期安装令牌的保护也应分开考虑，短期令牌过期并不能抵消应用私钥泄露的风险。

当前 SDK 指南的更新方式很具体：在令牌到期前签发新令牌；使用子进程运行时时，用新令牌重启 SDK client；进程内运行时或已有运行时连接，则按文档重启持有凭据的宿主运行时。

因此，不能把“后台可以无人登录运行”理解为“启动后永远无需管理凭据”。生产接入前要验证令牌到期、运行时重启以及未完成任务如何处理，不应假定 SDK 会自动把一份新环境变量注入已有进程。

本文没有实际调用付费模型或部署这段配置。这里的流程来自当前文档，SDK 参数和刷新行为仍可能在公开预览期间调整。

有预算，不一定会停止支出

组织安装应用的用量计入组织 Copilot 预算。当前文档明确说明，不能为单个应用或单次安装建立独立预算。

这会影响多个应用共用组织额度时的风险判断。一个应用循环重试或任务堆积，可能影响其他使用方。组织级预算可以限制整体支出，却不能替代服务自己的任务队列、并发限制和重试上限。

还要区分告警预算与阻止预算。仅发送通知的预算不会停止花费；需要到限停止请求时，应确认 Stop usage when budget limit is reached 已启用。具体配置应由管理员结合业务连续性要求审批，不能为了测试随意修改共享预算。

归账和停用需要事先验证

官方支持通过 AI usage CSV 报告中的 app_client_id 识别应用归属。当前指南说明，这种归属信息在 CSV 导出中，而非 GitHub 上的 AI usage 页面。

管理员可以将报告中的 app_client_id 与组织应用安装列表里的 client_id 对应，用 app_slug 识别具体应用。这个字段为空也不能直接解释成“没有调用”，因为用户、GitHub Actions、其他 GitHub 自有应用，以及归属字段推出前的历史用量，都可能没有这个值。

要停止某个安装继续访问，可以暂停或卸载该应用。但这同时会影响它对其他组织资源的访问，不只是阻止 Copilot 请求。若同一个应用还负责发布或仓库管理，停用操作的影响范围应提前梳理。

比较稳妥的试点是选择用途单一、权限明确的应用，完成一次正常调用、一次令牌更新和一次归账核对。然后验证不允许的模型确实被策略限制、停用后服务能正确处理认证失败，再逐步扩大任务范围。

结语

服务间认证让 Copilot SDK 的后台任务有了不依附个人登录的身份，但它也把权限审批、费用归属和运行时凭据管理摆到了同一个流程里。

接入时先确认安装目标，再验证令牌传递和更新，最后检查预算、报表与停用效果。请求成功只说明链路跑通，不能代替这些运行边界的核验。

参考来源

• GitHub Changelog：GitHub Copilot supports server-to-server authentication，发布于 UTC 2026 年 10 月 27 日 21:36，北京时间 10 月 28 日 05:36。用于核对公开预览、组织应用身份、权限和费用归属。
• GitHub Docs：Server-to-server authentication，用于核对 SDK 配置、Actions 路径、运行时凭据传递及一小时令牌的更新方式。
• GitHub Docs：Manage GitHub Apps that use your organization’s Copilot，用于核对安装限制、预算、CSV 归属和停用范围。

资料核对日期为 2026 年 10 月 28 日；功能处于公开预览，权限、配置和控制台行为可能随后续版本变化。