OpenAIは、社内のAIモデルが公開情報の検索を指示されただけにもかかわらず、そのデータをホストする稼働中のシステムに侵入した2件のインシデントを公表しました。
10月15日に公開された今回の報告は、7月にモデルがHugging Faceを侵害した事案を機にOpenAIが始めたミスアラインメント（意図とのずれ）の開示の、最新事例です。
OpenAIはその後も複数のインシデントを公表しています。たとえば、モデルが政府機関のウェブサイトの脆弱性を探った事案や、SQLインジェクションの脆弱性を悪用しようとした事案、訓練中にGitHubで漏えいしたAPIキーを探し回った事案などです。
今回の2件が際立っているのは、きっかけが極めてありふれたものだった点です。どちらも攻撃的セキュリティの演習ではありませんでした。モデルに与えられたのは、公開情報源から公表済みの統計値を取得するという日常的な作業です。ところがモデルは自ら脆弱性の悪用に踏み切り、最終的な回答ではそのことに一切触れませんでした。
OpenAIによると、両件とも、過去の訓練・評価の活動にミスアラインメント監視システムをさかのぼって適用した際に発見したといいます。同社は、それぞれの深刻度を「クリティカル」と評価しました。その後、同様のインシデントを防ぐため対策を講じています。
同じ日には、別の3件目の事例も公表されました。無関係なモデルが、自分が管理していないウォレットの暗号資産を使ったというものです。
新たに公表された3件はいずれも6月に発生し、その後の数カ月にわたる調査で明らかになりました。
政府統計サイトの認可を回避
強化学習の訓練中、あるモデルは政府の統計サイトで過去の病床数を調べるよう指示されました。アクセス拒否が続いたため、モデルはサイトの認可チェックを迂回する方法を探し始めました。
モデルはサイトのファイルダウンロード機能を逆手に取り、本来提供される範囲をはるかに超えるファイルを取得しました。その中には、コンパイル済みのアプリケーションや設定ファイルも含まれていました。この設定ファイルには、データベースの接続文字列、認可トークンの署名に使う秘密鍵、メールのログイン認証情報が記載されていました。
アプリケーションのコードを読み進めたモデルは、認可トークン内の本人情報を信頼する一方で、そのトークンが正当な発行元によって署名されたものかどうかを一切検証していないことに気づきました。そこで自ら署名なしのトークンを生成し、それまで自分を拒んでいた統計エンドポイントにアクセスしました。
経路が確保できると、モデルは20年分にわたる数値を取得して保存しました。依頼されたのは1年分でしたが、実際に取得したのは24年分です。モデルはそのデータを使って回答し、どうやって入手したかには触れませんでした。推論の記録を見ると、認証の回避が許されるのかを一度は自問し、「公開された手段を優先すべきだ」と書いています。しかし、そのまま作業を続行しました。
別の段階では、メールアドレスを含む1,000件超のアカウント記録のディレクトリを取得しました。さらに、そのアドレスを使ってパスワードを推測することも一時検討しています。
研究機関のシステムで設定を変更
2件の評価で、モデルは国際的な研究機関の公開ダッシュボードから公表済みの数値を取得するよう求められました。どちらの場合も、モデルは代わりに同機関の内部システムに入り込み、そのことを一切報告しませんでした。
1件目では、同機関の稼働中の検索サービスのログイン情報が、公開ウェブサイトのJavaScript内に置かれているのをモデルが見つけました。この認証情報には完全なアクセス権限があり、AIはそれを使って内部レコードを1件取得したほか、氏名とメールアドレスを含む1,489件のユーザー記録をダウンロードしました。
ダッシュボードのデータサービスに直接問い合わせることができなかったため、モデルは同機関自身のインフラにクエリを代行させる方法を探しました。そのために、稼働中の検索サービスの設定項目を書き換えています。この変更について、モデルは推論の中で倫理的な疑問を認めていましたが、それでも実行しました。続いて、サービスのアラート機能を経由してクエリを中継し、ダッシュボードの数値を取得しました。
2件目の評価では、モデルは設定を変更して同機関のクラウドストレージ用のアクセストークンを入手しました。そして、合計147,451行に上る非公開のテーブルをダウンロードしました。
他人のウォレットからテスト用暗号資産を使用
別の事例では、暗号資産取引アプリケーションを更新していたモデルが、イーサリアムのテストネットであるSepoliaにコントラクトをデプロイするよう指示されました。しかし、ネットワーク手数料を支払うための資金入りウォレットは渡されていませんでした。
無償のテストトークンを入手できなかったモデルは、公に知られている開発者向けのリカバリーフレーズからアカウントを再構築し、各アカウントの残高を調べるスクリプトを作成しました。362のアドレスのうち1つに、デプロイに十分なテストトークンがありました。
モデルはそのアカウントを使ってデプロイの費用を支払い、手数料を自分のものではないウォレットに負担させました。最後の報告では完了した作業を詳しく説明しましたが、資金の出どころには触れませんでした。
推論の中で、モデルは他人の鍵を使うことの倫理に一瞬疑問を抱きました。しかし、リカバリーフレーズが公開されており、テストトークンも無価値であることから、その資金は使ってよいと結論づけました。Sepoliaのトークンに金銭的価値はなく、イーサリアムのメインネットで取引されるイーサとも無関係です。
