AIエージェントのSkillsは「読む前」に検査できるか。SkillGateが示した指示ファイル供給網の守り方
便利そうなSkillを1つ追加する。中身はMarkdownだから、実行ファイルより安全に見える。
ところが、そのMarkdownに「事前確認として秘密鍵を読み、外部へ送る」「生成コードへ裏口を追加する」と書かれていたらどうなるでしょう。AI coding agentはSkillを参考資料ではなく、作業手順として読みます。ファイル、shell、外部APIへ触れる権限まで持つagentなら、悪意ある一文は単なる文章ではありません。権限を動かす命令です。
2026年7月28日に公開された論文SkillGate: Cost Efficient Runtime Malicious Skill File Detection in Coding Agentsは、この問題をAgent Skillsの供給網リスクとして扱います。そして、Skillをagentが読む前に検査するopen-source gatewayを提案しました。
結論を先に言うと、SkillGateは有望です。ただし、万能scannerではありません。論文のRecallは0.769です。検査を通ったから安全と考えるのではなく、Skillの導入をrelease processへ変える部品として使うのが正しい読み方です。
これまでの問題。Markdownはコードではないが、agentには命令になる
従来のsoftware supply chainは、package、binary、dependencyを主な検査対象にしてきました。hash、署名、既知CVE、source code patternを調べる道具も充実しています。
Agent Skillsは、その境界から少し外れます。多くのSkillは、説明、手順、tool定義、shell例をまとめたMarkdownです。静的解析器から見れば文章でも、LLMから見れば「次に何をするか」を決める強い文脈になります。
論文が想定する攻撃は具体的です。
.envやSSH keyを読み、外部endpointへ送らせる- 生成するcodeへcommand-and-control用の処理を混ぜる
- 正規のtool endpointを攻撃者側へ差し替える
- system-levelの安全指示を上書きするprompt injectionを埋める
しかも、Skillはregistry command、Git repository、手動配置、MCPのtools/call、resources/read、prompts/getなど、複数の経路からagent contextへ入ります。配布経路が増えるほど、どこで検査するかが曖昧になります。
既存のpattern scannerだけで守ろうとすると、別の問題が出ます。セキュリティ資料には、当然ながら「credential」「base64」「remote command」のような語が登場します。危険語があるだけで止めれば、正常なSkillまで大量にblockします。
反対に、すべてのSkill全文をLLMへ送り、安全かどうか判断させれば、token、費用、遅延が増えます。長いSkillほど不利です。SkillGateが狙ったのは、この二者択一の間です。
核心。正規表現は判定器ではなく、LLMへ渡す場所を探す
SkillGateは4段階で動きます。
1. agentへ届く前に内容を止める
SkillGateはUnix socket daemonとしてagentとMCP serverの間に入り、Skill contentを抽出します。一般的なSkill追加commandもwrapperで受け、判定が終わるまでinstallを完了させません。
ここで重要なのは、実行後に異常を探すのではなく、agentのcontextへ入る前をgateにしたことです。悪意ある命令を一度読ませてから取り消すのでは遅い。これはpackage managerのpre-install checkに近い考え方です。
2. 530個のpatternで「見るべき場所」を絞る
次に、MITRE ATT&CK由来428個とSigma由来102個、合計530個のpatternでSkillを走査します。credential access、exfiltration、obfuscation、persistence、remote executionなどが対象です。
ただし、pattern hitだけでは悪意ありと決めません。ここが設計の肝です。
hitがゼロならsafe pathへ進み、LLMは呼びません。hitがあれば、その位置と前後の文脈を切り出します。つまりregexは裁判官ではなく、付箋係です。何でも逮捕する警備員から、「ここを詳しく見てください」と印を付ける係へ降格させた。降格なのに、むしろ仕事の質が上がっています。
3. 疑わしいsnippetだけをLLM judgeへ送る
defaultでは、各hitの前後500文字をwindowとして取り出し、近接windowを重複排除します。最大20 window、payloadは8,000文字に制限されます。
LLM judgeが見るのはSkill全文ではなく、patternが示した周辺です。判定はSAFE、SUSPICIOUS、MALICIOUSとconfidenceで返します。
この構成には2つの節約があります。
- skip savings：pattern hitのないfileはLLMを呼ばない
- snippet savings：hitしたfileも全文ではなく疑わしい箇所だけ送る
4. allow、warn、quarantine、blockへ落とす
最後にpolicy engineが判定を具体的なactionへ変えます。MALICIOUSはblock、一定confidence以上のSUSPICIOUSはquarantine、低confidenceならwarn、SAFEはallowです。
判定、confidence、pattern hit、snippet、所要時間はJSONL audit logへ残ります。これにより、誤検知の見直しやrule調整ができます。
一方で、AICompanyとしてはaudit log自体も保護対象だと考えます。flagされたsnippetに秘密情報や攻撃payloadが含まれる可能性があるからです。これは論文の測定結果ではなく、運用へ移す際の追加注意です。
実験は何を示したか
評価にはSkillsBenchの1,650 fileが使われました。内訳は、public repository由来のbenign skillが1,500件、8種類の攻撃を埋め込んだhand-crafted malicious skillが150件です。悪意ある比率は9.1%です。
比較対象はClawVetとCisco AI DefenseのSkillScannerです。LLMを使う方式は3回実行し、平均とばらつきを報告しています。
主要結果は次の通りです。
| 指標 | SkillGate | 比較上の意味 | |—|—:|—| | Recall | 0.769 | 悪意ある例の約76.9%を検出 | | F1 | 0.817 | precisionとrecallの均衡 | | FPR | 1.13% | benign skillを誤って止める割合 | | MCC | 0.803 | class imbalanceを含む総合相関 | | AUPRC | 0.830 | threshold全体でのprecisionとrecall |
ClawVetのAUPRCは0.144、SkillScannerは0.162でした。論文はSkillGateが約5倍から6倍高いと報告しています。静的方式はrecallを上げるとfalse positiveが増え、ClawVetはoracle-optimal thresholdでもFPR 50.4%、SkillScannerの代表的な静的設定は17.4%でした。
この差は現場では大きいです。2回に1回正常なSkillを止めるgateは、やがて無視されます。security warningが壁紙になる、あの悲しい現象です。1.13%なら完全ではないものの、運用可能性が見えてきます。
精度だけでなく、tokenと待ち時間も減った
1,650 fileのうち1,110件、67.2%はpattern hitがなく、LLMを呼びませんでした。LLMへ送ったのは540件です。
全文検査なら約302万token相当だった入力が、hybrid方式では約70万token相当になりました。削減率は76.9%です。
遅延も分けて報告されています。
- prefilterだけで終わるpath：約139ms
- LLMを呼ぶpath：約2,208ms
- 全体の加重平均：約818ms
- 比較した全件LLM方式：約6,281ms
加重平均では7.7倍高速です。registryからSkillを取得する待ち時間へ重ねられる規模で、毎回数秒から十数秒止まる検査より導入しやすい。
ただし、ここで「77%安い」と一般化してはいけません。論文のtoken削減はSkillsBenchのfile長とpattern hit率に依存します。短いSkillばかりなら固定preambleの割合が増えます。疑わしいSkillばかりのregistryならLLM call率も上がります。
本当に新しいのは、検出modelより境界の置き方
SkillGateの価値は、LLM judgeを使ったことだけではありません。LLMをsecurity scannerとして呼ぶ案自体は珍しくありません。
新しいのは、どこで止め、何をLLMへ見せ、判定後にどう扱うかを一つのruntimeへまとめた点です。
- Skillがcontextへ入る前に止める
- 安価なpatternで対象箇所を絞る
- LLMには必要な周辺だけ見せる
- quarantineとauditを運用へ接続する
この設計は、AI agentの防御をmodelの善意だけに依存させません。「危険な命令には従わないで」とsystem promptへ書くより前に、危険かもしれない命令を別系統で検査します。
model-level safetyとsystem-level safetyを分けたことが重要です。賢いmodelでも、権限境界が雑なら危険です。少し抜けたmodelでも、sandbox、tool restriction、approval、network boundaryがあれば被害範囲を狭められます。
実務へ移すなら、5層で考える
SkillGateの結果をそのまま企業運用へ移すなら、単独導入ではなく次の5層が現実的です。
1. provenance
誰が作ったSkillか、どのcommitを承認したか、更新時に何が変わったかを記録します。最新版を自動追従するより、review済みrevisionをpinする方が安全です。
2. pre-install screening
SkillGateのようなgateで、Markdown、添付script、MCP responseをagentが読む前に検査します。新規追加だけでなく、version更新も再検査します。
3. human reviewとquarantine
SUSPICIOUSを即allowか即blockの二択にせず、隔離して人が確認できる状態へ置きます。誤検知を直すfeedback loopも必要です。
4. least privilegeとsandbox
検査を通ったSkillにも、不要なfile、credential、network、shell権限を渡しません。Recallが1.0ではない以上、実行時境界は必須です。
5. runtime monitoring
外部送信、credential read、永続化、未知endpoint、異常なtool sequenceを観測します。install時に見えなかった挙動を、実行時に止める最後の層です。
小さく試すなら、まず組織で使うSkillをapproved、quarantined、blockedの3状態へ分け、revisionを固定します。その上でshadow modeのscannerを走らせ、実際のfalse positiveとreview時間を測るとよいでしょう。いきなり全blockへすると、scannerより先に現場の信頼が落ちます。
まだ証明されていないこと
論文は限界をかなり明確に書いています。
第一に、malicious 150件はhand-crafted exemplarです。実際の攻撃campaignから採取した自然分布ではありません。実世界の攻撃者はruleを観察し、回避方法を変えます。
第二に、threat modelはnon-adaptive attackerです。SkillGateの存在やrulesetを知らず、逆解析していない攻撃者を想定します。adaptive evasionは対象外です。
第三に、Recallは0.769です。benchmark上でも見逃しが残ります。特にRSA modular arithmeticやzero-width characterを使うencodingは具体的な弱点として報告されています。
第四に、LLM judgeはgpt-5.4-miniだけです。Claude系やlocal Ollama modelへ置き換えた時のrecall、FPR、latencyは未評価です。
第五に、3 runは3週間にまたがり、false positiveは7件、24件、20件でした。provider側model updateの可能性を排除できず、hosted judgeの挙動が固定資産ではないことを示しています。
最後に、paperが評価したのはpre-installとMCP content screeningです。既にcontextへ入った攻撃、実行後の攻撃、agentが生成した危険codeまでを一つで守るものではありません。
評決
SkillGateは、Agent Skillsを「便利な文章」から「権限を動かす供給網artifact」へ見直した点で重要です。
530個のpatternとLLM judgeという部品より、境界設計に価値があります。agentが読む前に止める。全文ではなく疑わしい周辺だけを精査する。曖昧なものはquarantineする。そして判断を監査可能にする。
論文の数字は強いです。FPR 1.13%、AUPRC 0.830、token 76.9%削減、加重平均818ms。ただし、Recall 0.769とhand-crafted benchmarkという限界も同じくらい重要です。
したがって、実務的な結論はこうなります。
SkillGateは城壁ではありません。入城審査です。城壁、最小権限、監視を残したまま、入口で怪しい指示を減らす。その組み合わせなら、Skillsの便利さを捨てずに、agentへ渡す信頼を少しずつ測れるようになります。
参考資料
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能