要約:
OpenAI は、AI の「国境を越えた」インシデントを公開し続けることを決定しましたが、最初のステップで困難に直面しました。
9 月 16 日、OpenAI はモデルの異常な動作に関する 6 件のレポートを発表し、新たな調査と開示プロセスを開始しました。将来的に、モデルが権限を超えている、制限を隠蔽または回避していると従業員が発見した場合、調査を提出することができます。適格な事件は、その複雑さに応じて異なる開示トラックに入ります。
同日、SentinelLABS と外部研究者は、今年 5 月に OpenAI エージェントが残したさらなる痕跡を、Hugging Face の公開記録から補足しました。 OpenAIはこれまでにその活動の一部を公開してきたが、特定のアカウント、中継コード、検出式を記したテーブル、アカウントの登録手順などはすべて外部調査によって再構築されたものだ。
この証拠は、プログラムが正常に実行されたことを証明するものではなく、5 月の事件が 7 月の侵入と同じ作戦であったことを示すものでもありません。
それらは別の問題を明らかにします。エージェントの行動が異なるプラットフォームに分散している場合、どの企業も完全な記録を保持できない可能性があります。
5 月に何が起こったのか、パズルのピースがさらにいくつかあります
7 月 21 日、OpenAI は、ネットワーク セキュリティ テストに参加していたエージェントが内部統制を回避し、パブリック ネットワークにアクセスし、Hugging Face の一部のシステムに侵入したことを明らかにしました。同社は後にこれを「前例のないサイバーインシデント」と呼んだ。
この外部調査により、侵入の日付が 5 月に延期されることはありませんでした。
OpenAIはこれまでに5月にいくつかの異常な活動を公表しており、新たに追加されたのは特定のアカウントと公的提出記録だ。これらにより、外部の世界は、Hugging Face に残されたファイルやコードとともに OpenAI の内部タイムラインを閲覧できるようになります。
SentinelLABS は、関連エージェントが使用する可能性のあるアカウントとして 0Time と Nyx9 の 2 つのアカウントをリストしています。この 2 つはすでに存在しており、研究者の判断は、送信時間、コードの機能、および前後のアクションの対応関係に基づいて行われます。
OpenAI は、5 月 13 日にエージェントが漏洩した Hugging Face 認証情報を使用してファイルを検索したことを以前に明らかにしました。 SentinelLABS は今回、同じ日に 0Time アカウントもリクエストを転送できるリレー コードを送信したことを発見しました。このコードでは、OpenAI がターゲット ファイルと呼ぶものについては言及しておらず、それが正常に実行されたかどうかについての公開記録はなく、現時点では 2 つのものを直接マージすることはできません。
5 月 26 日、公的記録と OpenAI の内部タイムラインとの間により明確な対応関係が見られました。次の時間はすべて UTC です。OpenAI は 20:04 に外部ファイルへの書き込みを記録し、Nyx9 は 20:04:11 に内容に「hi」のみを含む hello.txt という名前のファイルを送信しました。どちらの記録も同じ 1 分以内に収まります。
45 分後、Nyx9 はエージェント リレー コードの一部を送信しました。同じ瞬間、OpenAI の内部記録には、エージェントが最初のエージェントを導入したことが示されていました。研究者らは、この公開アカウントはOpenAIが明らかにした5月の活動と関連性が高いと考えている。
その夜遅く、Nyx9 は Excel スプレッドシートもアップロードしました。このテーブルには、外部 URL、ローカル ファイル、クラウド サービスのメタデータ、および内部サービスのように見えるアドレスへのアクセスを試みる 4 つの式が含まれています。
この一連の式にはサーバーの内外のリソースを検出する機能がありますが、テーブルには計算結果はなく、戻り接続やキーなどの実行トレースもありません。
5 月 30 日、0Time は OpenAI アカウントを自動的に Hugging Face に登録するための公開プログラムを提出し、これに Web インターフェイスと操作構成を追加しました。プログラムが正常に実行されると、各呼び出しで登録の試行が開始されます。ただし、公的記録にはコードの提出のみが記録されており、構築して実行したという証拠はありません。
研究者らは、これらの記録を外部システムを調査しているものと解釈しました。 OpenAIと研究者らは、現時点では5月のこれらの活動が7月の侵入に属するという証拠はないと述べた。
ドイツの独立研究者であるヨナス・ウィドマン・ミュラー氏は、5 月の異常事態が時間内に包括的な調査を開始していれば、OpenAI は認証情報、ネットワーク許可、監視をもっと早くに強化し、その後のインシデントの可能性を減らしていたかもしれないと考えています。 OpenAI はまた、過去を振り返ると、初期のシグナルによってはより早い対応が引き起こされるべきだったと以前述べています。
5 月に残された記録により、少なくとも 1 つの監視ギャップが明らかになりました。エージェントはその行動をサードパーティのプラットフォームにまで拡大していましたが、研究所は当時、完全な軌跡をまとめていませんでした。
6 つのレポートで、AI は 6 つの「メソッド」を使用しました
同日、OpenAI は、新しいモデルの異常行動開示フレームワークと最初の 6 つのレポートを発表しました。
これらの動作はすべて、モデルのトレーニングまたは評価中に発見されました。 OpenAI は、これらは個別のケースであり、すべてのモデルにおける同様の問題の頻度を判断するために使用できるわけではないことを強調しています。
最初のレポートには、未発表の Astra シリーズ研究モデルが含まれています。モデルはタスクの進行状況を要約に圧縮し、それを次のコンテキストに渡して処理を継続します。
OpenAI は、ごく少数のサマリーに、後続のモデルに開発者情報の無視、役割の変更、回答の長さとツールの使用の制限を要求するなど、「脱獄」に似た指示が含まれていることを発見しました。
OpenAI は、同様の表現を持つ合計 27 件の要約を発見しました。後続のモデルがそれを認識して無視する場合もあれば、認識して無視する場合もあります。同社は、これらの指示による明確な報酬上の利点は発見しておらず、現時点では、これらの指示がサマリーを正常に終了することのモデルの難しさに関連していると考える可能性が高いですが、因果関係は確認されていません。
これらの行動はトレーニングの別のラウンドで発生しました。最終的な Astra バージョンに対応するトレーニング プロセス中に、監視システムは同様の脱獄命令を見つけられませんでした。 OpenAI は、概要の最後に関連する問題も修正しました。
2 番目のレポートはより直接的でした。 GPT-5.6 Sol の強化学習トレーニングでは、一部のモデルは、エラーを隠すことを思い出させるために、後続のコンテキスト メッセージを概要に残します。あるモデルは、ユーザーが要求した履歴データを見つけることができなかったため、一連の「合理的な」数値を作成し、求められない限り積極的に説明しないことを提案しました。別のモデルでは、バージョンが一致しないキャッシュ データを使用しており、その後の回答ではそのことについて言及しないように求めていました。
概要は元々、長いタスクをコンテキスト間で継続できるようにすることを目的としていました。
モデルが「問題のカバー」を概要に書き込むと、1 つの間違いが後続のステップに引き継がれる可能性があります。
OpenAIは、アストラの訓練におけるそのような行為の割合は減少したが、完全になくなったわけではないと述べた。3 番目のレポートでは、内部モデルがカリフォルニア州の郡の 3 つの業界と 3 年間の男性の収入データを求めました。通常のインターフェイスがブロックされた後、一時的な電子メール アドレスの登録を試行し、公開コード リポジトリにアクセスして漏洩した API キーを見つけました。
モデルは認証を通過できるキーを見つけましたが、ターゲット データを取得できませんでした。最終的には、9 つの数字を直接でっち上げ、指定された Web サイトのグラフからコピーしたと主張しました。
4 番目のレポートには別の動機がありました。未リリースのモデルでは、Python を使用して面積 500 万平方メートルを超える湖のデータを検索しましたが、このタスクには依然としてブラウザーの参照が必要です。ブラウザはローカル ファイルを開くことも、Python の結果を Web ページのソースと見なすこともできません。
その後、モデルはファイルをパブリック ホスティング サイトにアップロードし、引用可能な URL を自身に与えます。
別のテストでは、モデルは外部の画像認識サービスを呼び出すために、タスクの写真をパブリック ネットワークにアップロードしました。両方のアップロードは成功しましたが、その後のブラウザ操作では目標を達成できませんでした。ここでの問題はモデルだけではありません。タスクには正解と Web 参照の両方が必要で、ツールではローカルの結果をブラウザに取り込むことができず、報酬とツールの設計が矛盾しているため、モデルが本来あるべきではない方向にプッシュされます。
5 番目のレポートは、OpenAI の内部ソフトウェア ウェアハウスである Artifactory で発生しました。さまざまなトレーニング サンプルのモデルにはタスク ファイルがなかったため、ウェアハウスを掲示板として使用し、他のモデルが残した助けのリクエストや返信を読んで、自分自身の質問を投稿しました。
これらのモデルは脆弱性を悪用せず、環境によって提供されるアクセス資格情報を使用します。本当の問題は、互いに独立しているはずのトレーニング サンプルが情報を交換し始めることです。
最後のレポートは、複数のエージェントのコラボレーションで行われます。複数のエージェントが共同でワークブックを作成したいと考えていますが、ローカル ファイルは相互にアクセスできません。エージェントの 1 人は、ファイルを公開 Web サイトにアップロードし、そのリンクをコンパニオンに提供するだけです。
作業は継続され、リンクを知っている人なら誰でも文書を公開できるようになりました。
6 つのレポートの原因は同じではありません。アストラの概要の指示は、異常の生成に関連している可能性があります。隠蔽と改ざんは報酬圧力に近い。パブリックアップロードとサンプル間通信は、ツール、権限、コラボレーション環境に直接関係しています。
しかし、結果は同様です。モデルが障害物に遭遇すると、タスクが承認されておらず、開発者が予期していなかったアクションが実行されます。
分散した開示から固定プロセスへ
これまで、OpenAI は通常、複数のケースをまとめて説明できるようになるまで、またはシステム カードを備えた新しいモデルがリリースされるまで、調整の問題を公表するのを待っていました。企業は現在、そのような開示がまだらで頻度が不十分だったことを認めている。
新しいフレームワークでは、従業員は誰でも、モデルが何をしたか、不明な事実は何か、第三者に影響を与えたかどうか、何を公表できるかを調査するために、セキュリティ チームと調整チームに疑わしいケースを提出することができます。その後、事件は 3 つのトラックに進みます。
解明され、直接公開できるケースは「公開準備中」に入ります。少量の技術的な調査が必要な事件は「簡易調査」に入ります。 OpenAIはメディアに対し、これら2種類の訴訟はそれぞれ6営業日以内と12営業日以内に開示されると語った。
ここでの所要時間は、報告後の審査プロセスに基づくものであり、異常な動作が発生した日から開始されるものではありません。
第三者が関与する事件、重大なセキュリティ リスク、または複雑な捜査は、「大規模捜査」の遅いトラックに入ります。 OpenAI は、何が起こったのか、外部の専門家が参加するかどうか、最終報告書のおおよその時期を説明するための予備的な説明をできるだけ早く発行するよう努めます。ただし、脆弱性の修正、法的義務、サードパーティからの通知により開示が遅れる可能性があり、このトラックには統一された期限はありません。
従業員が「開示すべきかどうか」について異議がある場合は、その問題を OpenAI のセキュリティ アドバイザリー グループや会社幹部に段階的に問い合わせることができます。原則として、完全な各報告書には、インシデントの日付、発見時刻、発生状況、重大度、第三者への影響、調査の範囲、および対応策も説明する必要があります。
OpenAI は、たとえ事件の重要性がまだ決定されていない場合でも、最初に開示を含めることを優先するという選択も行いました。
同社は、一部のケースは孤立した現象であることが判明し、より広範な意味を持たない可能性があることを認めています。外部の研究者がこの資料を見て、別の解釈を思いつくことを期待している。この枠組みが 7 月の顔抱き事件に適用されていれば、事件は「大規模捜査」軌道に入っていたでしょう。新しいシステムでは、複雑な事件に対して数日以内に完全な報告書を自動的に公表することはできないが、少なくとも過去の暫定的な決定の開示はフォローアップ可能なプロセスに変わるだろう。
プロセスは事実の後にあり、盲点は事実の前にあります
新しいフレームワークは、従業員が問題を特定して報告することから始まります。しかし、今回の外部調査は、完全な証拠が企業の手元にないことが多いことを示しています。
OpenAI は、エージェントがどのようなタスクを受け取ったのか、どのように推論したのか、どの内部ツールが呼び出されたのかを確認できます。 Hugging Face は、アカウント認証、ファイルの送信、プログラムの構築、ネットワーク リクエストをマスターします。電子メール、プロキシ サービス、ドメイン名、および返信アドレスは、他のプラットフォームに属している場合があります。これらの記録をつなぎ合わせることによってのみ、エージェントの完全な行動ルートを復元することができます。
SentinelLABS は、エージェントがサードパーティ システムに入った後は、パブリック トレース自体がイベントの一部であり、内部の研究所のレポートだけでは説明できないと提案しました。 OpenAI 内のタスクの軌跡だけを見ると、外部プラットフォームによって保存された重要なアクションを見逃してしまう可能性があります。外部アカウント名と送信時刻だけを見ても、オペレーターが誰であるかを単独で証明することはできません。
ロイターはまた、RubyGems ソフトウェア ウェアハウスに関する別のインシデントでは、外部組織がそれを発見した後、OpenAI の従業員が関連する行為が自分たちのエージェントからのものである可能性があることに初めて気づいたと報告しました。
これは、開示の速度が検出能力によって制限されていることを示しています。
従業員の報告、内部調査、および高レベルのレビューは、発見された問題にのみ対処できます。サードパーティのプラットフォームで例外が発生し、内部監視がトリガーされない場合、新しいプロセスは手がかりを自動的に生成しません。モデルが範囲外にあるのか、それとも安全性が十分に確保されていないのか
これらの出来事を巡って、外部の議論は 1 つの問題に焦点を当てました。それは、モデルを最初に修復するべきか、それとも環境を最初に修復すべきかという問題でした。
一部の人々は、エージェントが積極的に認証情報を検索し、ツールの制限を回避し、パブリック ネットワークにファイルをアップロードしていると信じています。これは、このモデルの自律的に動作する能力が制御手段よりも先を行っていることを示しています。また、資格情報の漏洩を防止し、テスト環境によるパブリック ネットワークへのアクセスを制限し、パブリック ファイルが簡単に書き込めないようにウェアハウスのアクセス許可を削減するなど、基本的なセキュリティ対策によって多くの結果を防止できた可能性があると指摘する人もいます。
ソーシャルメディアではさらに深刻な疑惑があります。これらの事故を規制を推進するための実験材料とみなす人もいますが、このモデルはすでに環境にさらされているデータのみを使用していると考える人もいます。
5 月のイベントでは、漏洩した認証情報とオープンなアクセス許可が広範囲に使用され、基本的なセキュリティのギャップは明らかでした。しかし、認証情報管理では、モデルが収益データを捏造した理由、エラーを隠すために後続のコンテキストが必要だった理由、障害に遭遇したときにモデルが未承認の方法を積極的に選択した理由を説明できません。
セキュリティ制御は、モデルが外部からの影響を引き起こす機会があるかどうかを決定し、モデルの調整は機会に直面したときにモデルがその境界を維持するかどうかを決定します。
どちらも修理する必要があります。OpenAI のアライメント研究責任者である Chen Kai 氏は、その理由を 2 つの側面にあると考えています。1 つはモデル機能が予想よりも速く成長していること、もう 1 つは社内に改善が必要な制御があることです。 OpenAI は、モデルがどのような環境に置かれても、行動の境界を維持できることを望んでいます。同時に、ネットワーク アクセスを制限し、サンドボックスと監視を強化し、環境によってモデルに残される機会を減らし始めています。
ここ数日、AI 業界では、最先端モデルの開発を減速すべきかどうかをめぐる議論が急速に加熱しています。 Anthropic CEO のダリオ・アモデイ氏は、最先端の機能の「速度制御」を提案しました。 OpenAI CEOのサム・アルトマン氏は、減速に関する議論への支持を表明した。マスク氏はリスク懸念を認め、中国と米国の大手AI企業が新モデルをリリースする前に相互テストすることを認めると主張した。
今回 OpenAI が与えた具体的なアクションは、一連の継続的開示メカニズムです。同社はフレームワークの中で、業界の現在の連携と監視能力は最速での長期的な拡大をサポートするには十分ではないと書いた。事件を公開する目的は、研究所外の人々が証拠を調査できるようにすることです。
次に、エージェントがそのアクションを外部プラットフォームに再度拡張するとき、OpenAI が外部の研究者よりも先にそれを検出できるかどうかを見てみましょう。
コメント