AIエージェントの“スキル”2.25万件を監査—約3割にリスク、コードではなく「供給網」が新たな攻撃面になります

今日の深掘りポイント

• 2万2,511件のAIエージェント用“スキル”を監査し、約3割にセキュリティリスクが確認されています。AIが生成・実行するコードだけでなく、ツール連携そのものが新たな攻撃面になっている構図です。
• 生成AIの普及でソフトウェア供給網はツール・コネクタ・外部APIへ水平展開し、国境を越えた委託関係の“連鎖”が開発現場に常駐するようになりました。従来のSAST/SCA/コンテナスキャンだけでは死角が残ります。
• リスクは「今すぐ手を打てる領域」が多く、CI/CDのポリシー更新（スキルの許可制・依存関係の固定・権限分離・ネットワーク制限）に直結します。完璧主義よりガードレールの段階的実装が効果的です。
• 攻撃シナリオはサプライチェーン型の初期侵入、OAuthトークンの横取り、エージェントのツール呼び出しを悪用した横展開が中心です。MITRE ATT&CKでの検知・緩和ポイントを明確化します。
• メトリクスが示す通り「新規性は高め、実行可能性は高いが楽観視は禁物」です。導入現場が最短経路で“安全にAIを使う”ための運用設計に舵を切る段階です。

参考：監査の概要と数値はThe New Stackの報告に基づきます（2万2,511スキル対象、約3割にリスク）［The New Stack］。

はじめに

生成AIがコードを書くだけでなく、外部ツールやAPIを呼び出して“実行”まで担う時代に入りました。エージェントが使う小さな機能モジュール——いわゆる“スキル”（各種プラットフォームが公開・流通させるツール・コネクタ・アクション群）——は、利便性の裏で供給網の新たなノードになっています。
今回の監査では、2万2,511件という規模でスキルの実装や依存関係が点検され、約3割にセキュリティリスクが確認されました。AIが生成するコードに潜む欠陥だけでなく、「スキルの設計・実装・更新運用」そのものが踏み台になり得る現実が可視化されたと言えます。これは単なる品質管理の話ではなく、CI/CDと組織ポリシーをどこまで“AI時代対応”に刷新できるかという、即応課題です。

出典：

• The New Stack “Security Researchers Audit 22,511 AI Agent Skills”［The New Stack］(https://thenewstack.io/ai-agent-skills-security/)

深掘り詳細

事実関係（何が起きているか）

• 監査対象はAIエージェントが利用する“スキル”2万2,511件で、約3割にセキュリティリスクが見つかったと報告されています［The New Stack］。
• 指摘の主眼は、AIが生成するコードに従来見落としがちな脆弱性が含まれやすい点に加え、スキルそのものの設計・依存・公開運用がソフトウェア供給網として脆くなっている点にあります［The New Stack］。

この時点で押さえるべきは、「エージェントの機能はコード＋スキルの合成物」であり、守るべき境界が“ソースコードの外側”へ広がっている事実です。

出典：

• The New Stack (https://thenewstack.io/ai-agent-skills-security/)

インサイト（なぜそれが問題になるのか）

• 攻撃面の質的変化：AI生成コードの脆弱性は静的解析で拾いにくい変種（危険なデフォルト設定、未検証のツール呼び出し、権限過多のコネクタ利用）が混じりやすいです。しかも、スキルは外部API・SaaS・社内システムと直結しやすく、1つの欠陥が“組織境界を越えた権限”に直通します。
• 供給網のスピード：スキルは頻繁に更新・追加され、依存パッケージも動的です。開発者体験を損なわずに「許可・検証・ロールバック」を機械化できなければ、CI/CDに脆弱性の“最短経路”が開きます。
• 「人間の思考の外」にある実行：エージェントが半自律的にツールを連鎖呼び出しすると、レビューの“目”が届かない箇所で副作用が起きやすく、事後の監査ログが唯一の手掛かりになりがちです。設計として「踏み外しても被害が限定的」なガードレールを先に敷くべき段階です。

メトリクスの読み解きと現場示唆（総合所見）

• 報告のトーンは、目新しい脅威ながら行動に直結する具体性が高い領域に焦点が当たっているという印象です。ポジティブさは高くないものの、発生確率と信頼性は実装現場の肌感と整合的で、放置コストが積み上がるタイプのリスクです。
• 現場的には「完全な自動防御」を狙うより、次の3点を短期にやり切るほうが効きます。
  1. スキルの許可制（allowlist）＋依存の固定（pinning）＋最小権限（Least Privilege）
  2. 実行サンドボックスとネットワークのデフォルト拒否（egress制御）
  3. スキル呼び出しの監査ログと人間の承認ゲート（高リスク操作のみ）

脅威シナリオと影響

以下は想定シナリオです。具体的な事例が公表されていない部分は仮説であることを明示します。

• シナリオ1：悪性アップデートによるサプライチェーン初期侵入（仮説）

  1. 攻撃者が人気スキルへ悪性アップデートを流し込み（または依存パッケージをすり替え）、開発者環境やCIでロードされます。
  2. ロード時にスクリプト実行で環境変数のクレデンシャルを収集（T1552 Credentials In Files/Env）し外部送信（T1567 Exfiltration Over Web Services）します。
  3. 取得したトークンでSaaS/リポジトリへ正規アクセス（T1078 Valid Accounts）し、CI/CDに改ざんを展開します。
     関連ATT&CK: Supply Chain Compromise（T1195）, Trusted Relationship（T1199）, Credentials In Files（T1552）, Valid Accounts（T1078）, Exfiltration Over Web Services（T1567）, Command and Scripting Interpreter（T1059）
     参考: T1195, T1199, T1552, T1078, T1567, T1059

• シナリオ2：無害に見えるスキル＋プロンプト注入の連鎖悪用（仮説）

  1. エージェントが外部文書やIssueを取り込み、その中に仕込まれたプロンプト注入がツール呼び出しを誘発します。
  2. スキルの設計が「任意コマンド実行」や「広域APIアクセス」を許し、意図せずデータを第三者SaaSへ送出（T1567）します。
  3. 一連の操作は正規ツール利用に見えるため、振る舞い異常検知が弱いと見逃されやすいです。
     関連ATT&CK: Command and Scripting Interpreter（T1059）, Exfiltration Over Web Services（T1567）, Masquerading（T1036）
     参考: T1059, T1567, T1036

• シナリオ3：OAuthコネクタの権限過多からの横展開（仮説）

  1. スキルにハードコード/誤構成のトークン（T1552）や広すぎるOAuthスコープが存在します。
  2. 攻撃者が得たトークンでSlack/Jira/GitHubなどのSaaSへ侵入（T1078）し、組織の“信頼済み自動化”として横展開します。
  3. CI/CDのシークレットやアーティファクトに到達し、リリース成果物へバックドアを混入（T1195/T1574 Hijack Execution Flow）します。
     関連ATT&CK: Credentials In Files（T1552）, Valid Accounts（T1078）, Hijack Execution Flow（T1574）, Supply Chain Compromise（T1195）
     参考: T1552, T1078, T1574, T1195

影響評価の勘所

• 短期：リポジトリ流出、SaaS横展開、顧客データの二次持ち出し。
• 中期：CI/CDに改ざんが入り、ユーザー環境へマルウェアが“正規アップデート”として到達。
• 長期：AI導入の停止・巻き戻しコスト、規制準拠（SSDF等）での不適合対応。

セキュリティ担当者のアクション

“できること”から前倒しで積み上げるのが得策です。以下は実運用の優先度順に並べています。

• スキルのガバナンスと最小権限

  • 企業内で利用可能なスキル/ツールの許可リスト化（マーケットプレイスの自由導入を停止）
  • スキルごとの権限スコープ最小化、機密リソースはデフォルト拒否（deny-by-default）
  • 依存関係の固定（pinning/lockfile）と再現可能ビルドの徹底（SLSAの段階達成を目標に）［SLSA v1.0］

• 実行環境の分離と危険操作のゲート

  • スキル実行はエフェメラルなサンドボックス（コンテナ/gVisor/Firejail等）に隔離
  • ネットワークはアウトバウンドも原則遮断、スキル単位で必要な宛先のみ許可
  • 高リスク操作（シェル実行、外部送信、認可変更）は人間のワンクリック承認を必須化

• シークレットとアイデンティティ

  • 長期トークン/PATを撤廃し、OIDCなどの短命・スコープ限定トークンに移行
  • コミット前スキャン（pre-commit）とレポジトリ監視でシークレット露出を継続検知

• 生成コードとスキルの二重スキャン

  • 生成コード：SAST（CodeQL/Semgrep等）、依存SCA、IaC/ポリシーLintを必須ゲートに
  • スキル：SCA＋既知悪性シグネチャ、危険パターン（任意コマンド実行、ワイルドカードAPI）をルールでブロック
  • LLM特有の脅威（プロンプト注入・ツール濫用）はOWASP LLM Top10を基礎にテストケースを用意［OWASP LLM Top10］

• 可観測性とフォレンジクス

  • エージェントのツール呼び出しを構造化ログ化（誰が・どのスキルで・何を・どこへ）
  • 異常検知は“挙動の文脈”で判定（例：非業務時間帯に広域SaaSへ大量送信）
  • 監査ログは90日以上の保持と検索性確保、インシデント対応手順に組み込み

• ポリシーと教育

  • 「AI in SDLC」社内基準を文章化（許可されたスキル、審査手順、ロールバック）
  • コードレビューに“AI生成フラグ”を付与し、レビューアの注意配分を最適化
  • 開発者向けに「ツール呼び出しが生む権限の連鎖」を可視化した短時間トレーニングを提供

• 進捗の見える化（KPI例）

  • 許可リスト外スキルのブロック率、依存固定率、サンドボックス実行率
  • 高リスク操作の人的承認カバレッジ、インシデントの平均検知時間（MTTD）

参考フレームワーク

• NIST SP 800-218（SSDF）：AI時代でも有効なソフトウェア供給網の基礎アクティビティの参照軸になります［NIST SSDF］。
• SLSA v1.0：ビルド整合性と由来保証の成熟度モデルとして、スキル配布の検証にも適用できます［SLSA v1.0］。
• Sigstore：署名とサプライチェーンの検証基盤として実装の第一歩に最適です［Sigstore］。
• OWASP Top 10 for LLM Applications：エージェントとツール呼び出しの設計・テストの土台に使えます［OWASP LLM Top10］。

参考情報

• The New Stack: Security Researchers Audit 22,511 AI Agent Skills（監査規模・約3割のリスクに関する一次報道）https://thenewstack.io/ai-agent-skills-security/
• MITRE ATT&CK Techniques: T1195 Supply Chain Compromise https://attack.mitre.org/techniques/T1195/
• MITRE ATT&CK Techniques: T1199 Trusted Relationship https://attack.mitre.org/techniques/T1199/
• MITRE ATT&CK Techniques: T1552 Unsecured Credentials https://attack.mitre.org/techniques/T1552/
• MITRE ATT&CK Techniques: T1078 Valid Accounts https://attack.mitre.org/techniques/T1078/
• MITRE ATT&CK Techniques: T1567 Exfiltration Over Web Services https://attack.mitre.org/techniques/T1567/
• MITRE ATT&CK Techniques: T1059 Command and Scripting Interpreter https://attack.mitre.org/techniques/T1059/
• MITRE ATT&CK Techniques: T1036 Masquerading https://attack.mitre.org/techniques/T1036/
• MITRE ATT&CK Techniques: T1574 Hijack Execution Flow https://attack.mitre.org/techniques/T1574/
• NIST SP 800-218 (SSDF) https://csrc.nist.gov/publications/detail/sp/800-218/final
• SLSA v1.0 Specification https://slsa.dev/spec/v1
• Sigstore https://www.sigstore.dev/
• OWASP Top 10 for LLM Applications https://owasp.org/www-project-top-10-for-llm-applications/

最後に——AIの利便は、私たちが“境界の再設計”を怠らない限り、十分に安全に享受できます。スキルという新しい部品を組み入れた供給網をどう見える化し、どこで止め、どこで通すか。その設計を、今日からCI/CDとポリシーに落とし込んでいきたいところです。