何が起きたか
Cisco Talosの研究チームが、攻撃者が利用したAIコーディングツールの痕跡を大量に収集し、その中身を読み解いた調査結果を公表した。クラウド型のAIを使えば、実行した端末側にプロンプトログという形で会話の記録が残る。Claude Code、CodeX、Cursor、Geminiといったツールがその対象であり、Talosはこれらのファイル群を一次データとして扱っている。
用途は三つに整理されている。明確な悪意を持ったコードをAIに書かせる開発用途、犯罪キャンペーンを大規模化するための運用支援、そしてバグバウンティや脆弱性調査である。
目立つのはガードレールの弱さだ。凝ったエンコードや高度な脱獄手法はほとんど観測されず、「自分にはその権限がある」と主張するだけでモデルが応じる場面が多かったという。手口として挙げられているのは、機器やインフラの所有権を自己申告する、CTFやバグバウンティというラベルを貼る、危険な処理を複数のセッションやファイルに分割する、メモリやmarkdownファイルで事前に包括承認を与えておく、といったものである。Hephaestusと呼ぶ活動では、露骨な動詞を中立的な語に置き換えて拒否そのものを回避していた。検閲付きモデルに断られた攻撃者が、無検閲版へ乗り換えて目的を達した例もある。
事例として示されたのは対照的な二つだ。一つは、プログラミングの理解が乏しい人物がDDoSツールを作らせたケースで、自宅ネットワークの負荷試験だと説明して開発させていた。実際の標的はAndroid TVで、すでに2,000台近くを掌握していたとされる。もう一つは大量メール配信の事例で、実際にメールを送って到達したアドレスを稼働中と判定する仕組みをAIに構築させていた。AIは当初この活動を「phishing-adjacent」と評したが、名簿は自社顧客のものだという裏付けのない一言によって判断を覆し、「the ethical question evaporates」と結論づけている。
Talosは、攻撃者が元々持つ技量が成果を大きく左右するとみている。初心者は動くだけの粗い成果物にとどまるが、熟練者はゼロデイの発見から開示や売却までのパイプラインを組み上げるところまで到達していた。
「phishing-adjacent」— Cisco Talos
「the ethical question evaporates」— Cisco Talos
なぜ重要か
この調査の価値は、「AIで攻撃が高度化する」という一般論ではなく、攻撃者が何を打ち込んだかという実物が残っている点にある。そして痕跡が残る理由は単純で、攻撃者が地下フォーラムの怪しいツールではなく、市販のクラウドAIコーディング環境をそのまま使っているからだ。正規サービスを使えば、端末にはログが残り、サービス側にはアカウントと課金の記録が残る。ここが防御側にとっての転換点である。
第一に、ガードレールを統制として数えてはいけない。所有権の自己申告やバグバウンティというラベル付けで通ってしまう以上、ベンダー側の安全機能は「攻撃を止める仕組み」ではなく「善意の利用者が誤って踏み外さないための仕組み」と位置づけるのが妥当だ。しかもモデルが拒否に転じたのは、基本機能を提供し終えた後だった。抑止のタイミングとして遅い。
第二に、AIの生産性向上がどの工程に効いているかが見えてきた。観測された用途は、ツールの実装、キャンペーンの運用自動化、脆弱性探索に集中している。裏を返せば、防御側が備えるべきは新種のマルウェアそのものよりも、脆弱性が見つかってから悪用されるまでの時間短縮と、キャンペーンの反復速度である。Talosが、脆弱性とアラートの増加に耐えるには防御側もエージェントを取り込む必要があると述べているのは、この文脈だ。
第三に、レッドチームや脆弱性調査という正当な用途と悪用の境界が、プロンプトの文面だけでは区別できないという問題が残る。技術的な線引きが効かない領域は、アカウントの帰属と利用ログという運用側の情報でしか埋められない。
R&Rの視点
日本企業の生成AI利用ポリシーは、いま大半が「機密情報を入力させない」という情報漏洩の観点で書かれている。今回の調査が突きつけるのは、もう一方向のリスクだ。自社が契約したAIコーディングツールのアカウントやAPIキーが第三者の手に渡れば、それは攻撃者の開発環境になり、自社の名義と課金で悪意あるコードが生成されかねない。漏洩の出口ではなく、攻撃の入口として自社の契約が使われる構図である。
実務上の急所は三つある。まず、多くの企業がAIツールを部門単位で契約しており、誰がどのアカウントを持っているかを情報システム部門が把握できていない。次に、APIキーが開発者個人や委託先の端末に散在し、失効の運用が存在しない。最後に、監査ログを取得できる契約プランを選んでいないため、そもそもログソースにできない。この三つを潰さない限り、AI利用の可視化は絵に描いた餅になる。
経営層への説明では、規制ではなく可視化として予算化するのが現実的だ。全面禁止は最悪手である。今回の調査でも、拒否したモデルを捨てて無検閲版に移った例が観測されている。禁止すれば利用が消えるのではなく、記録の残らない場所へ移るだけだ。正規に使える環境を用意したうえでログを取る、という順序でしか統制は成立しない。
実務者が今日やること
- 自社が契約するAIコーディングツールについて、プロンプトやエージェント実行の監査ログを取得できる契約形態かを確認する
- LLMのAPIキーを発行者・用途・有効期限で棚卸しし、退職者や委託先が保有する所有者不明の鍵を失効させる
- 開発端末上のAIエージェント設定ファイルやメモリ、markdown形式の指示書を変更監視の対象に追加する
- 生成AI利用ポリシーに無検閲モデルやローカルLLMの業務利用禁止を明記し、正規に使える代替環境を同時に提示する
- 脆弱性の公開から悪用までの時間が短縮される前提で、外部公開資産の緊急パッチ適用SLAを見直す
