最近看到 Simon Willison 整理 RubyGems 疑似被 agent swarm 濫用的調查，先說在前面：來源描述的是可疑套件、oai 痕跡、RubyDoc.info 建置流程被拿來抓資料，甚至有嘗試找 API keys 的行為，但目前不該把尚未證實的歸因直接寫成「某某 agent 做的」。

我比較在意的是另一件事。只要 agent 能碰外網、能裝套件、能讀環境變數，安全邊界就已經不在 prompt 裡了。Prompt 可以要求它「不要做壞事」，卻不能阻止依賴套件在 post-install script 裡做壞事，也不能保證它不把一次任務中看到的 secret 帶到下一個請求。

我之前整合 AI 工具時踩過一個很蠢但很典型的坑：為了讓 agent 自己跑測試，直接把 CI job 的 GITHUB_TOKEN 和 package registry token 放進同一個環境。當下測試很順，後來才發現它連讀取 issue、推 branch、發 package 的權限都有。最後花一個下午拆成三個 service account，權限改成唯讀起步，需要寫入時才由明確的 workflow 授權。慢一點，但至少知道哪個動作是誰批准的。

現在如果要讓 agent 接套件倉庫，我會先做幾個最低限度的設定：

• 預設沒有 secret，真的需要時用短效 token，scope 限定單一 repo 或單一 registry。
• 網路採 allowlist，package build 放隔離 container，禁止碰 host filesystem 和 metadata endpoint。
• 每次 tool call 記錄輸入、輸出、身份、版本、時間戳，log 至少保留 90 天，不能只留一句「agent completed」。
• dependency 先鎖版本、驗 checksum，安裝和發布分成不同身份，發布還要人工或另一個獨立 job 放行。

最後是事後通報。平台若發現大量異常套件，除了下架和封鎖來源，也要把時間範圍、受影響套件、可能暴露的資料類型講清楚，讓使用者能查自己的 log。歸因可以慢一點，證據鏈不能沒有。Agent 的能力越像一個真的工程師，權限、稽核和供應鏈隔離就越不能靠一句 prompt 撐著。