AIエージェントにGitHubを操作させると開発作業を大いに効率化できますが、認証情報が流出すると一大事です。リスクと効率のバランスをどのように取るべきなのか、当社の整理をご説明します。
４つの手法
GitHubへのアクセス権をAIに与える手法を当社では４つに分類しています。
- Human In The Loop
- プロキシ利用
- GitHub App
- 直接トークン
それぞれ一長一短があり、すべてに勝る方式はありません。
| モデル | 基本方式 | 漏洩時の権限の寿命 | 効率性 | 流出リスク |
|---|---|---|---|---|
| HITL(Human In The Loop) | AIがアクセスできない場所から人間がghなどで操作を実行 | （AIにPAT/tokenを渡さない） | 人手が常に必要 | ありえない |
| プロキシ利用 | PATを格納したプロキシに中継させる | （AIにPAT/tokenを渡さない） | 使えるツールが限定され不便 | ありえない |
| GitHub App | GitHub Appが短命トークンを発行。それをAIが利用する | 短命 | 高い | ありえるが悪用リスクは限定的 |
| 直接トークン | PATをAIに直接付与 | 長命 | 高い | ありえる |
※ 流出リスクについて: 上記はあくまでAIによるPAT流出リスクについての評価です。オペミス等別の要因は除きます。
使い分け
- 極めて高いセキュリティを求められており、わずかな問題の可能性すら許容しがたい -> HITL
- AIによるPRスパム程度は問題ない。しかしPAT漏洩リスクの可能性は一切許容できない。あるいは諸事情でGitHub Appが使えない -> プロキシ
- 他の施策と合わせればインシデント発生時の被害を許容範囲内に抑えられる -> GitHub App
- 漏洩してもさして問題ない環境（実験用など）である -> PAT直渡し
利用方法
HITL
AIにコマンドを生成させたり、テキストを作らせて、人間が手動で操作します。直接AIが作業することがないため、AIによる流出はありえません。
プロキシ利用
PAT/Tokenをプロキシに配置し、AIがアクセスできないようにします。AIはHTTP経由でGitHub APIを呼ぶだけです。理屈は難しくなく、docker-composeでDevContainerを起動してサイドカーにNginxを使い、環境変数でPATを読み込ませるだけでも利用できます。AIにPATを見せなくてよいため流出リスクはほぼありませんが、できることが限られます。
GitHub App
トークン生成用環境（サイドカーコンテナやAWS Lambdaなどを利用）を用意し、そこでGitHub Appの秘密鍵を使って短命トークンを発行させる方式です。AIエージェントは生成された短命トークンを利用してアクセスします。万一トークンが流出してもすぐ時間切れとなるためリスクを大きく軽減できます。利便性とセキュリティのバランスを取った方式です。
- GitHub Appsを登録
- トークンを生成し、AIエージェントに渡す。秘密鍵を使う方式のほか、ブラウザ経由で認証する方式もある。
- AIエージェントはトークンを利用してGitHubを操作する。
直接トークン付与
環境変数を経由してPATをDevContainerに渡します。もっとも手間がかからず高効率ですが、万一PATが流出してしまうとタイムアウトがない分、悪用のリスクが4方式の中で最も大きいです。
こう書くと劣悪な方式と思われるかもしれませんが、個人的な実験を行っているだけで漏洩リスクを許容できる環境なら手間が少なく良い手法です。言うまでもなく強すぎる権限を持たせたキーは使ってはいけません。
備考
- 上記いずれの方式を取ったとしても、最小権限の原則など他の方策も併用すべきです。