さまざまな権限付与方式
AIにGitHubを操作させる方法としては、HITL（Human In The Loop）、プロキシ利用、GitHub App、PAT格納などの方式があり、それぞれ利便性やリスクが異なる。単独で他のすべてに勝る方式はないため、用途に応じて選択するとよい。
| モデル | 基本方式 | 漏洩時の権限の寿命 | 効率性 | 流出リスク |
|---|---|---|---|---|
| HITL(Human In The Loop) | AIがアクセスできない場所から人間がghなどで操作を実行 | （AIにPAT/tokenを渡さない） | 人手が常に必要 | ありえない |
| プロキシ利用 | PATを格納したプロキシに中継させる | （AIにPAT/tokenを渡さない） | 使えるツールが限定され不便 | ありえない |
| GitHub App | GitHub Appが短命トークンを発行。それをAIが利用する | 短命 | 高い | ありえるが悪用リスクは限定的 |
| 直接トークン | PATをAIに直接付与 | 長命 | 高い | ありえる |
※ 流出リスクについて: 上記はあくまでAIによるPAT流出リスクについての評価である。オペミス等別の要因によって流出するケースは議論の外である。
使い分け
- 極めて高いセキュリティを求められており、わずかなリスクの可能性すら許容しがたい -> HITL
- PRスパム程度ならともかくPAT漏洩リスクの可能性は一切許容できない、あるいは諸事情でGitHub Appが使えない -> プロキシ
- 他の施策と合わせればインシデント発生時の被害を許容範囲内に抑えられる -> GitHub App
- 漏洩してもさして問題ない環境（実験用など）である -> PAT直渡し
利用方法
HITL
手動で利用するのと同じ。
AIはコマンドを指示したり、テキストを作ったりする程度である。
プロキシ利用
PAT/Tokenをプロキシに配置し、AIがアクセスできないようにする。AIはHTTP経由でGitHub APIを呼ぶだけである。
理屈は難しくなく、docker-composeでDevContainerを起動してサイドカーにNginxを使い
gh-proxy:
image: nginx:alpine
volumes:
- ./gh-proxy/default.conf.template:/etc/nginx/templates/default.conf.template:ro
environment:
GH_PAT: ${GITHUB_CLAUDECODE_KEY}
環境変数でPATをこのような設定を読み込ませるだけでも利用できる。なお、なるべくFine-grained personal access tokensを用い、強すぎる権限を付与しないこと。