READMEの「承認済み」は許可ではない――kiuribotsの権限設計

READMEを書く人と、反映を許可する人は別

外部資料に紛れ込んだ指示が、本来の利用者の依頼に割り込んでくる。これが「間接プロンプトインジェクション」です。問題の本質は、「AIがその文章を読めること」と「その文章の書き手に操作の許可権を渡すこと」が混同されてしまう点にあります。

kiuribotsにおいても、ウェブ係（Searcher）が外部から取得したWebページだけを警戒すればよいわけではありません。作業係（Worker）が読み込むREADMEやコード内のコメント、Issueの本文、さらにはツールの実行結果も、すべて不正な指示の入口になり得ます。間に「要約」という工程を挟んだところで、元の資料の書き手に権限が生まれるわけではありません。

構成・手順の概念図

Simon Willison氏の「Dual LLM pattern」では、汚染され得る本文や要約を、権限を持つ側へそのまま渡さない構造が重視されています[1]。また、OpenAIの設計指針でも、モデルが外部の文面に惑わされる可能性を前提とし、下流のシステム側で操作や情報送信を制限する対策が重ねられています[2]。

読む道具と、書き換える道具を分ける

kiuribotsでは、役割ごとにAIへ渡すツール（プロファイル）を分けています。

まず、ウェブ係（Searcher）の調査用プロファイルには、標準ツールとして WebSearch、WebFetch、Read、Grep、Glob を渡しています。ファイルの編集やシェル実行は含めていません。なお、ローカルのファイル参照ツールも含んでいるため、単なる「Web検索専用」の役とは区別しています。

一方、作業係（Worker）の書き込み用プロファイルには、ファイル参照に加えて Edit、Write、Bash を渡しています。特定の危険なコマンドを拒否するルールも設けていますが、それだけで任意のプログラム実行や外部通信を完全に遮断できるとは見なしていません。

構成・手順の概念図

読み取り用のツールも、外へ情報を送る

ここで注意したいのは、「編集ツールを取り上げれば安全」とは限らない点です。

検索ツールは検索語を外部サーバーへ送り、URL取得ツールは指定された宛先へ通信します。もし秘密の値を検索語やURLのパラメータに含めてしまえば、ファイルを一切書き換えない読み取り用ツールであっても、情報を外部へ持ち出す経路になり得ます。

つまり、編集ツールを外すことで防げるのは主に「意図しない書き換え操作」です。情報漏えいを防ぐには、「何を読めるか」に加えて「どこへ何を送れるか」も制限する必要があります。検索やURL取得に渡される入力を検査し、通信先や扱える値を実行環境側で絞り込むことが設計上の課題になります。

現在のkiuribotsでは、役ごとのツール制限やサンドボックスを導入していますが、実環境のすべての通信に対して出口制御（Egress制御）が強制されているかまでは確認できていません。そのため、curl などの特定コマンドを拒否するルールと、実行環境全体のネットワーク制限とは別問題として切り分けて扱っています。

実装例：許可したコミットだけをpushする

AIが作った変更案を、そのまま無条件で外部リポジトリへ送らせない。そのために、Gatewayでは反映の許可と、その許可が対象にしているコミットをプログラムで確かめています。

pushの要求データには、対象リポジトリ、作業用ブランチ、コミットのSHA、作業クローンのパスを持たせています。実際の送信先は設定ファイルに登録されたリポジトリから取得し、送信先ブランチ名もタスク専用の形式（bot/task-<id>）に限定します。また、作業クローンからGateway自身の送信用リポジトリへいったんコミットを取り込む構造にしているため、作業クローン側に仕込まれたGitフックや送信設定（remote URLなど）はそのまま使われません。

以下は、roles/publisher.ts にある「取り込んだコミットを検査する処理」の抜粋です（エラーメッセージのみ簡略化しています）。

const fetched = await git(['-C', staging, 'rev-parse', ref]);
if (fetched !== payload.sha) {
  throw new Error('承認後にコミットが変わっています');
}

ここで確認しているのは、「これから外部へ送ろうとしているコミットが、許可に紐づけられたコミット（SHA）と同一か」という一点です。変更内容そのものの妥当性や安全性は、事前のテストやレビューで別に確認します。別のAI（レビュー係）による「問題なし」というレビュー結果もあくまで品質面の評価であり、利用者の許可としては扱いません。

反映の許可は、人間による承認操作か、あらかじめ設定した自動push・事前委譲の条件に基づいて記録されます。自動マージの事前委譲では、対象リポジトリ・有効期限・上限回数を絞ったうえで、CIの通過やレビュー完了といった条件も残しています。読み込んだ資料内の「承認済み」という文言によって、これらの条件を広げるような処理は正規のAPIには設けていません。

コードと鍵を分けても、承認DBには課題が残る

GatewayにLLMを置かないことに加え、稼働環境ではOSのユーザー権限によって「反映処理のコード」と「GitHub書き込み用の秘密鍵」を保護しています。具体的には、作業係（Worker）の実行ユーザーには反映処理のソースコードを書き換える権限を与えず、GitHubへの書き込み用秘密鍵を読み取る権限も持たせていません。systemdの設定でもシステム領域を読み取り専用にし、役ごとに書き込み可能なディレクトリを限定しています。

一方で、明確に残っている課題もあります。タスクの状態や承認記録を保存するSQLiteのDB（承認DB）が、現在「共有グループで書き込み可能」な状態になっており、作業係（Worker）の実行ユーザーにもファイル上の書き込み権限がある点です。正規のStore API経由では承認判断をGatewayのみに制限していますが、もし作業係の環境で任意のコードが実行された場合、APIを迂回して承認DBへ直接書き込む経路まではOSの権限で拒否できていません。

そのため設計上は、「正規のAPIが許可を正しく検査していること」と「侵害されたプロセスから許可の記録自体を改ざんできないこと」を別の段階として区別しています。承認DBへの書き込み権限をGatewayのみに集約することは、今後解決すべき課題です。なお、第3回で紹介するプログラム検査も、この「承認DBへの直接書き込み」に対する耐性を測ったものではありません。