Agent workflow permissions 是怎麼運作的？我用一條真實連結把它講清楚

權限不是開關，而是代理（Agent）的操作邊界

假設你正在建立一個能自動讀寫程式碼、提交 PR、呼叫 AWS CLI 的 Agent。你告訴它“部署到生產環境”，Agent 需要哪些權限？很多人第一個反應是「給一個 admin 憑證就行」──這正是第一號迷思。

Agent workflow permissions 不是像門禁卡那樣「有/無」的二元開關，而是一組細粒度的作用域和限制。每個權限實際上要做的是兩件事：定義 Agent 能操作哪些資源，以及它可以在這些資源上執行什麼動作。

一條真實連結：從意圖到執行

我幾年前接手過一條 CI/CD 管線，其中 Agent 負責：拉代碼 → 跑測試 → 建置鏡像 → 推送到 ECR → 更新 ECS 服務。這個流程涉及六個不同的權限集合：

1. 代碼倉庫讀取權限（拉取代碼）
2. 建置環境寫入權限（快取、日誌）
3. 鏡像倉庫寫入權限（推播鏡像）
4. 編排服務更新權限（觸發部署）
5. 密鑰管理讀取權限（取得資料庫密碼）
6. 日誌寫入權限（記錄執行結果）

當時我圖省事，給 Agent 綁定了一個「開發者全權限」角色。第一周運作正常。第三週，一次誤操作讓 Agent 刪除了未使用的 EBS 磁碟區——那個磁碟區上還有三天的測試資料。修復花了團隊兩天。

那之後我才真正理解到：agent workflow permissions 不是“能做什麼”，而是“如果它做錯了，損失有多大”。

權限檢查清單：對照你的 Agent 過一遍

以下是我從那時起一直使用的檢查清單。每次新建 Agent 工作流程時，我都會逐條確認：

• 每個步驟是否只擁有執行自身任務所需的最小權限？例如，測試步驟不需要修改 ECR 的權限。
• 權限作用域是否限定了資源 ID 或標籤？例如只允許操作標籤為 env=staging 的資源。
• 敏感操作（刪除資源、修改 IAM、讀寫金鑰）是否有額外確認機制？例如二次審批或人工幹預步驟。
• 工作流程是否在獨立的 IAM 角色下運作？不要把多個 Agent 塞進同一個角色裡。
• 權限策略是否有版本控制？每次變更都能回滾和審計。
• 是否設定了執行逾時和頻次限制？避免無限重試導致權限放大。

最容易踩的坑

**坑一：把 Agent 的角色綁定到使用者。 ** 許多平台允許用當前使用者憑證直接創建 Agent。好處是快捷，壞處是 Agent 獲得的是使用者全部權限，包括刪除不相關資源的權限。正確做法是為每個工作流程建立專用角色。

**坑二：忽略跨帳戶權限。 ** 當 Agent 需要存取另一個 AWS 帳戶的 S3 儲存桶時，不僅需要本帳戶角色有 AssumeRole 權限，還要求對方帳號信任這個角色。這個環節最容易被遺忘，導致運行時「權限不足」報錯。

**坑三：權限策略過於寬鬆的 Resource 欄位。 ** 例如 "Resource": "*" 會讓所有資源暴露。即使 Action 限制為 s3:GetObject，一旦桶策略允許，Agent 就能讀取整個桶。建議始終將 Resource 限定到具體桶路徑或資源 ARN。

失敗了怎麼辦：降級與逃生艙

即使做了最完善的檢查，Permission 錯誤仍然可能發生。我遇到的是 Agent 在凌晨三點嘗試更新 ECS 服務時，因角色會話逾時而失敗。解決方案不是給予更大權限，而是：

1. 在 workflow 中增加重試邏輯，並捕獲權限異常後自動降低操作目標（例如從「更新服務」降級為「只輸出 diff」）。
2. 準備一個備用角色，該角色只有唯讀權限，用於調試和生產快照。
3. 記錄鑑權失敗日誌到獨立的安全帳戶，方便事後審計原因。

總結

Agent workflow permissions 的核心不是阻止一切風險，而是把風險控製到可接受範圍。每個權限聲明都是一道防線。下次你在 workflow 裡加入一個步驟時，不妨多問一句：如果這個步驟被惡意利用，我的最大損失是多少？答案會引導你寫出更安全的權限策略。