PentAGI 是什麼？開源 AI 滲透測試工具的功能、成本與企業導入評估

PentAGI 是 VXControl 開發的開源 AI 滲透測試系統，讓多個 AI 代理共同規劃任務、呼叫資安工具、整理發現。對企業而言，它值得研究的地方是把「模型判斷」接到「工具執行」；採用前則要準備授權範圍、隔離環境與人工驗證，才能把產出的線索轉成可交付的改善工作。

我們看這類工具，最在意的是最後能不能形成可追蹤的修補流程。一份看起來完整的報告，如果沒有重現證據、負責人和複測紀錄，開發團隊仍然不知道該先改哪裡。這也是本文的評估角度：先看懂 PentAGI 怎麼運作，再決定它適合放進系統交付的哪一段。

本文是官方文件與公開研究的整理，沒有宣稱恆遠已用 PentAGI 完成客戶滲透測試。產品功能以 PentAGI 官方專案 與 2026 年 10 月 5 日發布的 v2.2.0 更新說明 為查核基準，查核日為 2026 年 10 月 13 日。

PentAGI 的定位：把 AI 代理接上資安工具

先把幾個名詞說清楚。滲透測試是在取得授權後，模擬攻擊者的觀察與驗證方式，確認系統弱點能造成什麼影響。AI 代理則像能使用工作工具的數位助理：除了回答問題，還能依任務做決策、讀取工具結果，再安排下一步。

PentAGI 把這兩件事接起來。它的名稱展開為 Penetration testing Artificial General Intelligence，名稱中的 AGI 是專案命名，不能因此推論它已達到通用人工智慧，也不能把產品名稱當成能力認證。評估時應看實際任務、證據品質和使用條件。

一般聊天模型可以解釋一份掃描報告，卻通常沒有獨立的執行環境。PentAGI 提供代理協作和執行工具的系統，讓任務能持續推進。這也使風險邊界改變：當模型可以採取行動，錯誤判斷的後果會從回答不準，擴展到環境和資料受影響。

如果你剛開始規劃系統驗收，可以先看 弱點掃描、滲透測試與壓力測試的差別。三者回答的問題不同，採購文件若只寫「要做資安測試」，廠商與業主很容易對交付內容有不同理解。

多代理怎麼分工，企業該看哪些功能

理解多代理，可以想像一個小型研究小組：有人拆解任務，有人找資料，有人處理工具與技術工作，再有人整理輸出。本文把角色功能歸納為規劃、研究、執行、整理四類，方便理解；這是功能分類，實際代理名稱與數量應以所用版本設定為準。

規劃負責將目標拆成較小的問題；研究提供背景與參考資訊；執行取得環境回應；整理則把工作歷程轉成閱讀者能使用的結果。多代理的價值在於把長任務分解，但代理彼此同意一個結論，也可能只是共同沿用同一份錯誤資訊。

因此，企業看到「多代理交叉檢查」時，還要追問它們使用哪些獨立證據。模型重述另一個模型的判斷，與另外取得一份可重現的環境回應，證明力差很多。這個區別會影響你是否願意讓報告進入正式驗收文件。

工具層負責將模型的計畫轉成可執行工作。官方專案列出 20 多種內建資安工具，涵蓋不同測試用途；工具多寡只能說明可用手段的範圍。企業仍要逐項看啟用範圍、可能產生的負載、記錄內容，以及錯誤時如何中止。

v2.2.0 公布支援共 13 類模型供應商，也提供部分相容端點的設定方式。這表示模型選擇有彈性，但 API 相容與任務品質是兩個評估項目。切換模型後，應重新確認輸出格式、工具使用可靠性與成本，避免把可連線誤當成可交付。

可觀測性可以理解成工作紀錄儀：讓團隊回查任務在哪裡停住、哪些工具失敗，以及哪些內容送到外部服務。企業選型時應把「能不能看見過程」列為基本要求，因為最後的摘要常會省略中途失敗，而那些失敗可能直接影響結論。

知識記憶和歷程保存也有兩面性。它們有助於承接長任務，卻同時增加敏感資訊保留的位置。內部網址、測試帳號、錯誤訊息與程式片段，都應納入資料清單；保留多久、誰能讀取、任務結束如何清理，要由團隊自行確認。

如果你想理解這類工具和技能包的差異，可以搭配 reverse-skill 的定位與基本功 閱讀。技能內容提供知識與做法，執行系統還要處理環境、狀態與權限，兩者在導入工作量上有明顯差別。

與弱點掃描、程式碼審查和人工測試怎麼搭配

選工具之前，先列出這次要回答的問題。例如「套件是否有已知弱點」、「不同角色是否讀得到別人的資料」、「報價審批是否能繞過」、「流量增加會不會當機」，各自需要不同方法。把所有問題交給單一工具，最後常得到一份很長、但覆蓋範圍不清楚的報告。

例如，一套採購系統在形式上要求主管核准，程式也確實檢查了登入狀態，但可能少了「此人是否為這張單的核准者」的判斷。這類問題需要角色規則、測試資料和業務背景。工具能協助找線索，業務單位仍要說明什麼才算違反流程。

再看第三方串接。測試環境中的付款、寄信或簡訊，如果仍連到正式服務，測試行為就可能產生真實交易或通知。系統擁有者應先確認替代端點與測試資料，將環境副作用處理好，再安排任何會主動互動的工具。

我們的判斷是，把 PentAGI 放在已有品質流程裡比較有意義。先有可回滾部署、明確的角色模型和基本測試，再用它評估補充線索；這樣每項發現才有地方落地，也能確認修補後有沒有引入新的功能問題。

若你的現況是「廠商交了程式，但不知道怎麼驗收」，先把 上線前程式碼審計的檢查項目 和交付文件整理出來。工具選型應跟著驗收需求走，才能避免買了工具卻沒有人處理結果。

Web 系統的測試範圍可以參考 OWASP Web Security Testing Guide。它提供測試知識框架，適合拿來討論覆蓋範圍；實際專案仍要補上自家權限、商業規則與第三方整合情境。

2026 年版本評估：測試工具本身也要檢查

在工具介紹裡談版本，看似瑣碎，卻會改變採用決策。PentAGI v2.2.0 的更新重點包含模型供應商設定、沙箱隔離、搜尋整合和多實例部署。本文只將更新說明作為功能來源，沒有替官方執行獨立安全驗證。

其中最值得企業留意的是 CVE-2026-14784。官方說明指出，2.1.0 及以前版本在特定 Docker 設定下，沙箱會取得主機 Docker socket，提示注入可能將代理引導到影響主機的行為。2.2.0 調整了這部分的隔離設計。

提示注入可以理解成「把指令混進代理原本要讀的資料」。例如外部頁面或檔案中的文字，可能讓模型偏離原任務。對會使用工具的代理而言，防線要同時放在模型判斷之外的環境與權限，不能只依賴提示詞要求代理遵守規則。

這個事件的管理意義很直接：你用來檢查其他系統的工具，也是一套要維護的軟體。版本盤點、更新紀錄、測試環境與權限審查，應列入它自己的維運工作。修補某個已知問題，也不代表其他設定和依賴已經全部安全。

Docker 的容器像分隔工作的空間，隔離效果仍取決於主機與授權設定。Docker 官方安全文件 說明 daemon 權限與容器安全的考量。企業可以要求維運者說清楚：代理能碰哪些資源，出了問題會影響哪一層。

對有 AI 工作流程的企業，這也延伸到模型端與連接器端。把外部內容、工具權限和敏感資料放在同一條鏈上時，需要一起評估。OWASP GenAI Security Project 提供生成式 AI 與代理安全風險的參考框架。

相關的資料與權限盤點，可先參考 企業 AI 導入前資料權限盤點。盤點結果應能回答「這份資料為什麼要送出去」，而且讓非工程主管也看得懂。

API 金鑰也要有負責人與更換程序。工具試行結束後，確認臨時憑證是否撤回，以及日誌和備份有沒有留下敏感內容。可搭配 API 金鑰外洩後的處理清單，整理團隊的聯絡與恢復責任。

開源免費之外，PentAGI 的成本怎麼估

開源工具的授權費、模型服務費和維運成本，必須分開看。PentAGI 的核心程式採 MIT 授權，可在遵循條款的前提下使用與修改；第三方元件、企業版及 VXControl SDK 則要另外查看其適用條款。商業整合前應核對 LICENSE 與 EULA。

MIT 授權允許使用核心程式，不代表全部外部服務都免費，也不代表有正式客服與服務水準承諾。如果你將工具改造成對外服務，更要把元件授權、資料處理和支援責任寫進評估紀錄，避免只讀首頁的「開源」兩個字就做採購決定。

不要先問「跑一次多少錢」，先定義一次的範圍。測幾個角色、哪些功能、允許多久、保留哪些紀錄，會讓成本差很多。同一個任務換模型或開啟其他外部服務，也可能改變支出與資料流向。

試行時可以使用一份簡單成本表：記錄任務開始與結束時間、模型實際用量、基礎設施支出、人工確認工時及修補工時。把失敗與中止的任務也記進去，才能看見可交付結果的完整成本，避免只算成功展示的那一次。

以下是計算方式，並非 PentAGI 官方報價：單次完整成本等於模型與外部服務費，加上環境分攤、維運、審核及複測成本。再把它除以「人工確認後可採取行動的發現數」，會比單看報告頁數更能比較工具的實用性。

對已有 AI 開發流程的團隊，也要把工具權限與恢復能力算進導入工作量。AI 寫程式的權限隔離與救援規劃 可以幫助你整理這部分的基本條件。

怎麼判讀 AI 報告，避免把線索當成結論

AI 代理會把觀察整理成自然語言，這讓報告更易讀，也容易讓讀者高估證據的完整性。企業應要求每項發現分別列出實際觀察、推論、尚未驗證的條件和影響範圍。當這幾種內容混在一起，主管很難判斷是否要立即安排修補。

2026 年的研究 From Controlled to the Wild 提出以已驗證弱點發現評估代理的方式，並強調較真實情境、重複評估與效率指標的重要性。這提供一個有用方向：把驗證和成本納入評估，避免只用任務是否完成作為唯一指標。

閱讀任何 PentAGI 排名與成本數字時，都應核對研究中的版本與測試條件。研究中的版本、模型、目標和預算，都可能影響結果；舊版本的比較也不能直接當成 v2.2.0 的成績。要做工具排名，應先確認相同條件與可重現資料。

另一個公開案例是 XBOW 在 2025 年 6 月的 HackerOne 美國榜第一紀錄。該公司說明，送出的近 1,060 份發現都有安全團隊事前審閱。這是 XBOW 的歷史案例，不能借用成 PentAGI 的表現證明；它提醒我們，工具的自主發現與正式對外交付仍有不同責任。

誤報會吃掉工程時間，漏報則容易產生過度安心。兩者都需要透過人工驗證與測試範圍管理處理。工具說「沒有發現」，應連同「測了哪些、哪些沒測、哪裡失敗」一起閱讀，才能知道這句話到底涵蓋多大範圍。

重現也有層次。只在特殊測試帳號和不符合實際使用的設定下出現的問題，仍可能有價值，但修補優先順序要結合正式環境條件。保留假設與限制，會讓報告更有用，也讓開發者少花時間來回詢問。

關於資料外洩的業務影響，可以搭配 電商訂單資料與自動化攻擊的自查觀念 閱讀。評估時要把資料種類、存取角色與應用流程列在同一張圖裡，才容易討論修補優先順序。

導入前七項檢查：先做有限範圍的試行

第一項是授權與範圍。由系統擁有者確認可測的環境、功能和帳號，也要確認第三方服務是否另有條件。委外測試時，將允許與排除的範圍交付承接者；實際法律與契約義務需由企業依自己的情況確認。

第二項是環境隔離。準備獨立測試環境、去識別資料和專用帳號，先確認備份與恢復程序能用。測試環境要足以反映你想驗證的設計，同時避免讓測試行為直接碰到正式營運資料。

第三項是資料去向。盤點模型、搜尋、日誌、監控與記憶服務，看它們會收到哪些資訊。自架 PentAGI 與所有資料留在本機是兩個不同條件；選了外部 API，就應另外確認資料處理與保留政策。

第四項是版本和供應鏈。記錄 PentAGI、執行環境及主要元件版本，訂出更新與回復方式。工具開始試行前，先查已知問題和更新說明；之後每次重大更新也應重新確認測試結果，避免沿用舊驗收紀錄。

第五項是預算與停止條件。設定試行的費用上限、時間範圍和人工聯絡窗口，並確認停止任務後還有哪些背景工作需要處理。這裡的上限是企業應建立的控制措施，具體是否能直接在工具內設定，要以所用版本確認。

第六項是驗證責任。事前指定誰判讀報告、誰確認業務影響、誰修改程式。每個角色要能接手下一步。對沒有資安判讀能力的中小企業，先安排合格人員協助規劃範圍，比直接增加工具更有成效。

第七項是修補閉環。把人工確認的發現建立為工作項目，記錄嚴重度、負責人、預定完成日和複測結果。交付者應能說明問題怎麼處理，採購者則要保留最終結案依據，讓這次測試能改善下一次交付。

一個務實的起點，是挑選已完成部署、可恢復的內部測試系統，用相同範圍比較現有流程與新工具。先確認它是否帶來可用發現，再談擴大範圍。過程中保留版本、模型設定和人工處理時間，結果才有比較價值。

對需要多角色和稽核紀錄的系統，可以參考 系統交付中的角色權限與驗收文件。把規則寫成可驗收條件，能讓工具發現與專案交付更容易接起來。

企業的下一步：把工具接進系統交付流程

如果團隊已有資安人員、獨立環境和修補流程，PentAGI 可以列入試行清單，觀察它能否補充有價值的線索。如果目前連權限規則、部署版本和備份都說不清楚，先整理這些基礎條件，會更容易判斷工具是否適合。

對中小企業老闆，最值得問承接團隊的問題是：「這次測試完成後，我會拿到哪些可確認的改善結果？」答案應包括已確認問題、已處理項目、尚未完成的風險，以及複測紀錄。這份清單比「用了哪個熱門工具」更能支撐驗收決策。

恆遠的 Vibe Coding 健檢 可作為討論 AI 開發成果與上線檢查的入口。你可以帶著系統用途、目前部署方式、角色清單及最擔心的資料風險來談，先釐清需要檢查的範圍與交付內容；本文沒有承諾提供特定 PentAGI 測試或認證。

我們公司自己每天在跑 20+ 個 AI 流程，也已有 40+ 企業客製案落地。這些是整體工程與內部使用經驗，不能挪作 PentAGI 實測成績。我們將 AI 放進規劃、程式品質、測試與安全檢查，同時保留每個階段的驗收責任。

可複製的試行評估清單

把以下欄位複製到專案文件即可使用：系統名稱、系統擁有者、授權範圍、排除項目、測試環境、角色與帳號、資料去向、工具及模型版本、預算上限、停止窗口、人工驗證者、修補負責人、複測日期與結案依據。

每欄除了填內容，也應附上確認者與確認日期。遇到空欄位，先補條件再安排工作。這是一份本文提供的流程範本，沒有預設所有控制都能在 PentAGI 介面完成；環境與組織的措施同樣要列進計畫。

我們怎麼看

我們認為 AI 測試代理會逐步成為系統品質流程的常用元件，原因是它能連接觀察、推理與工具工作。企業的採用門檻則會落在證據品質和責任分工。我們會優先把測試接到修補與驗收，讓每項發現有人接手。對採購者而言，先要求一份範圍清楚、能複測的試行結果，再決定是否擴大投入。

PentAGI 常見問題