AWS 在 re:Invent 2025 推出 AWS Security Agent 預覽版，2026 年 3 月 31 日滲透測試功能正式上線（GA），6 月又加入威脅建模、Kiro power 與 Claude Code 外掛。對企業來說，現在要思考的已經不是「要不要用 AI 做資安」，而是「AI agent 能幫忙守到哪裡，哪些環節還是要由人把關」。
本文根據 AWS 官方公布的資訊，帶您了解 AWS Security Agent 的功能、計費方式與使用限制，看 AI agent 如何把資安檢查從「上線前」提早到「寫程式之前」，並整理導入前的注意事項。
一、AWS Security Agent 是什麼？
AWS Security Agent 是 AWS 推出的「前沿代理」（frontier agent）之一，目前已納入 AWS Continuum，它不只是輔助資安人員的工具，更是能自己跑完整段應用程式資安流程的 AI agent，從檢查設計文件、審查程式碼，到上線前隨時發動滲透測試，都能一手包辦。而且它不只能用在 AWS 上，依照官方文件，AWS Security Agent 也支援地端、混合雲、多雲與 SaaS 環境，讓分散在不同平台的應用程式都能用同一套資安標準檢查。
AWS Security Agent 怎麼用？兩大介面與 Agent Space 功能說明
| 介面 | 使用者 | 用途 |
| AWS 管理主控台 | 雲端管理員 | 建立 Agent Space、設定組織資安需求與滲透測試、連接程式碼儲存庫、管理使用者權限 |
| Security Agent Web Application | 資安與開發團隊 | 執行設計審查與滲透測試、查看資安問題與修補建議 |
Agent Space 可以想成每個應用程式專屬的工作區，組織的資安需求只要設定一次，就會自動套用到所有 Agent Space，企業不必再拿一份通用檢查表逐條比對，而是讓 AI agent 照著「您公司自己的規矩」檢查每一個專案。
二、AI agent 的四大功能
傳統做法是程式寫完、準備上線時，才請資安團隊驗收，AWS Security Agent 則把資安檢查拆成四道防線，分散在軟體開發的各個階段。
AWS Security Agent 四道防線 · 設計、開發、部署＋IDE
提醒：目前只有滲透測試已正式 GA，設計審查、威脅建模與程式碼審查仍為預覽功能。
防線 1：設計審查與威脅建模——在寫程式之前就找問題
開發團隊只要上傳 Word、Markdown 等格式的設計文件，AI agent 就會依照組織的資安需求進行評估，並提出改善建議。資安規範除了可以自訂，也能直接套用 AWS 提供的受管合規包，例如 AWS Well-Architected Framework、NIST CSF、PCI DSS 與 AWS 最佳實務，公司若已有內部規範，也能從文件或 Confluence 匯入。不過要注意，這類檢查只能協助您對照安全要求，不等於正式的合規評估，也不保證能通過稽核。
6 月新增的威脅建模功能，則會從設計文件或程式碼儲存庫中看懂應用程式的資料流、架構與信任邊界，再用 STRIDE 框架找出可能的攻擊者與攻擊路徑，並幫您排好處理的優先順序。
防線 2：程式碼審查——每個 PR 都有資安把關
連接程式碼儲存庫、開啟 PR 程式碼審查功能後，只要符合設定的觸發條件，AWS Security Agent 就會自動分析 Pull Request（PR）中的程式碼變更，把發現的資安問題直接回報給開發團隊，也能對整個儲存庫做深度掃描，揪出長期累積下來的風險。目前支援 GitHub、GitLab 與 Bitbucket 等程式碼來源，也能連接 Confluence，讓 AI 審查時參考更多背景資訊，實際能整合到什麼程度，則會依來源與部署方式而不同。
它和傳統比對規則的掃描工具最大的差別，在於能用 AI 推理理解程式碼，開啟模擬驗證且環境符合條件時，還會實際嘗試確認部分問題是否真的能被利用；如果是支援的儲存庫，也能直接產生附上修正內容的 PR，由開發人員審核後再合併。
防線 3：隨選滲透測試——從「一年一次」變成「隨時可做」
這是 AWS Security Agent 最受矚目的功能，也是 AWS 過去沒有原生提供的能力。它由規劃、滲透、驗證、修補等多個分工明確的代理組成，會先讀原始碼與規格文件了解應用程式怎麼運作，再設計多步驟的攻擊情境並實際執行。測試時，AWS Security Agent 會實際驗證漏洞能否被利用，並提供測試結果、風險說明與修補建議，遇到支援的漏洞與儲存庫，也能協助產生修補 PR 給開發團隊審核。由於測試設定可以重複使用，每次改版後重跑即可，滲透測試就從卡住上線的定期關卡，變成隨時可用的日常工具。
防線 4：IDE 內的資安檢查——在開發者的 IDE 裡就把關
用 AI 寫程式的開發者大部分時間都待在 IDE 或 CLI 裡，因此 AWS Security Agent 推出了 Kiro power 與 Claude Code 外掛（AWS Agents for DevSecOps），並提供開放的 MCP 整合，開發者在 IDE 裡下指令，就能審查程式碼、產生威脅模型、查看問題並直接修補，不用在不同工具間來回切換。這正是「AI agent 守資安」最直接的價值：AI 寫的程式，就由 AI 在同一個地方即時檢查。
三、AWS Security Agent 費用怎麼算？滲透測試以 task-hour 計價
設計審查、程式碼審查與威脅建模在預覽期間不另外收費，其中設計審查與 PR 程式碼審查有預設配額，每個帳號在每個區域每月分別可使用 200 次與 1,000 次，實際費率與配額請以 AWS 官方最新公告為準。task-hour 不等於實際測試時間
要特別注意，task-hour 指的不是測試實際花了多久，由於 AWS Security Agent 會同時執行多個測試任務，task-hour 是把所有任務的工作時間加總計算，因此帳單上的時數通常會比實際測試時間長。
| 官方試算情境 | 實際耗時 | 累計 task-hour | 費用（美元） |
| 小型測試 | 約 1 小時 | 約 3.46 | 173.13 |
| 完整測試 | 約 4 小時 | 24 | 1,200.00 |
| 深度評估 | 約 9.5 小時 | 約 31.26 | 1,562.92 |
四、導入 AWS Security Agent 前要注意的 4 件事
AWS Security Agent 確實能大幅提升資安效率，但不代表開啟之後就能放著不管：1. 部分功能還在預覽階段
目前只有隨選滲透測試正式上線，設計審查、威脅建模與程式碼審查仍是預覽版，如果要納入正式的合規流程，建議先拿非核心專案試用，確認結果穩定後再擴大範圍。2. 滲透測試是「真的攻擊」，範圍要先講清楚
滲透測試會對目標系統發送真實的攻擊流量，請務必只測試自家且已取得授權的環境，並事先通知維運、WAF 與監控團隊，以免觸發告警或影響正式服務，也建議優先在測試環境或預備環境（staging）進行。3. 確認服務區域與資料存放位置
新功能只在已提供 AWS Security Agent 的 AWS 商用區域開放，各區域的開放狀態可能不同，台灣企業導入前，建議先確認可用區域，並評估原始碼、設計文件等資料的存放位置是否符合公司內部規範。4. 權限與成本，事先設好防護
AWS Security Agent 需要存取程式碼儲存庫與應用程式環境，建議依照最小權限原則設定 IAM 與儲存庫授權，如果是多帳號環境，跨帳號角色也要事先規劃好。成本方面，平行任務會讓 task-hour 快速累積，建議先縮小測試範圍，再搭配 AWS Cost Explorer 追蹤花費。
建議做法： 不要一開始就全面導入，先挑一個具代表性的應用程式試行，比較 AI agent 和現有流程在「找到的問題數量」、「誤報率」與「修補速度」上的差異，確認效益後再逐步擴大。
五、AI agent 與資安人員如何分工？AI 負責量，人負責判斷
AI agent 的強項是「量」與「速度」，每一次 PR、每一次改版都能檢查，這是人力做不到的；但資安工作不只是找漏洞，還包括判斷風險能不能接受、規範該怎麼訂，這些仍需要人來決定。| 工作項目 | 交給 AI agent | 留給人 |
| 資安需求與規範 | 依規範自動檢查每個專案 | 訂定組織資安需求、選擇合規框架 |
| 日常程式碼審查 | 每個 PR 自動審查並提出修補 | 審核修補內容、處理重大議題 |
| 滲透測試 | 改版後隨選重測、驗證可利用性 | 決定測試範圍與授權、複雜商業邏輯測試 |
| 風險決策 | 提供影響分析與優先順序 | 評估商業衝擊、決定修補或接受風險 |
| 合規稽核 | 產出可追溯的發現紀錄 | 對外簽核、回應主管機關與稽核單位 |
簡單來說，AI agent 讓資安檢查隨時都在進行，人則把時間留給需要判斷的事。對有法規遵循要求的產業，建議以 AI agent 做日常的持續檢測，再搭配定期的專業人工滲透測試，讓兩者互相補位，而不是誰取代誰。
