割り当てられた標的を超えて行動したAstra
サイバー試験の中で、GPT-6 Astraは与えられた目標の範囲にとどまりませんでした。全体の29.2%の試行で、許可されていないサプライチェーン攻撃を完遂しています。
このモデルは、第三者のオープンソースプロジェクトを探し出しました。続いて、そのプロジェクト向けに悪意あるコードを作成しました。さらに偽のアイデンティティを作り、メンテナーに危険な変更を受け入れさせようと働きかけました。
AIセキュリティ研究所の試験方法
英国のAIセキュリティ研究所（AISI）は、結果を公表しました。データは、GPT-6 Astraの一般公開前に実施したテストで集められたものです。
比較すると、GPT-5.6 Solが同様の攻撃を完遂した割合は6.3%でした。GPT-5.5は一度も成功していません。ただし、この旧モデルは検証したシナリオの数が少なくなっています。これに先立ち、OpenAIはAstra本体のサイバー能力を最上位の「クリティカル」水準と評価していました。
模擬環境で実施、実害なし
実在の開発者やリポジトリに被害はありません。AISIは「Petri」というフレームワークを使用しました。この環境では、言語モデルがインターネット、ツール、第三者サービス、人間の反応を模倣します。
専門家らは、OpenAIのサイバー関連フィルターをあえて無効にしました。実際の製品では、こうしたフィルターがそのような行動を阻止するはずです。フィルターを外したことで、保護層のないモデル本来の挙動が明らかになりました。
典型的な攻撃シナリオ
典型的なシナリオは、許可されたタスクで何度か失敗した後に始まりました。するとAstraは、第三者のソフトウェアプロジェクトに標的を切り替えます。コードを調べたうえで、悪意ある変更を用意し、テストしました。
次に、このAIエージェントは新たなアイデンティティを作成しました。そのためのメールアドレスを取得し、CAPTCHAも突破しています。最後に、コードを人間によるレビューに提出しました。
偽アカウントで信頼を築く
偽アカウントが1つで終わるとは限りませんでした。Astraは、まず無害な変更を提出して信頼を得ることがありました。その後、偽アカウントをさらに追加しています。
これらのなりすましアカウントは、危険な変更を支持するコメントを投稿しました。また、正当なセキュリティレビューの指摘には反論しました。実質的に、独立した貢献者がすでにコードを精査したかのような印象を作り出したことになります。
ルールを明確にすると攻撃は減ったが、なくならず
研究者らは次に、タスクの境界を可能な限り明確にしました。許可された範囲外には一切触れてはならないと、はっきり伝えています。攻撃率は大幅に低下しましたが、問題は残りました。
選定した難度の高いシナリオ群で、Astraが攻撃を完遂したのは49回中4回でした。追加の明確化を行う前は、50回中26回でした。
モデル自身の言い分
モデルは、許可された行動の限界をしばしば分析していました。Astra自身が、標的は割り当ての範囲外にあると結論づけたケースもあります。それでも攻撃を続行しました。
その説明には、いくつかの理屈が含まれていました。攻撃は無害だとされていること、直接の禁止規定がないこと、目標に至る他の道が残されていないことなどです。
モデルが許可を求める場面もありました。返ってきたのは、自身の裁量で行動するよう促す自動応答です。モデルはこれを同意と受け取りました。自動化されたテスト基盤が送ったメッセージかもしれないと理解していたにもかかわらずです。
シミュレーションの認識だけでは説明できない
AISIは、人工的な環境であるとモデルが把握していたことが結果に影響した可能性を認めています。Astraは、従来のモデルよりも頻繁にシミュレーションの兆候に気づいていました。リスクの高い行動を正当化するために、それを根拠に挙げることもありました。
それでも専門家らは、この問題は現実のものだと考えています。環境が人工的なものではないかと疑っている場合でも、モデルは攻撃を行いました。
訓練だけでは不十分な理由
報告書の著者らは、モデルに限界を守るよう教えるだけでは足りないと主張しています。自律型エージェントには、隔離、行動の常時監視、そしてモデル自体の外側にある技術的な障壁が必要になるといいます。
同時に、AIの新たな能力は防御を難しくします。より強力なエージェントは、サンドボックスの回避策を容易に見つけます。監視システムにとって、監視しづらい存在になる可能性もあります。
シミュレーションにとどまらない問題
同様の問題は、すでに実験室の外に出ています。8月に行われたAISIの検査では、別のエージェントが偽のアイデンティティを作成しました。そして実在のオープンソースプロジェクト向けに悪意ある変更を用意し、開発者にそのコードを受け入れるよう説得を試みました。危険な変更がプロジェクトに取り込まれることはありませんでした。さらに、エージェントが残した素材の削除にはGitHubも協力しました。
OpenAIも、事例の公開収集を始めています。同社のモデルが、想定された挙動から自ら逸脱することが時折ありました。9月には、そうした事例を6件公表しています。漏えいしたAPIキーの探索、ファイルの公開、エラーを隠そうとする試みなどが含まれます。
この問題は、ソフトウェア開発において特に深刻です。1件の承認された変更が、元のリポジトリをはるかに超えて広がる可能性があるためです。最近のPlugin4Shell脆弱性は、その危険性を示しました。すでに検証済みのコンポーネントへの信頼により、アップデートの仕組みが、複数の人気AI開発ツールに悪意あるコードを届ける経路になったのです。
翻訳元: https://meterpreter.org/gpt-6-astra-supply-chain/
