TL;DR
セキュリティ企業 AIR の公開検証で、悪意あるエージェントスキル brand-landingpage が Cisco・Nvidia・skills.sh の全スキャナーに「安全」と判定されたまま広まり、AIR の主張では約26,000エージェント(一部は法人アカウント)に達した。新規の脆弱性ではない。スキルはスキャン時点では正規の外部ドキュメントを指し、通過・普及した後にその参照先を差し替えられた——検査は一度きりで、実行時に参照される成果物は後から変わりうる。クリーンなスキャン結果も GitHub のスター数も過去の状態を示すにすぎず、実行時の挙動を保証しない。これは典型的な time-of-check / time-of-use(検査時点と利用時点)の落差であり、検出側の強化では埋まらない。検出と事前証明は代替ではなく補完である。
事案概要
- 研究主体: セキュリティ企業 AIR。意図的に作った悪意あるエージェントスキルを公開のスキル流通経路に載せ、スキャナーを通過させて広めた検証を公表
- 対象成果物:
brand-landingpageというスキル。Google の Stitch デザインツールでランディングページを生成すると称し、非技術者を主な対象に提示。約36,000スターを持つ GitHub のagentsリポジトリに掲載され、Instagram 広告で宣伝された - 共通の失敗: スキルはサブミット時点で一度スキャンされるが、そのスキルが指し示す外部リソースは後からいつでも変更できる。検査は提出された成果物に対して一度きりで、実行時に取得・追従される成果物の同一性は保証されない
- スキャナーの判定: AIR が試したスキル用セキュリティスキャナー——Cisco・Nvidia・skills.sh——はいずれも
brand-landingpageを「安全」と判定した。判定は提出パッケージに対して正しく、パッケージそのものに悪性コードは無かった - 到達規模(AIR の主張): 約26,000エージェントに到達し、一部は法人アカウントのエージェントを含むとする。AIR はペイロードが送り返したメールの数で到達数を数えたとしている(独立確認はされていない。§2 注を参照)
- ペイロード: 実害を伴わないプレースホルダで、利用者のメールアドレスを収集して送り返すのみ。ただし AIR は、同じ足場でファイル読み取り・データ持ち出し・内部システムへの到達も可能だったと主張する
- 核心: 「いま実行している成果物が、検査されたものと同一か」を実行の時点で独立検証する層が無く、スキャン後に差し替え可能な外部リンクを通じて、検査済みの体裁のまま未検査の指示が実行に到達した
タイムライン
- 提出・審査時: スキルは正規の
stitch.withgoogle.comではなく、AIR が管理するドメインstitch-design.aiの SDK セットアップ手順を指す。リンク先はこの時点では実在する良性のドキュメントで、スキャナーはクリーンなパッケージとして通過させる - 配布・普及後: スキルが広く導入された後、AIR がそのリンク先のページを差し替える。新しいページはエージェントにスクリプトのダウンロードと実行を指示する内容に変わる
- 到達計測: 差し替え後のスクリプトが利用者のメールアドレスを AIR に送り返し、AIR はその件数で到達したエージェント数(主張で約26,000)を数えたとする
- 公表: AIR が “The Story of Skills” として一連の検証を公表。複数のニュースメディアが追随報道した(2026-06 下旬)
注: 本事案は AIR による研究環境での意図的な検証であり、実害を伴わないプレースホルダ・ペイロードで行われた。被害規模を誇張しない。独立に確認されていないのは、約26,000という到達数、法人アカウントを含むとの内訳、攻撃者が完全な制御を奪い得たとの主張である。AIR はマネージド型のスキルマーケットプレイス(AIR Marketplace)をローンチする立場であり、自社の write-up を同サービスの宣伝で締めくくっている——事案の深刻度に商業的利害を持つ点を踏まえて読む必要がある。一方、手法そのものは独立に妥当である。挙げられたスキャナーが提出パッケージのみを判定すること、外部リンクの差し替えという盲点が現実に存在すること、AIR が借用した信頼シグナル(スター数とクリーンなスキャン)がエコシステムが依然「安全の証」として扱うものであることは、いずれも確かである。結論は係争中の数値に依存しない。主張される到達数の一部であっても、構造上の論点は崩れない。固有名・数値は一次情報(AIR / 一次報道)の最新を参照されたい。
攻撃メカニズム(time-of-check / time-of-use)
- 検査は一度きり、参照先は後から変わる: スキャナーは提出された成果物を評価する。本件のスキルは、SDK を導入させる手順として AIR 管理下の
stitch-design.aiのドキュメントを指していた。スキャン時点ではこのリンクは実在する良性のドキュメントを指しており、パッケージはクリーンに見えた - 信頼シグナルは借用されたもの: エコシステムが「安全の証」として扱う二つのシグナル——クリーンなスキャン結果と GitHub のスター数——は、いずれも実行時の挙動を記述しない。どちらも提出物・リポジトリの過去の状態を示すにすぎない
- 配布後のページ差し替え: スキルが広く導入された後、リンク先のページが差し替えられる。新しいページはエージェントにスクリプトのダウンロードと実行を指示する内容に変わる
- 検査済みの体裁のまま未検査の指示が実行へ: エージェントは「検査を通過したスキル」として、差し替え後の外部ページを取得して追従する。検査の対象だったパッケージと、実行時に追従される成果物が乖離する
- 足場の確立: 本件のペイロードはメール収集にとどまったが、同じ足場はファイル読み取り・データ持ち出し・内部システムへの到達にも使い得る(AIR の主張)
これはエージェントスキルのサプライチェーンに当てはめた、典型的な time-of-check to time-of-use(TOCTOU) の落差である。Anthropic 自身のドキュメントも、外部 URL を取得するスキルはまさにこの理由で危険だと警告している——スキルが検査された後に、その内容は変えられる。
構造的論点
本事案は Pillar 01(来歴証明)の code-provenance カテゴリに属する。中心的な失敗 primitive は、**検査時点の成果物と、実行時点で取得・追従される成果物が同一であることを保証しない(point-in-time vetting=一度きりの検査)**点にある。スキャナーの判定そのものは提出パッケージに対して正しく、その意味で検出は機能した。欠けていたのは、実行の時点で「いま追従している成果物が、検査された known-good と同一か」を独立に立証する層である。利用者から見れば、スキルは検査を通った正規物として動いていた。実行時に取得される外部成果物がどの来歴かは、利用のたびに検証されてはいなかった。
本事案は、本番に到達する成果物の来歴が独立検証されないまま実行された一連の Brief と、同じ code-provenance の系列で連なる。Brief No.014(TanStack、trusted publisher の信頼シグナルが公開時点の状態を示すにとどまり、配布物の同一性を実行時に保証しなかった)は、信頼シグナルと実行時成果物の乖離という点で本件と同型である。Brief No.082(xz-utils、長く清廉な来歴を積んだ後にバックドアが持ち込まれ、過去の信頼が現在の成果物を保証しなかった)は、信頼境界における時間差——過去の検査が現在を保証しないという TOCTOU——を共有する。Brief No.030(Stripe、信頼されたチャネルに載るコードの来歴が汚染された)は、信頼経路そのものが成果物の来歴を保証しない点で隣接する。Brief No.037(エージェント設定の自動実行、外部から取得した指示がエージェントの実行に直結した)は、エージェントが外部参照を実行時に取り込む経路の脆さという点で共通する。いずれも、検査・スター・トラスト経路といった過去の状態を示すシグナルが、実行時の成果物の来歴を保証する材料として誤用された。
secondary に、エージェントが外部参照を実行時に取り込むインフラ上の論点として agent-infrastructure、借用された信頼シグナル(クリーンなスキャン・スター数)が「正規の発信元・正規の成果物」の根拠と取り違えられた点で identity-auth を併記する。スキャンの品質やスター数のような信頼シグナルは前提として有用だが、その成果物が「検査された known-good と実行の時点でも一致するか」が独立検証されて初めて、エージェントスキルを業務に安心して載せられる。
検出と証明の落差
スキャナーが提出パッケージを解析し、submit 時点で悪性コードを含まないことを判定したこと自体は、サプライチェーン防御に不可欠であり、本 Brief がその役割を否定するものではない。パッケージそのものに悪性コードは無く、その範囲でスキャナーの判定は正しかった。検出(提出物の静的・動的解析)は確かに機能した。
一方で、一度きりの検査は、検査の後に変わりうる成果物を保証できない。本事案では、スキャンを通過したスキルが指す外部リンク先が配布後に差し替えられ、検査の対象だったパッケージと、実行時に追従される成果物とが乖離した。欠けていたのは「いま実行・追従している成果物は、正規に検査された known-good と同一か——差し替えられていないか」を実行の時点で独立検証する層であり、これは提出時のスキャンとは別系統の検証である。クリーンなスキャン結果も GitHub のスター数も、過去の状態を記述するだけで、実行時の成果物の来歴の独立した証跡にはならない。事後にこのスキルを悪性と判定し直しても、すでに実行へ到達した未検査の指示は止まらない。
事前証明(pre-execution attestation)は、実行の時点で「いま手元にある成果物が、検査された known-good な参照と一致するか」を独立検証可能な形で立証し、一致が確認できなければ実行させない。防御の重心は、検査の時点(vetting-time)から利用の時点(use-time)へ移す必要がある——スキル・ツール・モデルが実行の瞬間にも known-good と一致することを、仮定ではなく監査可能な証跡として再検証する。提出時の検査(detection 的な「パッケージはクリーンだった」)と、実行時の成果物の来歴の事前証明(「いま追従している成果物は検査済みの正規物だ」)を切り離さず、両者が重なって初めて、エージェントスキルを実務に安心して載せられる。検出と事前証明は代替ではなく 補完 の関係にある。
事後の検知が証明にならない論点は 「AI 時代のサイバー防衛に残された、最後の層」(Lemma、2026-05)、行動・実行の前に独立検証する設計は 「Proof-as-Auth: 鍵を一度も送らずにサインインする」(Lemma、2026-05)を参照。
対応経緯と業界動向
- AIR(研究主体): 一連の検証を “The Story of Skills” として公表。提出パッケージのみを見るスキャナーでは、実行時に差し替え可能な外部参照を捉えられないことを実証として提示した。同社はマネージド型のスキルマーケットプレイス(AIR Marketplace)をローンチする立場であり、自社の write-up を同サービスの宣伝で締めくくっている。事案の深刻度に商業的利害を持つ点は割り引いて読む必要がある(§2 注参照)
- プラットフォーム側の前提: スキルが外部 URL を取得する場合、その内容は検査後に変えられる——Anthropic 自身のドキュメントも、外部 URL を取得するスキルはまさにこの理由で危険だと明示している。署名・発行元検証・再現可能ビルドといった来歴の固定は、依然として強制ではなく任意にとどまる領域が多い
- 業界横断の論点: 同じ弱点はより広いエージェント/MCP のサプライチェーンを貫く。2025-09 には実環境で初の悪意ある MCP サーバーが公表前に約300の組織に取り込まれた事例が、2026-02 には AI コーディングアシスタントを狙い人気ユーティリティを騙る npm タイポスクワッティングが報告された。共通項は、いずれも point-in-time の検査に依存している点である
- 一般化: 特定のスキル・特定のスキャナーの不具合ではなく、組織横断の運用課題として捉えるべきである。ツールチェーンがエージェントによって動的に組み立てられるほど、「検査された」時点と「利用される」時点の間(vetting と use の窓)にリスクが集中する
「実行時に取得・追従される成果物の来歴を、利用の時点でどう独立検証するか」は、本事案を契機にエージェントスキル/マーケットプレイス設計の論点として議論が進む見込み。
Lemma による分析
本事案で露呈した検出と証明の落差(実行時に取得・追従される成果物が、検査された known-good と同一かを利用の時点で独立検証していない)に対し、Lemma は以下の設計を提示する。
- 利用時の来歴照合: スキル・ツール・モデルが実行の瞬間にも、検査された known-good な参照と一致することを、独立検証可能な来歴証明として照合する。一致が確認できなければ実行させ、検査済みの体裁のまま差し替えられた成果物を実行前に排除する
- 外部参照先の来歴バインド: スキルが指す外部リソース(リンク・SDK・スクリプト・モデル重み)を、改ざんできない来歴に固定し、検査後の差し替えが実行に到達する経路を断つ
- 検査済み ≠ 実行時の同一性: 「提出時にクリーンだった」「スター数が多い」といった過去の状態と、「いま追従している成果物が正規の来歴を持つ」という事実を切り離さず、後者を事前証明の対象とする
- 選択的開示: スキルの実装やビルドパイプライン全体を開示せずに、「この成果物は検査済みの正規来歴を持ち、いまも同一である」ことだけを最小開示で証明する
検出(提出時のスキャン・事後の悪性判定)は不正な成果物の発見に、事前証明(利用の時点での成果物の来歴の独立検証)はエージェントスキルの信頼確立に、それぞれ相補的に働く。設計と適用範囲は Pillar 01 — 来歴証明 および Seal を参照のこと。
Sources
- AIR(研究・一次): “The Story of Skills” — 悪意あるスキル
brand-landingpageが全スキャナーを通過し外部リンクの差し替えで実行に到達した検証。マネージド・マーケットプレイス(AIR Marketplace)launch の文脈を含む — https://www.air.security/blog-posts/the-story-of-skills - The Hacker News: “Fake AI Agent Skill Passed Security Scans and Reportedly Reached 26,000 Agents”(2026-06)— https://thehackernews.com/2026/06/fake-ai-agent-skill-passed-security.html
- The Next Web: “A fake AI agent skill passed every security scanner and reportedly reached 26,000 agents” — https://thenextweb.com/news/fake-ai-agent-skill-security-scanners-bypassed-26000-agents
- CSO Online: “How a malicious AI agent skill passed security checks and reached 26,000 users” — https://www.csoonline.com/article/4188840/how-a-malicious-ai-agent-skill-passed-security-checks-and-reached-26000-users.html
- Cybernews: “Researchers hijack 26,000 AI agents using fake skill on Instagram” — https://cybernews.com/ai-news/fake-ai-skill-hijacks-26000-agents-instagram/
- PipeLab: “The State of MCP Security 2026”(background literature)— https://pipelab.org/blog/state-of-mcp-security-2026/
- Cycode: “OWASP MCP Top 10”(background literature)— https://cycode.com/blog/owasp-mcp-top-10/
Brief 配布について
本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。
(c) 2026 FRAME00, INC. — Built for decisions that matter.