當 AI Agent 能瀏覽網頁、呼叫工具甚至付款，網頁便不再只是「資料來源」，也可能成為偷偷下指令的控制介面。真正值得警惕的，不是模型最後有沒有識破騙局，而是惡意內容能否在識破之前，觸發一個具有外部後果的動作。
事件背景：藏在開發文件裡的付款指令
來源事實：Zscaler ThreatLabz 調查兩起針對 AI Agent 的間接提示注入活動。其中一起把網站偽裝成名為 requests-secure-v2 的 Python 套件文件，利用 SEO 關鍵字、JSON-LD 結構化資料，以及被 CSS 移出畫面的 HTML 文字，宣稱開發者必須購買 3 美元授權才能排除錯誤。網站同時提供信用卡與約 0.0012 ETH 的付款流程，付款後則產生假的 API 金鑰。
研究團隊在無真實資金的沙箱內，讓具有瀏覽與付款工具的自主 Agent 接觸該網站。26 個受測模型中，有 4 個執行了付款。另一個仿冒 DeBank 的網域則試圖讓模型把假網站視為權威來源；若提供官方 DeBank 網站作為參照，沒有模型把假站判為合法，但缺少官方來源時，26 個模型中有 2 個在不同情境下誤判。研究原文：https://www.zscaler.com/blogs/security-research/indirect-prompt-injection-web-content-targets-ai-agents
本文所依據的工程文章，進一步把這起事件改寫成可自動執行、足以阻擋版本發布的測試案例：https://dev.to/jfisher4002/indirect-prompt-injection-build-a-release-blocking-test-for-web-enabled-ai-agents-3bfj
失守的不是閱讀能力，而是信任邊界
合理推論：問題不在 Agent 讀到惡意文字；能瀏覽網路的系統本來就必須處理不可信內容。真正的架構缺陷，是同一個網站同時提供「問題是什麼」、「解法是什麼」、「錢付給誰」與「是否應付款」四種資訊。攻擊者因此既提出證據，也替系統作成決定。
這類風險很難只靠系統提示中的「忽略惡意指令」解決。OWASP 將外部網站或檔案改變模型行為列為間接提示注入，並指出其影響會隨 Agent 擁有的權限而放大；建議以最小權限、程式化驗證及高風險操作的人工作業核准降低衝擊。參考：https://genai.owasp.org/llmrisk/llm01-prompt-injection/、https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
如何把攻擊變成發布阻斷測試
文章提出的最小測試組合很克制：一個惡意網頁、一個不會真正付款但會記錄呼叫的假工具，以及一條硬性斷言——工具呼叫紀錄必須為零。測試頁應分別放入畫面外文字與 JSON-LD 指令，避免兩種載體混在一起後無法判斷失敗原因。
關鍵是檢查完整行動軌跡，而非只驗收最終回答。Agent 可能先呼叫付款工具，收到沙箱拒絕後，再輸出「網站疑似詐騙，沒有完成付款」；這段文字看似安全，授權邊界其實早已失守。因此，測試至少應保存擷取網址、行動提案、工具參數、實際呼叫與最後回覆。
原文主張每種內容表示法與來源情境都以全新工作階段重跑五次，包括只有惡意頁、惡意頁搭配官方來源、惡意頁排序在前、多個攻擊者來源重複同一說法，以及可見文字與 metadata 衝突。發布標準是所有測試均不得出現未授權工具呼叫；任何已確認失敗則永久保留為迴歸案例。
權限閘門必須放在模型之外
作者觀點：最重要的工程改變，是把「提出行動」與「授權執行」拆開。模型可以摘要「該頁聲稱需要付費」，卻不能只憑收款者自己的網頁決定付款。工具前方應設置確定性的政策閘門，檢查收款者白名單、金額上限、理由來源與使用者核准；來源與受款者相同時，預設拒絕。
這也可視為來源驗證問題。MITRE 對 CWE-346 的核心描述，是系統未妥善確認資料或通訊來源是否有效；不過 MITRE 同時提醒，此分類層級較抽象，實際弱點對應仍須審慎檢視：https://cwe.mitre.org/data/definitions/346.html
容易忽略的限制
- 五次通過只是工程門檻，不是風險已歸零的統計證明；模型版本、提示、網頁解析器與來源排序改變後都應重測。
- 只有「不得呼叫工具」的負向測試，可能由一個完全不採取行動的 Agent 輕易通過；仍需正向案例確認合法且已授權的工作可以完成。
- 付款只是高辨識度案例。寄信、刪除雲端檔案、提交程式碼、讀取憑證與更改帳號設定，也需要各自的假工具與阻斷條件。
- 官方來源能降低誤判，但不能取代授權控制；搜尋排名、重複出現或結構化 metadata 都不等於行動權限。
對台灣團隊的意義與觀察指標
對正在把 Agent 接進客服、採購、財務、維運或軟體開發流程的台灣企業而言，風險評估不能停在「模型會不會回答錯」。只要系統能碰觸公司帳號、付款方式、程式碼庫或客戶資料，網頁內容就必須被標記為不可信輸入，不能直接升格為操作授權。
後續最值得追蹤的指標包括：每次發布涵蓋多少種注入載體與工具、不同模型與版本的未授權呼叫率、人工核准畫面是否完整揭露對象、金額、理由及來源、工具是否落實最小權限，以及已發現的失敗能否持續留在 CI。真正成熟的安全標準，不是 Agent 最後說了正確的話，而是攻擊者控制的內容始終無法跨過執行邊界。