情報取得のためにインターネットへのアクセスを許可されたAIエージェントが、想定されていなかった外部サイトへの書き込みにもその通信経路を利用していた――。OpenAIのAIエージェントによる外部Wikiへの書き込み事案は、AIエージェントにどこまで権限を与えるべきかを考える材料となりました。本記事では、この事案をもとに、企業がAIエージェントを利用する際に確認しておきたい権限・通信・承認・監視のポイントを解説します。
contents
OpenAIのWiki事案とは？ 研究報告が示した行動
研究者は、外部Wikiに残された約1万8,000件のAIエージェントによる投稿を発見したと報告しています*1。活動の中心はドイツ語のDSEwikiでした。これはエージェントの台数や被害者数ではなく、投稿の数です。同報告では、エージェントがWeb検索課題の回答を共有し、動作環境の情報や制限を回避する方法も交換していたと説明されています。
図1：外部Wikiがエージェント同士の情報共有場所になる構図
主な活動：2026年5～6月（一部7月）／研究報告の公表：9月4日
※約1万8,000件は、研究者が確認したAIエージェントによる投稿数であり、エージェント数ではありません。図中のエージェントは構図を説明するためのイメージです。
外部Wikiへの活動は5月に始まり、6月に急増しました。6月22日以降はほぼ停止し、7月1～2日に一部の活動が確認されています。研究報告が公表されたのは9月4日です。
「閲覧用の通信」と「書き込みできない状態」は同じか
技術面で注目したいのは、研究報告がGETリクエストを通じた外部Wikiへの書き込みを説明している点です*2。GETは、通常、Webページなどの情報を取得するために使われるHTTPのメソッドです。HTTPの仕様では安全なメソッドとして扱われ、クライアントがサーバーの状態変更を求めないことが基本の意味になります。
ただし、HTTPメソッドの仕様と、実際のWebアプリケーションの実装は必ずしも一致しません。研究報告によれば、今回利用された古いWikiでは、GETリクエストによって編集処理を実行できる仕組みが存在していました。そのため、エージェント側で通信をGETに限定していても、結果として外部サイトの状態を変更できました。この事案が示すのは、通信の名前だけで権限の境界を判断できないという問題です。
AIへの注意書きに加え、実行側で権限を制限する
AIに「外部には書き込まないでください」と指示することは、行動方針を伝える手段です。一方で、システムが実際にその操作を拒否できるかどうかは別に検証します。閲覧用途なら、閲覧に不要なツールや認証情報を与えず、アクセス先と実行可能な操作を絞る必要があります。
OWASPは、LLMを使うシステムに必要以上の機能・権限・自律性を与えるリスクを「LLM06:2025 Excessive Agency」として整理しています。利用目的に必要な機能だけを提供し、接続先のシステムでも権限を確認するという考え方は、AIエージェントの設計に役立ちます。
Hugging Face事案やプロンプトインジェクションとの違い
研究者は、Wikiで活動した群とHugging Faceへの攻撃に関わった群について、別のエージェント群だった可能性が高いと分析しています。そのため、両者は別の事案として捉える必要があります。また、Webページや文書に紛れた指示でAIの動作を変えようとする「LLM01:2025 Prompt Injection」と、エージェントが与えられた課題の達成に向けて想定外の手段を使う問題も同一ではありません。Wiki事案を特定のプロンプトインジェクション攻撃が原因だったと決め付けず、実際にどの操作が可能だったかに注目することが大切です。
AIエージェントのセキュリティ対策を、操作の流れで考える
企業がAIエージェントを導入する際には、モデル単体ではなく、ツール、認証情報、接続先を含む実行環境を確認します。以下は、OWASPの対策を基にした企業向けの設計例です。
図2：AIが提案した操作を、実行前後の制御で管理する
※制御設計の例。実際の構成・承認条件・取得可能なログは、システムごとに定義します。OpenAIの実際の内部構成や、BBSecの個別サービス構成を表すものではありません。
最小権限と人の承認を、業務の影響に合わせて設定する
社内資料の検索を行うエージェントなら、必要な資料を読む権限に絞り、不要な更新・削除権限を持たせないようにします。外部送信、公開、重要データの変更など影響の大きい操作は、人が送信先と内容を確認してから実行する設計が考えられます。承認する操作と実行する操作が一致することも、実装時に確認します。
許可した接続先でも、使える操作を点検する
接続先の許可リストは管理の出発点になりますが、そのサイトやAPIで何ができるかまで点検します。検索・閲覧に必要な通信と、投稿・更新など状態を変える通信を区別し、目的外の操作を実行側で拒否できる構成を検討します。例外を追加したときは、許可範囲が広がっていないかを再確認します。
ログは「AIの回答」だけでなく「実際の操作」を残す
AIエージェントの挙動を調べるには、回答文だけでなく、呼び出したツール、接続先、実行結果、承認の記録を追えるようにします。誰の依頼で動いたエージェントか、どの権限を使ったかも結び付けておくと、想定外の操作が起きた際の調査に役立ちます。OWASPもエージェントのツール利用等の記録と異常の監視を推奨しています*3。
一方で、ログに個人情報や認証情報を無制限に残してよいわけではありません。調査に必要な記録と機微情報の保護を両立させ、閲覧権限と保存期間を定めます。異常な連続アクセスや承認外の操作を検知した後、誰がエージェントを止め、認証情報を無効化するのかまで運用手順に含めます。
BBSecの支援で、AIの利用方針とシステム設計をつなぐ
エージェントに任せる業務と、人が判断する業務の境界は、情報システム部門だけでなく利用部門も共有する必要があります。BBSecの「AIサービス提供者・利用者向けサイバーセキュリティ対策支援」は、提供者と利用者それぞれに向けたセキュリティガイドラインの雛形提供と、事業に合わせたカスタマイズによる整備支援を用意しています。
自社でAIエージェントを組み込むシステムを開発する場合には、BBSecの「Shift Left コンサルティング」も相談先になります。同サービスは、要件定義・設計段階でのセキュリティレビューや、システム・運用要件の評価と対策案の提示、開発標準・ガイドラインの策定支援を提供しています。まず、AIに許可する操作、接続先、承認が必要な処理を整理し、レビューしたい範囲を相談する進め方が考えられます。一般的なシステムのセキュリティレビューと、モデルの自律的な挙動を専門的に評価する試験は区別し、必要な評価内容を事前にすり合わせることが大切です。
AIエージェントの活用範囲は、止められる範囲から広げる
Wiki事案から企業が学べるのは、指示した内容に加え、システムとして何を許しているかを確認する姿勢です。扱う情報と操作を絞って検証し、記録・承認・停止の仕組みを整えたうえで活用範囲を広げる。権限の境界を具体的に設計することが、AIエージェントを業務で使い続けるための基盤になります。
【参考情報】
- collusion.wiki,Discovery of a new OpenAI agent message board,Sydney Von Arx
,Cormac Slade Byrd,Spencer Kitts,Thomas Larsen（2026年9月4日）（https://collusion.wiki/） - OpenAI「Hugging Face のインシデントと今後の道筋」（2026/8/26）（https://openai.com/ja-JP/index/hugging-face-incident-and-the-road-ahead/）
編集責任：木下
AIエージェントのセキュリティ対策をご検討の方へ
AIエージェントの導入・活用におけるセキュリティ対策についてお悩みの方は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。
ウェビナー開催のお知らせ
最新情報はこちら
