The Guardrail Company Got Owned. Skill Provenance Is the Layer Below.

_2026-05-11 那波 Mini Shai-Hulud npm/PyPI 蠕蟲污染了 404 個套件版本，跨 JavaScript 和 Python 生態。其中兩個受害者是大部分團隊預設信任的廠商：Mistral AI（前沿模型 lab）和 Guardrails AI（runtime LLM-output guardrail 提供商）。Runtime 層的 guardrail 攔不住 install time 投放的攻擊。Detection layer 必須在 guardrail 之下。_

中標的東西

Akamai、Wiz、CSA 的研究員追蹤這波到 2026-05-17。Help Net Security 和 The Hacker News 報導了時序。中標清單至少包括：

• ●@mistralai/mistralai — Mistral 官方 TypeScript SDK on npm。Payload 透過 npm prepare lifecycle hook 投放（和 TanStack 同一個 install vector）。
• ●mistralai 和 guardrails-ai — Mistral 和 Guardrails AI 官方 Python SDK on PyPI，payload 由 __init__.py 的 on import side effect 觸發，下載 /tmp/transformers.pyz 從 git-tanstack[.]com。
• ●TanStack packages（@tanstack/router、@tanstack/query 等）— 同一家族，npm prepare lifecycle hook 透過 Bun runtime 投放。
• ●UiPath packages（這波另一個 sub-cluster）用 npm preinstall hook 呼叫 node setup.mjs 當 install vector。

Wiz 和 Aikido 的分析估計總共 403 個 trojanized package versions，分布在約 172 個獨立 package 上，累積過去十二個月 5 億 1,800 萬次下載。

Payload 做什麼

這波攻擊有三個 artifact:

1. `gh-token-monitor` — 持續駐留的 daemon，透過 macOS LaunchAgent（~/Library/LaunchAgents/com.user.gh-token-monitor.plist）或 Linux systemd user service（~/.config/systemd/user/gh-token-monitor.service）安裝。Daemon 用開發者的 GitHub token 每 60 秒 poll 一次 api.github.com/user。

2. Dead-man's switch — 當 polled token 回 HTTP 401（開發者輪換或撤銷 token），daemon 對整個 home directory 跑 rm -rf ~/（依 Wiz 和 JFrog 分析）。毀滅動作是條件觸發的，這就是為什麼純靜態 manifest 掃描抓不到 daemon。

3. Exfiltration 通道 — filev2.getsession[.]org（走 Session Protocol）、api.masscan[.]cloud（GitHub Actions secret serialization）、typosquat git-tanstack[.]com 拿來收 credential。83.142.209[.]194 這台 host 已確認在跑 PyPI credential stealer。

Mistral 在 2026-05-12 開了一個公開 security advisory 頁面 docs.mistral.ai/resources/security-advisories，承認 TypeScript SDK 中標。這是 Mistral 第一次跑公開 security advisory 頁面。也是對的動作。

為什麼 runtime guardrail 攔不到這個

Guardrails AI 的產品就是字面意思 — 一個包在 LLM output 外面的 runtime guardrail。它驗證 model response 符合預先宣告的結構和安全約束，才把 response 放給 user 或下游 tool。Lakera、PromptArmor、Protect AI、Lasso Security 以及閉源同類產品都在做一樣的事，在一樣的 layer。

這些產品在他們自己那層做得很好，但他們全都活在 stack 的同一層。沒有一個會去檢查 pip install guardrails-ai 執行時跑的 __init__.py 內容，因為 runtime guardrail 載入的時候，install-time daemon 已經在磁碟上落地三到五分鐘了。Runtime guardrail 定義上就在 install 之後。

這不是針對特定廠商的攻擊。這是一個 layering 觀察。一個 guardrail 廠商自己在 install time 中標，意味著他們產品處理的 threat model 沒有延伸到送他們產品上門的 supply chain。那個 threat 的 detection layer 在更下面。

ATR 為這件事出的規則

Agent Threat Rules v3.1.0 出 ATR-2026-00525 覆蓋 Mini Shai-Hulud 家族。規則對任何到 agent runtime 或 skill scanner 的文字觸發三條 alt:

1. 字面 daemon 名稱 gh-token-monitor、gh_token_monitor，或 LaunchAgent label com.github.token.monitor。 2. 在 500 字元內配對：對 api.github.com/user 的 polling loop + 毀滅性 shell primitive（rm -rf、shutil.rmtree、os.system rm）— 也就是 dead-man's-switch 形狀。 3. 在 300 字元內配對：interval/timer 結構（setInterval、threading.Timer、asyncio.sleep）+ /user poll + shell execution primitive（child_process、exec、毀滅指令）— 也就是 install-time daemon 形狀。

覆蓋度誠實講：規則抓到的是 Akamai、Wiz、Sysdig 公開 writeup 中出現的 canonical IOC。它抓不到 dead-man's-switch pattern 的每一種 obfuscation。規則的 true_negatives block 文件化了刻意接受的 FP case 和明確拒絕的 case。Source 在 Agent-Threat-Rule/agent-threat-rules main 上的 skill-compromise category。

一層一層的偵測 map

對今天在建構或採購 AI security 的團隊來說，layer 是這樣排的：

|---|---|---|

五層裡有三層看不到這次攻擊。能看到的兩層不是 runtime guardrail 廠商所在的層。PanGuard 從 2026 年 3 月 v0.1 開始的 positioning，就是 skill-content layer 加 manifest layer。這不是一句行銷詞。這是這次攻擊真實浮現的層。

我們不主張的事

幾個誠實揭露，讓這篇文不變成廠商 cosplay：

• ●ATR 是被動的。規則裡的 gh-token-monitor 字串是一個 IOC；下一個 worm 會用不同 daemon 名稱，規則第一個條件就需要更新。規則第二、第三條件（dead-man's-switch 形狀和 timer-plus-shell 形狀）是 pattern-based，應該 generalize 比較好，但 pattern-based 規則也會有 false negative。
• ●ATR 是 MIT open source。它不是 PanGuard 獨有的。任何人用 ATR 的 npm package、MISP feed，或 Cisco AI Defense scanner config，拿到的是一樣的覆蓋。差異化不在規則本身，在 disclosure 到 shipped rule 的 loop 時間。這次攻擊 disclosure 是 2026-05-11，對應規則 ship 是 2026-05-23，十二天。太慢了。Microsoft Copilot Semantic Kernel 那個 loop 在 2026-05-11 兩小時十六分鐘收尾，是因為 disclosure 帶了可用的 PoC。Mini Shai-Hulud 的 writeup 沒帶，這就是這個 loop 比較慢的結構原因。
• ●對 runtime guardrail 廠商的誠實 framing 是「不同的 layer，兩個都需要」，不是「我們取代他們」。Runtime LLM-output guardrail 抓的是和 skill-content scanner 不同的攻擊類別。成熟的部署會兩個都跑。這篇的 point 是：只跑 runtime guardrail 留下一層沒蓋到。

這週可以做的事

1. 如果你的依賴樹有 @mistralai/mistralai、mistralai 或 guardrails-ai，audit 你的 install：npm ls @mistralai/mistralai + pip show mistralai guardrails-ai。Mistral 的 advisory 頁面列了具體 bad version。Pin 到 patched release。

2. 檢查 persistence daemon：macOS 上 launchctl list | grep -i token-monitor，Linux 上 systemctl list-units | grep -i token-monitor。Daemon 的 plist label 是 com.github.token.monitor，systemd unit 叫 gh-token-monitor.service。

3. 如果你出 agent platform，把 skill-content scan 加進 registration flow。ATR 規則是一個檔加 YAML；它 load 進任何吃 ATR format 的 rule-runner。Microsoft Agent Governance Toolkit、Cisco AI Defense、MISP 今天都在跑。

4. 如果你做 runtime guardrail 產品而且讀到這邊，誠實的 move 是加一個 skill-content 或 package-manifest 的 companion scanner。Runtime layer 是必要的。但它不夠。

收尾

如果你的 AI security architecture 只檢查 runtime output，supply chain 就是你的盲點。Mini Shai-Hulud 是經驗證據。Guardrail 公司被打穿了。Detection layer 必須在更下面。

_Adam Lin 維護 Agent Threat Rules，一個 MIT 授權的 AI agent 威脅偵測 corpus。ATR 規則在 Microsoft、Cisco、MISP 都在跑。同時是 Panguard AI 的 founder（Delaware C-Corp，做 ATR 標準的商業化產品）。聯絡：[email protected]_