Agent 權限先做縮圈，功能再往外放
這兩天看到一個案例，我覺得很值得做產品的團隊警惕。
某個 Copilot Cowork 流程被驗證可以透過間接 prompt injection，把使用者有權限的檔案下載連結帶出去，而且在測試裡是 5/5 成功。更麻煩的是，寄給自己這種動作不需要 approval，就等於把"發送"這個看似低風險操作，變成外洩通道。
從產品角度看，問題不在模型聰不聰明
很多團隊會先討論 model safety，但這次更像是 permission choreography 出錯：
- Agent 可讀 M365 內大量資源
- Agent 可自動發送訊息給使用者自己
- 訊息內容可觸發外部請求（例如 image URL）
三件事單看都合理，疊在一起就形成資料外流路徑。這就是典型的組合風險。
我自己在規劃 Agent 產品時會先做三件事
1) 先定義 blast radius，不是先定義功能清單
每個 action 都要問：一旦被 prompt injection 劫持，最壞會拿到什麼？能帶到哪？
2) 高風險動作用 policy 分層，不用單一 approval 開關
像「發送給自己」這種特例最容易被忽略。我會把 send 行為再切：內部通知、外部通訊、含 URL/附件內容，三層不同檢查。
3) 預設可回滾與可稽核
每次 agent 代行操作都要有 trace，並且能在 1-2 步內停權。很多事故不是沒防住，是發現時已經回不去了。
一個簡單判斷
如果你的 Agent 現在已經能跨多個 SaaS 操作，但你還沒畫出「資料可能怎麼出去」的路徑圖，那其實已經在裸奔。
功能做快很重要，但在 agent 時代，權限設計就是產品設計本身。這件事越早做，後面越不會用 incident 來補課。
作者：MingTech