為 AI 開發流程建立威脅模型

選擇範圍有限的情境

先從大家能理解的一個流程開始。例如，代理程式讀取議題、編輯儲存庫、執行測試，然後開啟 PR。納入讓這些操作得以執行的系統。

列出重要資產：原始碼、客戶資訊、存取憑證、發布產物和服務可用性。確認各項資產的負責人，再找出哪些人與系統能讀取或修改每項資產。

OWASP 建議先為系統建模、辨識威脅、選擇應對方式，再驗證結果。及早使用這個方法，並隨系統變更更新。威脅建模指引。

為虛構的議題到 PR 流程，畫出下列連結：

Issue → agent → repository → test runner → artifact store → deployment

加入模型提供者與機密值儲存位置。標記哪些內容來自信任程度較低的來源，也標記身分在哪裡取得新能力，例如從讀取議題，進一步變成可寫入儲存庫檔案。

只看應用程式圖，無法掌握完整開發風險。正式環境資料庫可能不對外開放，但 CI 工作仍可能暴露存取憑證。暫時環境與技術支援存取若影響情境，也要納入。

避免只寫「AI 可能不安全」。寫出行為者、操作、受影響資產和後果，並包含情境發生所需的條件。

這些只是範例，不是完整威脅清單。實際資料、工具與維運環境，決定哪些情境相關。

依後果與有根據的暴露程度排序優先順序。不要用數字分數營造並不存在的精確度。記錄不確定性，以及哪些證據可能改變優先順序。

應對方式可以是移除有風險的能力、縮小範圍、新增控制措施，或接受已定義的剩餘風險。接受風險需要有授權的負責人與理由，不應採用代理程式未經審查的結論。

將選定應對方式轉成工作，並設定可觀察的驗收條件。「改善代理程式安全」很難驗證；「測試工作無法讀取正式環境機密值」，則定義了可以檢查的邊界。

新連接器、模型路徑、環境或權限，都可能改變威脅模型。將這些變更加入複查觸發條件，也使用事件與失敗的評估結果更新假設。

試做風險審查練習，調整情境中的資料、權限、使用對象和復原條件。結果會提出問題，但不能取代針對特定系統的威脅模型，也不會授權執行工作。