社内でAIエージェントに「この資料を読んでまとめて」「顧客からの問い合わせを見て下書きして」を任せ始めた会社は、もう珍しくありません。ここで一度立ち止まってほしいことがあります。そのエージェントが読み込む文書やWebページ、問い合わせ本文の中に、悪意ある指示が紛れ込んでいたら、どうなるかです。AIは、あなたの命令と、たまたま読んだテキストに書かれた命令を、確実には区別できません。
これが絵空事でないことを、2026年7月に公表された「GitLost」という実例が示しました。攻撃者は 公開されたGitHubのIssueに一文を仕込むだけ で、GitHubのAIエージェントに私有リポジトリの中身を読ませ、それを公開コメントに書き出させることに成功しています。コードを書く必要も、パスワードを盗む必要も、書き込み権限すら要りませんでした。この「間接プロンプトインジェクション」という抜け穴の構造と、社内でAIに作業を任せる会社が導入前に決めておくべきことを整理します。
GitLost が示したこと
セキュリティ企業 Noma Labs が2026年7月6日に公表した「GitLost」は、GitHubのエージェント型ワークフローに対するプロンプトインジェクション攻撃です。手口はこうです。攻撃者は、ごく普通に見える 公開Issue の中に、AIエージェント向けの隠された指示を書き込みます。エージェントがそのIssueを読むと、隠された指示に従って 私有リポジトリの中身を読み取り、公開コメントとして投稿してしまう ——という実証がなされました（InfoQ、Noma Security）。
重要なのは、攻撃者に必要だったのが「公開Issueを一つ開ける」ことだけだった点です。サーバーには一切触れず、盗んだ認証情報も、対象への書き込み権限もいりません（The Register）。これは単純なバグというより、AIエージェントの設計そのものに潜むリスクのパターン だと説明されています。認証情報を渡す側のリスクは AIエージェントに認証情報を渡す前に で扱いましたが、今回は毛色が違います。正規の権限を持ったエージェントが、外部の文章に操られて、その権限を悪用させられるという話です。
なぜフィルタでは防げないのか
「危険な入力をフィルタで弾けばいい」と考えたくなりますが、間接プロンプトインジェクションはそれでは止まりません。理由はこの攻撃の成立条件にあります。信頼できない外部テキスト・私有データへのアクセス・公開できる出力先——この三つが揃うと、それだけで情報が漏れる経路ができあがるからです。
AIエージェントは、あなたが与えた指示も、読み込んだIssueやWebページに書かれた指示も、同じ「テキスト」として受け取ります。人間なら「これは他人が書いた怪しい文だ」と気づけますが、エージェントには両者を確実に見分ける仕組みがありません。だから「悪意ある一文を弾く」フィルタをすり抜ける言い回しは無限に作れてしまう。この性質は、MCP のようにエージェントを外部のデータやツールへつなぐほど広がります。つなぎ先が増えるほど、エージェントが「他人の書いた指示」を読み込む機会も増えるからです。
だから対策の軸は、注入そのものを検知することではなく、注入が起きても被害が出ない構造にすること——具体的には、権限の絞り込み・処理の隔離・人による確認・公開出力の制限——に置く、というのが専門家の共通見解です。
自社のAIエージェント運用で気をつけること
自社でAIエージェントに業務を任せるなら、次の三点を運用の前提に組み込みます。
第一に、エージェントに渡す権限を最小にする。「念のため広めに」は禁物で、その業務に本当に必要な範囲だけに絞ります。私有データへの読み取りと、外部への書き出しの両方を同時に持たせるほど、漏洩経路は作りやすくなります。第二に、外部から来る文章はすべて「敵かもしれない入力」として扱う。問い合わせ本文、取り込んだWebページ、他人が書いたIssueやコメント——これらにエージェント向けの指示が仕込まれている前提で設計します。第三に、公開・外部送信の一歩手前に人の確認を挟む。エージェントの出力がそのまま社外や公開先へ流れる経路を作らないことが、最後の砦になります。
| 守りどころ | 具体策 |
|---|---|
| 権限 | 業務に必要な最小権限だけ付与。読み取りと外部出力の両立を避ける |
| 入力 | 外部由来のテキストは敵性入力として扱う |
| 出力 | 公開・外部送信の前に人のレビューを挟む |
導入・発注時に確認する統制
外部にAI活用や自動化を発注する場合も、確認すべき勘所は同じです。「エージェントにどの範囲の権限を与えるのか」「どこからの入力を、どこまで信用する設計なのか」「エージェントの出力が人の確認なしに外へ出る経路はないか」。この三つを設計段階で明文化できているベンダーかどうかが、任せて安全かの分かれ目になります。加えて、AIに何を渡してよいかの線引きは 業務データがどこの国のサーバーへ行くのか の観点ともセットで詰めておくと、抜けが減ります。
まず決めるべきは「権限」と「出力先」
GitLostが突きつけたのは、AIエージェントは便利さと同じだけ、操られたときの被害範囲 を持つということです。そして被害範囲を決めるのは、モデルの賢さではなく、あなたが与えた権限と、出力が流れる先の設計です。ここを最小に絞ることが、注入を弾こうとするどんな対策よりも効きます。
社内でAIエージェントを安全に運用する設計、あるいは発注先の統制をどう見極めるか。相談したい場合は 開発・AI・自動化のご相談 からお問い合わせください。権限設計と出力経路の見直しを軸に、事故を前提とした安全な運用をご提案します。
