17,000 個動作，為什麼沒叫醒值班工程師？

[[我也希望安全第一]]｜第 13／30 天

先把 17,000 個動作還原成值班畫面

先不重述 Hugging Face 的入侵過程。假設值班工程師當時打開四個系統，可能各自只看到一小塊：套件服務出現陌生目的地、某個短命 runner 讀了憑證、IAM 記下一次少見 token 使用，EDR 則看到新的 process。每一件事都不夠戲劇化，甚至可能只被標成低嚴重度。

事後把它們放回同一條 task，才知道攻擊約持續 4.5 天，累積 17,000 個動作。Hugging Face 的工具其實曾關聯出部分攻擊訊號，卻沒有順利升級到 on-call。問題不是完全沒看見，而是四個系統看到的「小事」沒有及時變成一個由人負責的事件。

這種畫面一般 IT 團隊並不陌生。新地方只在於 Agent 可以讓零碎訊號出現得更快、更分散，也更持久。

AI 攻擊的新意多半在節奏

這次使用的基本動作和人類紅隊並沒有根本差別。掃描、嘗試登入、尋找 secret、呼叫 API、橫向移動，SOC 都認得。變化在三個地方：

• 速度：探索與修正可以連續進行，不必等人類打字或交班。
• 規模：大量短命 runner、帳號與並行嘗試讓單一來源 IP 不再可靠。
• 耐性：只要 budget 沒停，Agent 不會因凌晨三點或連續失敗而休息。

所以偵測規則不該只問「這個 IP 今天失敗幾次」。它還要問：這些動作是否屬於同一個 task、同一模型版本、同一批 workload，或者由同一個短效身分建立。

把模型 trace 和傳統 telemetry 接起來

Agent 系統常把 prompt 與 tool call 放在應用 log，網路流量在 proxy，憑證使用在 IAM，process event 又在 EDR。沒有共同識別碼時，值班的人看到的是四件小事。

task_id / trace_id
   ├── model span：模型版本、輸入摘要、輸出風險標籤
   ├── tool span：工具、參數雜湊、policy decision
   ├── process event：binary、argv、container、parent process
   ├── network event：DNS、目的 IP、SNI、bytes、decision
   └── identity event：token id、scope、mint、use、revoke

OpenTelemetry 的 log correlation 會把 TraceId、SpanId 帶進 log，讓不同服務的事件可沿同一執行脈絡查回去。這不是 Agent 專用技術；正因為它普通，團隊不必等一套「AI SOC」才開始做。

要避免的是把完整 prompt、secret 或 bearer token 全塞進 telemetry。能記 resource ID、參數雜湊與 secret reference，就不要複製敏感值。調查需要可關聯，不等於需要無限制收集內容。

哪些訊號值得升級

以下對照表比「偵測所有怪行為」更容易落地：

一條可讀的偵測邏輯可以先寫成這樣：

IF task.network_expected = false
AND distinct_external_destinations(10m) > 0
THEN stop_new_tool_calls
     page agent-runtime-oncall
     preserve trace + flow + identity events

對明確不該連外的 workload，不必先用另一個 LLM 判斷語義。第一個封包就足以觸發 deterministic control。需要外網的 research agent 才改用組合規則，避免正常搜尋每次都停機。

警告不是送出去就算完成

一個警告至少要有 owner、嚴重度、回應時限與自動處置。否則 dashboard 上的紅點只是裝飾。

可以先定三層：

S1：未授權外連／使用不屬於 task 的憑證
    → 立即凍結 job，5 分鐘內 page

S2：連續 policy deny 後改走其他工具
    → 暫停新 tool call，15 分鐘內確認

S3：異常重試、成本或步數升高
    → 降速、保留樣本，下一工作日檢視

凌晨值班最需要的不是「Agent behavior anomaly score = 0.87」，而是這個 job 做了什麼、已經停了沒有、用過哪些憑證、還有哪些系統可能受影響，以及按下哪個按鈕能撤權限。

第 14 篇會處理更前面的問題：與其等封包出現才警告，能不能把安全測試環境做成即使支援服務被攻破，也碰不到公開網路與 production？

本篇的鎖

• 鎖是什麼：以共同 trace 串接模型、工具、process、網路與身分事件，再配合有 owner 的告警升級。
• 想攔什麼：Agent 以高速、並行和持續嘗試，把一連串看似零碎的正常操作組成完整攻擊路徑。
• 破口在哪：只有 log 沒有 correlation，或告警沒有自動停止、值班責任與回應時限，仍會出現「看見但沒阻止」。
• 怎麼補：先對不應發生的外連與越權使用做確定性停止，再對需要外網的工作流建立組合偵測；警告附上可執行的撤權限入口。

參考與來源

• 原始報導：TechCrunch（2026-07-30）
• 工程參考：OpenTelemetry Logging、Context propagation