AWS Security Agent API 導入前：測試目標、IAM 與授權範圍如何驗收？

專題編輯：Iris Hsieh · 資料截止 2026.11.08

一、資安工作正在前移，但「Agent」不是免責的自動化魔法

軟體團隊傳統上常在功能完成後才安排安全檢查。程式碼先合併、系統先部署，等滲透測試報告出來再把問題交回工程師，結果可能需要重新理解需求、修改設計、延後發布。當 AI 協助產生程式碼的速度提高，這個流程更容易形成新的瓶頸：開發變快了，安全驗收卻沒有跟上。

AWS Security Agent 試圖把多種類型的安全檢查串進軟體開發生命週期。官方 API Reference 目前描述可依組織要求進行安全審查，包含設計審查、連接程式庫的 PR 程式碼審查，以及按需授權滲透測試。使用者可以從 API 或 CLI 角度理解與服務互動的方式，也可以依官方 User Guide 檢查實際操作與限制。

但是，必須先澄清時間線。AWS 的按需滲透測試於 2026 年 3 月 31 日宣布正式可用；5 月 12 日公告整個程式庫的程式碼審查能力；7 月 1 日公告增加孟買、新加坡與聖保羅區域。當次官方文件亦將 Security Agent 標示為 AWS Continuum 的一部分。這些日期對應不同能力與公告，不能合併成所有功能在所有區域同時可用。因此本篇討論的是既有產品能力與 API 文件的整合意義，不能把 2026 年 11 月的文件頁面當成上述所有功能的首次發布日。

這個區分尤其重要，因為企業採購與資安合規需要確定某項能力目前是 GA、Preview 還是受區域和帳號資格限制。把預覽功能當成全面正式可用，可能導致專案排程或責任分工與實際服務不符。

二、三類工作要拆開：設計檢查、程式碼審查與動態授權測試

設計安全審查主要處理系統尚未部署前的風險，例如身份驗證、授權邊界、資料流、敏感資訊處理與信任邊界。這個階段需要架構文件、需求說明與威脅模型等上下文。若只給一個程式碼倉庫，可能無法完整表達系統為何需要某個權限或哪些外部服務會接觸資料。

程式碼審查關注實際變更或整體程式庫，可能在 PR 或其他檢查節點進行。這個階段可以結合程式、設定與專案資料，尋找安全問題並提出改善建議。但 AI 的審查結果必須被工程師理解與驗證；未審查的分支、相依套件、配置與執行環境仍然可能存在風險。不能只因某個 PR 通過了審查，就宣告應用沒有漏洞。

按需滲透測試則是另一種能力，目標是對獲得授權的應用進行測試，嘗試驗證特定漏洞是否真的可被利用。AWS 官方文件指出這類測試會結合上下文規劃多步驟情境，並提供風險評級、重現步驟及修正建議。這類能力可能比單純靜態分析更接近攻擊鏈，但也因此需要更嚴格的測試範圍及授權管理。

三者回答不同問題。設計審查問「架構是否把風險考慮進去」，程式碼審查問「實際實作是否違反安全要求」，授權滲透測試問「在指定範圍內，系統是否存在可重現的攻擊路徑」。要形成安全閉環，必須再加上人工確認、修正、重新測試與發布決策。

三、API 文件真正提供的是作業介面，不是企業授權的替代品

AWS Security Agent 的 API Reference 列出操作、請求結構、回應格式與錯誤處理方式，例如可查到建立第三方程式碼整合的 CreateIntegration 操作。IAM Service Authorization Reference 另有對應的 securityagent 動作、資源類型與條件鍵資訊，可作為設計最小權限政策的依據。這些文件使工程團隊有條件將安全工作納入可追溯的系統流程，而不必完全依賴操作介面上的人工點擊。

但看到 API 名稱不代表已經核實任何帳號可以使用。實際執行仍取決於 AWS 帳號、區域、服務啟用、IAM 權限、第三方整合授權、可用功能狀態與目標系統條件。文件也可能在未來更新，因此正式建立企業流程時，應以當次 API 版本及適用區域的最新文件為準，不應把本文的描述當成可直接執行的永久指令。

企業應把所有安全自動化都放進變更管理。建立整合之前先確認資料來源及控制權；啟動掃描之前核對測試對象、環境與授權；取得結果之後明確記錄是模型建議、可驗證發現，或仍待人工排查。當結果要影響部署、封鎖發布或通知客戶時，應有清楚的核准角色與異常處置路徑。

此外，安全工具本身也涉及敏感權限。若 Agent 可以讀取程式碼、架構文件與錯誤紀錄，企業就應先確認是否含有憑證、個資或其他受保護資訊，並對來源、保留與可存取身分設計最小範圍。資安自動化不應成為將整個內部系統不加區分提供給單一工具的藉口。

四、授權滲透測試的第一道關卡，不是掃描按鈕，而是目標擁有權驗證

AWS 官方教學指出，啟動按需滲透測試前需要完成目標網域的所有權驗證，例如 DNS TXT、HTTP 路徑或符合條件的 Private VPC 驗證，藉此驗證目標符合服務的技術驗證條件；這仍不能代替系統所有者的書面測試授權。這不是多餘的繁瑣程序，而是避免工具被拿去測試第三方未授權系統的安全界線。即使技術上有能力對某個地址發送測試請求，也不能據此推論在法律或合約上具有權利。

測試範圍應以書面確認，包含可測試的網域與環境、時間窗、允許的測試類型、禁止的動作、資料保護要求、故障通報及緊急中止方法。對正式環境應更加謹慎，事前考慮交易、資料完整性、服務可用性與客戶影響。若使用第三方服務或雲端平台，還要遵守其滲透測試政策與合約條款。

AWS 的資安考量文件指出，服務會監控試圖超出目標 URL 的存取或其他濫用行為；若偵測到未授權測試第三方端點等情況，相關測試可能被中止。官方亦提醒，AWS Security Agent 並不是專業滲透測試服務的替代品，應被整合進由資安人員參與的審查工作。這兩項說明都支持一個管理結論：Agent 有自主執行能力，並不代表它具有自主決定授權範圍的權力。

對企業內部教學或 PoC，應先使用自己擁有或明確授權的隔離測試系統。保留目標所有權證據、測試時間、權限、執行設定、測試發現及處置結果。測試內容應避免涉及不相關的第三方，並防止測試資料與真實客戶資料混用。

五、跨雲、程式庫與外部服務整合，最容易產生的兩種錯誤

第一種錯誤是把多雲支援理解成「所有環境直接即插即用」。AWS 曾公告其按需滲透測試能涵蓋 AWS 以外的雲端及部分內部部署環境；但實際測試仍受可連線性、驗證程序、區域、整合設定、認證機制和安全要求影響。企業可能需要設定私人端點連線、提供 API 規格或登入流程資訊，這些都不會因為文件宣稱跨雲而自動完成。

第二種錯誤是把整個程式庫與相關文件全部交給 Agent，卻沒有內容權限規範。完整的安全上下文可能包含系統架構、原始碼、業務流程與過去事件紀錄，這些資料很有價值，但也可能高度敏感。若沒有資料分類、最小權限、憑證處理、連線審查與退出機制，資訊整合愈完整，治理風險也可能愈集中。

最佳做法是依專案建立明確邊界。每個應用的程式庫、文件、測試目標與環境獨立管理；可提供哪些來源、可執行哪些動作、結果由誰接收都必須有紀錄。若需要串接 GitHub Enterprise、GitLab 或其他來源，先驗證對應功能、權限與資料政策，再決定是否納入流程。

這也涉及資料品質。若設計文件已經過期、API 規格與實際部署不同，Agent 可能在錯誤的上下文上做出看似合理的檢查。工程團隊應讓程式版本、部署環境、設計文件與測試目標具有可追溯的版本關係，並在文件不一致時停止高風險自動化，而非強迫工具繼續執行。

六、如何從 PR 審查走到修正與重新測試？

合理的 DevSecOps 流程應從需求與威脅模型開始，進入程式開發與 PR 審查，再將高風險發現交由負責人處理；修改程式碼後，由 CI 與必要的安全測試確認修正是否有效，最後由授權者決定是否部署。若應用進入可用測試環境，可對合法目標進行按需滲透測試，將可重現的問題重新交回程式碼修改流程。

在這個循環中，Agent 並不是每一站的唯一決策者。初步發現可能需要人工排除誤報，修正建議可能對其他功能造成副作用，動態測試可能受測試帳號權限限制。人工審核、回歸測試與業務驗收仍然必要，尤其當系統處理金流、身份驗證或重要個資時，更應保留必要的變更核准與安全豁免程序。

管理者可以用「漏洞生命週期」追蹤成效，而不只計算 Agent 發現多少問題。每個發現應有識別碼、受影響版本、證據來源、風險等級、責任人、修正策略、修正 Commit、重測結果與關閉批准。這些資訊若無法連起來，安全工具可能只會產生大量報告，並沒有改善實際暴露的風險。

值得注意的是，官方技術示例與個別客戶使用經驗不能直接等同所有企業的普遍效益。即使某篇文章展示模型能找出複雜攻擊鏈，也不能保證每個產品、每次測試都能找到所有漏洞。安全成效要依據自己的測試對象與實際檢驗方法建立，而不是靠通用宣傳數據代替。

七、台灣企業可以採用的四階段試點方案

第一階段選擇有完整授權的非正式環境，盤點 IAM、程式庫、網域所有權與資料分類。第二階段提供經核對的架構文件及 API 規格，執行可以合法完成的安全審查。第三階段針對具代表性的發現建立修正 PR，要求人工確認原因、影響面及測試結果。第四階段在核准範圍內重新測試，將結果併入交付驗收，而不是只留下掃描報告。

各階段都有停止條件。若沒有網域所有權與測試同意，不啟動滲透測試；若測試可能影響真實客戶資料，先調整環境；若外部整合過度授權，先修正 IAM 和存取策略；若 AI 的發現缺少可重現證據，標為待人工確認。這些停止條件比建立一個看起來全自動的 Demo 更重要。

導入評估可以觀察平均缺陷修復時間、重複缺陷比例、重大發現的驗證率與人工處理負擔；但任何改善都應比較相同風險等級、相似類型的專案和一致的觀測期間。若資料不完整，寧可先建立基準，不應宣稱 AI 提高多少安全性。

八、AWS Security Agent 對軟體主管的真正啟示

軟體開發流程越來越倚賴 AI，安全制度也需要進一步整合。未來的競爭不在於誰的工具能產生最多漏洞報告，而在於誰能將設計需求、程式碼變更、測試證據、人工決策和部署結果連成一條可驗收的鏈路。缺少這條鏈，團隊即使有最先進的 Agent，也可能不知道哪些問題真的解決、哪些只是暫時關閉警示。

企業可以從一個受控的小型專案開始，先把權限、流程與證據設計正確，再逐步擴大。適當的自動化會讓安全檢查更容易出現在開發過程，而不是等到最後才成為一道難以跨越的審批關卡；但任何有能力模擬攻擊的工具都必須在合法、授權和可控制的環境下運行。

核心觀點：AI 資安工具的價值不在於它能自己嘗試多少攻擊，而在於企業能清楚說明每項測試獲得何種授權、發現了什麼、誰批准修正，以及如何證明風險已被處理。

可複用的安全測試交接卡

每一個測試任務填寫：應用名稱、系統所有人、環境及區域、測試網域、所有權驗證、授權期間、程式版本、使用的 API 或工具、IAM 角色、資料分類、測試目的、風險限制、執行紀錄、發現列表、人工確認、修正與重測結論。沒有明確授權、環境或證據的任務，應保持暫停，不能被視為已通過安全驗收。

把安全自動化納入責任分工，而不是交給單一工具帳號

一個可落地的安全測試制度，至少涉及四個角色。系統擁有者確認資產、業務重要性和允許影響；資安負責人審核測試範圍、風險與發現；平台管理者處理 IAM、整合與日誌；開發團隊負責修正、回歸測試與交付證據。同一個人可以兼任，但不能因人力有限而把核准、執行、驗收三種責任全部省略。

對於可能影響生產環境的測試，應在啟動前準備聯絡名單和停止程序。測試開始後若監測到異常流量、服務錯誤或資料完整性疑慮，應依預先約定的條件中止，再由相關負責人決定是否恢復。所有測試內容都應限於清楚授權的目標，不將安全研究需求擴張成對第三方未授權系統的探測。

企業還應記錄工具的限制條件：是否使用測試帳號、哪些登入或外部系統無法進入、哪些程式庫版本尚未審查、是否涵蓋行動應用和 API、哪些安全規則仍須人工驗證。資安報告最危險的不是出現一個紅色警告，而是用一句「AI 檢查完成」掩蓋原本沒有檢查到的範圍。清楚揭露限制，才能讓主管做出符合風險承受度的發布決定。

官方來源與版本提醒

1. AWS Security Agent API Reference：https://docs.aws.amazon.com/securityagent/latest/APIReference/Welcome.html
2. AWS IAM Service Authorization Reference：https://docs.aws.amazon.com/service-authorization/latest/reference/list_securityagent.html
3. AWS Security Blog，2026 年 3 月 31 日，On-demand penetration testing GA：https://aws.amazon.com/blogs/security/aws-security-agent-on-demand-penetration-testing-now-generally-available/
4. AWS What's New，2026 年 5 月 12 日，Full repository code review：https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-agent-full-repository-code-review/
5. AWS What's New，2026 年 7 月 1 日，區域擴張：https://aws.amazon.com/about-aws/whats-new/2026/07/aws-security-agent-asia-pacific/
6. AWS Security Agent Security Considerations：https://docs.aws.amazon.com/securityagent/latest/userguide/security-guidance.html

本文以 2026 年 11 月 8 日取得的官方文件為準；不同 API 操作、產品能力、區域和帳號資格可能不同，未在使用者 AWS 帳號實際執行任何資安掃描。本文不提供未授權的入侵指令。封面是 AI 概念插畫，非 AWS 真實操作畫面。

補充官方文件：測試網域驗證、CreateIntegration API。

延伸閱讀

延伸閱讀：與本篇相連的企業實務。

內容提供：TARAISG。專題編輯為天地人 AI 虛擬角色；文章由 AI 產製及協助查核。封面為 AI 概念插畫，非新聞現場或產品操作畫面。本文未宣稱經具名人工或專業法律審核。