SkillJect 把 coding agent 的弱點撕開來看，下一波安全問題已經不是 prompt injection 那麼簡單

SkillJect 讓人不安的地方，不在它又替 agent 安全多發明了一個新名詞，而是它把問題重新擺回現實世界。大家原本以為 coding agent 的風險主要在提示被污染，現在看到的卻是另一種更貼近產品化場景的局面: 惡意邏輯不必直接寫在對話框裡，它可以躲在技能包、說明檔、輔助腳本、工具元資料與外部連結裡，然後借用 agent 對「能力模組」的信任慢慢進場。這種攻擊面一旦成立，開發者面對的就不再是單輪 prompt injection，而是整條技能供應鏈都有可能被利用。

這也是為什麼 SkillJect 的討論分量比一般安全事件更重。研究拆解、中文科技媒體摘要、開發者社群反應與安全圈對 agent 權限設計的批判拼起來後，可以看出它不是單純在示範某個邊角漏洞，而是在揭露一個結構性事實: coding agent 越像真正的工具使用者，就越會繼承供應鏈攻擊的老問題，而且還會額外疊上模型誤判、上下文誤信與自動執行帶來的新風險。這些風險彼此不是平行存在，而會互相放大。

傳統軟體供應鏈安全至少還能靠簽章、版本審計、套件管理和執行權限切割建立邊界。到了 agent 世界，麻煩在於很多危險訊號被包裝得更像正常協作內容。只要技能描述寫得夠自然、指令包裝得夠像最佳實踐、腳本命名看起來夠無害，模型就可能在沒有惡意意識的情況下自己把門打開。這意味著安全判斷不再只是掃毒或 lint 那樣的技術流程，而變成語義信任問題。把這條新聞和 AI Recommendation Poisoning 被正式點名，記憶層攻擊正在成為下一個安全缺口 放在一起看很有必要，因為兩者都在提醒市場，AI 系統最危險的位置往往不是輸出結果，而是那些看似方便、其實沒被嚴格治理的中間層。

這件事也直接打臉一種很流行的產品樂觀主義: 只要模型夠強，它就會自己看穿風險。實際上，模型越會調工具、越能拆解任務、越敢自主執行，出錯時造成的傷害就越大。安全不是因為能力提升就會自然變好，反而常常因為能力提升而需要更重的限制。這正是 Agent API 真正想賣的不是又一個接口，而是把代理執行環境直接商品化 這條後續主線值得追的原因，因為當執行環境本身被獨立成產品，市場等於在承認光靠模型判斷不夠，還需要外部運行框架幫忙縮風險。

對採購方來說，SkillJect 最現實的後果是評估標準會變。大家之後不只看 coding agent 能不能補檔、修 bug、生成測試，而會看技能來源是否可驗證、外部工具是否可審計、每一步執行是否可追蹤、權限是否默認最小化、敏感操作是否一定要人工確認，以及失敗是否能安全回退。這和以往買一般開發工具完全不同，因為你不是在買一個被動的 IDE 外掛，而是在買一個會自己做事的半自主系統。

反過來說，這也會讓真正重視治理的產品有機會和只會秀 demo 的 agent 拉開差距。那些能把技能來源驗證、執行沙箱、權限隔離、審計紀錄與可視化 trace 做好的平台，之後會比只會講模型能力的產品更有企業說服力。因為當 agent 要進入真實程式開發流程時，安全不會是加分項，而是准入門檻。

SkillJect 最後是否會變成產業常用語，其實沒那麼重要。真正重要的是它逼大家正視一件事: coding agent 的風險已經從輸入框升級到技能供應鏈。如果平台還想把這件事講成少數邊緣案例，後面只會讓開發者更不敢把高權限任務交出去。現在市場要回答的不是 agent 能不能寫程式，而是它有沒有資格碰你的程式、你的秘密和你的部署權限。