GitHub App に最小権限の新スコープ、リポジトリ作成権限を分離

何が発表されたか

• repository_creation:write（fine-grained PAT / GitHub App）：リポジトリの削除・移譲まで含む広範な repository_administration:write を付与せずに、リポジトリ作成だけを許可できる。作成者は新しいリポジトリへのアクセス権を得るが、Appのインストールには引き続きOrganization管理者の操作が必要。
• installation_repositories:write（同）：Organization内の任意のインストールに対し、リポジトリの追加・削除ができる。呼び出すユーザーはOrganizationオーナーまたはリポジトリ管理者である必要がある。従来、関連APIは粗い repo スコープを要求していた。
• リポジトリ管理者によるインストール追加：Organizationレベルで承認済みのAppについて、リポジトリ管理者がオーナー承認なしに自分のリポジトリを追加できるようになった。リポジトリ作成・リポジトリ管理・Organizationレベルの各権限は引き続きオーナー承認が必要で、オーナーは設定でこの挙動をブロックできる。
• Credentialsタブ：Appの認証情報が専用タブに集約され、Client secretsとKey pairsのセクションに分かれた。今後のworkload federation認証情報にも備える。
• Get an app API：同一オーナー配下のApp、同一Enterprise内のinternal App、Enterprise所有AppからのOrganization所有Appの参照が可能になり、自動監査がしやすくなった。
• offline_access スコープ：GitHub Appが有効期限付きアクセストークンと併せてリフレッシュトークンを受け取れる。無期限トークンから期限付きトークンへ段階的に移行するための仕組み。

提供状況：offline_access はGHES 3.23、その他はGHES 3.24に含まれる。

開発者への影響

AIエージェントにGitHubを触らせる構成が普通になってきた今、この変更の価値は「エージェントに渡す鍵を小さくできる」点にある。これまで「リポジトリを新規作成する」だけのために repository_administration:write（削除・移譲込み）を渡していたケースは珍しくないが、暴走や誤操作が起きたときの被害範囲が致命的だった。repository_creation:write に差し替えれば、最悪ケースが「余計なリポジトリが増える」で止まる。

受託案件での実務としては、(1) 既存のGitHub App／PATの権限を棚卸しし、作成目的のものを新スコープに置き換える、(2) offline_access を導入して無期限トークンの残存をなくす、(3) repository_administration:write を持つ自動化が残っている場合は、誰が・何のために使っているかを一覧化する——この順で進めるのが現実的だ。

クライアント企業のセキュリティレビューで「AIエージェントにどこまで権限を渡しているか」を問われる場面は確実に増える。権限表を1枚持っておくだけで通りが変わる。