OpenAI、11月20日からAIゲートウェイに承認を義務付け

職場で使うAIアシスタントはGPTへの直接接続のように見えるかもしれないが、画面の裏側で別の企業がリクエストを処理している可能性がある。従業員が目にするのは回答であり、モデルへのアクセスを提供するサービスを目にすることはほとんどない。

11月20日から、OpenAIは同社のモデルへの直接アクセスを第三者に提供するAIモデルルーターとゲートウェイに、事前承認の取得を義務付ける。この変更により、仲介業者を通じて企業とAI技術をつなぐサービスに対する新たな監督が導入される。

こうした仲介業者を利用する企業にとって、この変更は2つの疑問を生む。利用するプロバイダーがOpenAIのモデルを提供する認可を得ているか、そして企業のデータや認証情報をどれだけ安全に扱っているか、という点だ。

OpenAI、モデルプロバイダー全体で一貫したセーフガードを求める

OpenAIは10月21日の発表で、顧客が同社のモデルに直接アクセスする場合だけでなく、ホスティングパートナーや再販業者を通じてアクセスする場合にも、安全対策をどう適用すべきかを説明した。参加するサービスには同等の基準を維持することが期待されており、ユーザーが制限を回避するためにプロバイダーを単純に乗り換えられないようにする。

このアプローチには、モデルへのアクセスの各段階に応じた複数の対策が含まれる。

• 導入前。モデルはリスク評価を受け、セーフガードを回避しようとする試みに対するテストが行われる。信頼済みアクセスプログラムでは、一部の高度な機能について利用資格の条件も定める。
• 利用中。監視によって不正利用の可能性を特定し、パートナーは疑わしい活動を調査し、違反が発生した場合に措置を講じることが求められる。
• 執行後。顧客が根本的な問題に対処すれば、制限は再検討される可能性がある。現在開発中のSafetyIDは、モデル開発者に身元を明かすことなく、調査中に個々のエンドユーザーを区別するのにも役立つ可能性がある。

プライバシーも別の考慮事項だ。OpenAIは Private Safety Processingについて、関連するやり取り全体から不正利用の可能性を検知しつつ、基となる顧客コンテンツをOpenAIの担当者に開示しない方法として挙げた。9月22日の更新では、API顧客へのアクセス提供を段階的に開始したと説明している。

承認ルールでゲートウェイと一般的なAIアプリを区別

改訂されたUsage Policiesは、第三者にOpenAIのモデルへの直接アクセスを提供するプラットフォームに適用される。AIゲートウェイは共通の接続を通じてリクエストを中継し、企業がモデルごとに統合を管理することなく異なるAIシステムと連携することを可能にする。このような仲介アクセスを提供するサービスは、事前承認を取得しなければならない。

GPTを自社製品に組み込むアプリケーションは、扱いが異なる。例えば、カスタマーサポート用アシスタントや文書生成ツールは、技術を利用することだけを理由に承認を必要としない。既存の契約上の許可は引き続き適用され、従来のポリシーは11月20日まで有効だ。

発表には承認済みゲートウェイのリストは含まれておらず、既存の仲介業者が11月20日までに審査を申請する方法も説明されていない。

eWeekが明らかにしたこと：ゲートウェイ攻撃が示す、承認では防げないリスク

AI仲介業者が侵害された場合にOpenAIの計画する監督がどう役立つ可能性があるかを調べるため、eWeekはLiteLLMに関する最近の実例を調査し、3月のセキュリティ開示、その後のセキュリティ改善、さらに10月21日のインシデント報告を検証した。調査では、顧客がAIモデルに接続するために信頼しているソフトウェアに、繰り返し発生するセキュリティ上の露出が見つかった。

10月のインシデントで配布されたマルウェアは、認証情報を盗み、リモートコード実行を可能にした。特に懸念されるのは、LiteLLMの正規のGitHubソースタグには悪意あるファイルが含まれていなかったことだ。攻撃者は自ら管理する別のリポジトリから感染したリリースを構築していた。影響を受けた顧客には、アクセス可能なシークレットが侵害されたものとして扱うよう指示が出されたが、プロジェクトの非公開エンタープライズ版は影響を受けなかった。

盗まれたプロバイダーの認証情報がその後、疑わしいモデルリクエストに使用された場合、OpenAIの計画は役立つ可能性がある。承認済みの仲介業者との連携により、参加サービス全体での調査と執行を支援できるほか、リクエストにSafetyIDが付随していれば、正当なユーザーの識別にも役立つ可能性がある。しかし、いずれの対策も、ダウンロードしたゲートウェイソフトウェアの完全性を単独で検証することはできない。この区別は、 意図された境界を越えたAIの挙動に関するOpenAIの開示においても重要だ。問題の調査に役立つ情報は、それ自体で問題を防ぐものではない。

LiteLLMのインシデントと承認判断との間に確立された関連性はないが、認可だけではゲートウェイのセキュリティを保証できない理由を示している。

11月20日までに、企業はゲートウェイプロバイダーに対し、承認要件が自社のサービスに適用されるか、どのような認可を保有しているか、そして審査によってOpenAIモデルへの継続的なアクセスが影響を受ける可能性があるかを確認すべきだ。発表では、プロバイダーごとに異なるこうした疑問への答えは示されていない。

セキュリティチームはまた、ゲートウェイがアクセス可能な認証情報、ソフトウェアのリリースを承認できる人物、侵害後にアクセスを無効化して信頼できるデプロイメントを復旧する方法を明確にすべきだ。 クラウドおよびアイデンティティのセキュリティ評価の結果は、最初の侵入と併せて、過剰な権限や露出した認証情報を精査する必要性を裏付けている。

調達チームにとって実務上の意味は、ベンダー審査の範囲が広がることだ。AIモデルを選ぶことは、そのモデルを提供する仲介業者を評価することも意味する。プロバイダーの認可、ソフトウェアのリリース管理、インシデント対応のそれぞれについて、裏付けとなる証拠を確認すべきだ。

さらに読む：Nvidia、GPUクラスターにAIを活用した監視を導入。Minervaは、ワークロードを中断させる前にインフラの問題を検知するよう設計されている。