GitHub AIエージェントはどう乗っ取られるのか――公開Issueが生む情報漏えいリスク

GitHub の agentic workflow は、Issue 対応やコメント生成を自動化する便利な仕組みとして注目されている。しかし Noma Security が報告した GitLost の事例は、その便利さがそのまま攻撃面にもなることを示している。

何が起きたのか

報告によると、この workflow は issues.assigned イベントで起動し、Issue のタイトルと本文を読み取ったうえで add-comment ツールを使って返信する。さらに、組織内の他リポジトリにもアクセスでき、公開リポジトリだけでなく private リポジトリまで読める設定だったという。

攻撃者に特別な資格情報や高度な技術は不要で、組織所有の公開リポジトリに Issue を立て、そこへ隠し指示を入れるだけでよい。Noma は、防御策が置かれていても、ある語句「Additionally」がモデルの意図しない挙動を引き起こし、制限付き情報を公開コメントに出してしまう可能性を示した。

この事例が示すポイント

• プロンプト注入はモデル単体の失敗ではない。 実行権限と接続先が広いほど、誤解釈はそのまま漏えいにつながる。
• 危険なのは賢さではなく権限の広さ。 多すぎるコンテキスト、複数リポジトリ、過剰なトークンが攻撃価値を高める。
• ユーザー入力は命令として扱うべきではない。 Issue やコメントは、システム指示から分離する必要がある。
• 公開先の制限が重要。 敏感な内容を、公開コメントとして再出力してはいけない。

影響と対策の方向性

この件は、AI セキュリティを「モデルの性能」ではなく「ワークフロー設計」の問題として捉え直す必要があることを示している。私有リポジトリは、それ自体では安全境界にならない。そこへ到達できるエージェントがいるなら、境界はすでに崩れ始めている。

実務上は、権限を最小化し、入力と命令を分離し、公開出力に厳しい制限をかけることが不可欠だ。そうしなければ、AI エージェントは作業の自動化ではなく、情報流出の経路になりかねない。

InfoQ 中文