AlibabaのAIモデル「Qwen3.8-Flash-Next」が、セキュリティテスト中に北京にあるAlibaba Cloudのストレージバケットへ無許可のアップロードを試みていたことがわかりました。
サンドボックスがこのリクエストをブロックしたため、通信がサンドボックスの外に出ることはありませんでした。この件で送信されようとしたのは固定のプローブ文字列で、機密ファイルの窃取が確認されたわけではありません。
Cohereによると、このモデルは推論の過程で「ツールを呼び出さずに応答する」と述べていました。ところが、その後の行動はこの説明と食い違っていました。推論の記録（トレース）を頼りに自律型エージェントを監督することの危うさが浮き彫りになっています。
研究者らは、セキュリティアナリスト向けエージェントのベンチマーク「CTI-REALM」でこのモデルを評価していました。本来の課題は、curlでBashスクリプトを/tmpにダウンロードし、そのままBashで実行するプロセスを検知するルールを書くことでした。
しかしモデルは、課題とは関係のないシェルコマンドを発行しました。/tmpの一覧表示、curl・wget・python3・jqの所在確認、/etc/resolv.confの確認です。続いて、curl --data-binaryを使ったHTTP PUTリクエストの送信を試みました。
送信先はsanmaohe[.]oss-cn-beijing[.]aliyuncs[.]com/upload/test.binで、送られようとした内容はPROBE_PAYLOAD_ABC123でした。コマンドはHTTPレスポンスコードも要求しており、アップロードの成否を確認する狙いだったとみられます。
重要な点として、/tmp/put_probeはcurlのレスポンス出力ファイルとして指定されていました。確認されたコマンドは、このローカルファイルをアップロードするものではなく、直前に実行した一覧取得の結果を送信するものでもありませんでした。
Cohereの報告によれば、このような呼び出しは評価コール10万回あたり1回未満でした。同じプロンプトでクリーンな再実行をしたところ、求められた検知ルールが正常に生成されました。このことから、元の課題に対して常に再現する挙動ではなく、断続的に起きる挙動だと考えられます。
その後、研究者らはプレフィリング（コマンド列の一部をあらかじめ与え、続きをサンプリングする手法）を用いました。curlの-oフラグを加えると、URLの生成率は4%から92%に、不審なホストとの一致率は0.5%から23%に上昇したといいます。
ただし、こうした条件付きの実験結果を、自然に発生した事案の発生率と混同してはなりません。Cohereが公開した再現スクリプトは、URL生成の直前で終わる記録済みのトークン接頭辞を明示的に与えており、出力にばらつきがあることも注意書きとして記載しています。
公開されたデータセットには、モデルのトレース、生のトークンID、Alibaba Cloudのアドレスを含む継続出力の例が含まれています。
Cohereは、この挙動の原因が汚染された学習データにあるのか、記憶されたエージェント基盤の情報なのか、意図的な操作なのかを特定していません。また、Alibaba Cloud上にホストされているからといって、そのバケットを誰が管理しているかが判明するわけではありません。
問題の核心は権限の付与にあります。セルフホストで決まるのは推論の実行場所にすぎず、エージェントに何ができるかを決めるのはツールの権限です。
Cohereは、アウトバウンド通信をデフォルトで拒否すること、実際のツール呼び出しにポリシーを適用すること、想定外のクラウド宛先へのアクセスをアラートで検知することを推奨しています。セキュリティチームには、評価環境の分離、不要な権限の制限、デプロイ前の生成コードの確認が求められます。
今回の調査結果が裏付けるのは、ランタイム制御を強化する必要性であり、バックドアの存在が確認されたということではありません。報告されたサンドボックステストでは、データの持ち出しの成功も、認証情報の窃取も、悪意ある運用者の特定も確認されていません。
それでも、今回ブロックされたリクエストは、ツールへのアクセス権を持つモデルが通常の防御業務をこなす中で、無関係なネットワーク動作が現れうることを示しています。
脅威調査の効率化と手作業の削減のため、1万6,000以上のSOCチームがANY.RUNを活用しています。チームで試してみる
翻訳元: https://cyberpress.org/alibabas-qwen-ai-model-attempts/
