AI 時代の権限管理

このスライドの作り方

Claude Opus と おしゃべりして 作りました。

• 思いつくまま話す
• Opus が聴衆役で質問する
• 答えた内容もスライドに反映

マルチエージェントが当たり前に

• 仕事をエージェントに任せる
• 何体も並列で動かす
• 一晩放置して回すことも

じゃあ、権限はどうする?

危ないのは「3つが揃う」とき

1. 権限の強さ

2. 権限の広さ

3. 実行時間の長さ

強くて広い権限を持ったエージェントが 一晩 動き続ける — これが危ない

3つを1体に集めない

エージェントに 上下関係 を作る

• 長時間動く → 権限は狭く弱く
• 強い権限 → 短く、判断だけ
• 広い権限 → 持たせない

全体の構造

末端: プロジェクトエージェント

自分のディレクトリだけ

アクセス権がプロジェクトの中に 閉じていれば 全部お任せ で OK

長時間の作業はサンドボックスで

実際に一晩働くのはこの層

気をつけるのはネットワーク

特にアウトバウンド

公開リポジトリに機密情報を 書き出してしまう事故が起こりうる

読むのは OK、書くのはブロック

書き出しが必要になったら

末端は 自分では書かない、依頼を出すだけ

上司エージェントの役割

• 依頼を AI 的にチェック
• 判断してゲートキーパーへ回す
• それ以外は何もしない

Web アクセス禁止

上司がプロンプトインジェクションを 受けないことが一番大事

ゲートキーパー

自分が管轄するリソースの権限 だけ を持つ

• GitHub 専用
• Slack 専用
• Web 書き出し専用
  • ドメインのホワイトリストを持つ

依頼は「決まった形式」で

• 自由文ではなく構造化した依頼
• 形式から外れたものは弾く
• 依頼文経由のインジェクションを防ぐ

承認はだんだん自動に

1. 初めてのパターンは 人間が許可
2. 同じパターンは AI が自動で許可
3. パターンから外れたら 人間に聞く

ネットワークはホワイトリスト

• 最初に 50 個くらいドメインを決める
• それ以外にはアクセスしない

それでも残る難所が GitHub

GitHub の縛り方

プロジェクト ↔ リポジトリを厳密に紐づけ

紐づいたリポジトリ以外には触れない

末端には書き込みトークンを渡さない

• 公開リポの読み取りはトークン不要
• 書き込みは必ずゲートキーパー経由
• トークン管理はゲートキーパー 1 か所

なぜ末端にトークンを渡さないか

• Fine-grained PAT で絞る手もある
• でも今の GitHub では AI からトークンを発行できない
• プロジェクトごとの発行・更新は人間の手間

→ 書き込み権限は ゲートキーパーに集約

聴衆からの質問(作成時に Opus から)

Q. 上司は依頼文経由で騙されない?

依頼を決まった形式にして弾く

Q. どこで人間が承認する?

パターンから外れたときだけ

Q. 紐づいたリポが公開リポだったら?

末端は書けない。書くのはゲートキーパーだけ

まとめ

• 強さ・広さ・時間を 1体に集めない
• 末端はディレクトリとサンドボックスに閉じる
• 上司は Web に触らず 判断だけ
• 外への書き出しはリソースごとの ゲートキーパー 経由
• ネットワークはホワイトリスト