Google將Gemini Spark與Chrome整合後，可在使用者授權下代為處理跨網站任務，但也引入提示注入、帳密暴露與敏感操作外移等風險；本文從技術、影響與防護三面向深度解析。
Google 擴大 Gemini Spark 的開放範圍，並讓這項可代為執行任務的 AI 功能與 Chrome 整合；在使用者同意後，Spark 可利用 Chrome 中已登入的帳號與儲存的密碼，處理較繁瑣的網路工作。[2][6][8]
根據原始情資，這類操作包含替已收藏的租屋物件安排看房，或搜尋、比較不同航班並開始訂票；Chrome 整合後，Spark 可直接沿用瀏覽器登入狀態，繼續在網站內完成跨站流程。[2][6][8]
Google 同時指出，Spark 使用這些帳號與密碼前必須先取得使用者允許；遇到涉及付款等敏感操作時，Spark 會把任務交還使用者，不會自行完成付款。[2][6][8]
此次更新也分成兩種不同開放範圍：Spark 本身自 7 月 30 日起，陸續開放給另外 160 多個國家的 Google AI Pro 訂閱者；但透過 Chrome 操作網站的功能，初期僅在美國推出，之後才會擴大到其他地區。[2]
從機制來看，Gemini Spark 已不只是對話式助理，而是具備「任務編排」與「瀏覽器代操」能力的 AI agent；它可以接收目標、拆解步驟，並在多個網站之間接續執行操作。[2][4][6][8]
這類能力的關鍵在於瀏覽器上下文的可用性。當 Spark 與 Chrome 整合後，系統可利用目前登入狀態與已儲存密碼登入會員網站，讓 AI 不必重新取得帳密即可延續工作流，這也是它能跨網站完成任務的原因。[2][6][8]
然而，這種設計同時放大了 prompt injection 風險。原始情資已明確提到，部分網站可能包含刻意誤導 AI 的文字或指令，使其偏離使用者原本交付的工作；這表示網頁內容本身可能成為攻擊面，而不只是傳統的惡意程式碼或釣魚頁面。[2]
技術上，這代表 AI agent 必須判斷「網頁提供的資訊」與「使用者意圖」之間的優先序。一旦模型把頁面中的隱藏指令、誘導語句或不相干內容誤認為任務的一部分，就可能產生錯誤瀏覽、錯誤提交、資料外洩，甚至把行為導向非預期網站。[2][6][8]
Google 已表示加入相關防護措施，以降低 Spark 遭惡意網頁內容操控的風險；但從目前資訊可知，這些防護仍屬降低風險而非消除風險，因此使用者仍需保留最終監督權。[2]
另一個重要設計是「敏感步驟回傳使用者」。原始情資指出，付款不會由 Spark 自行完成；Chrome 的官方說明也提到，涉及機密性高的步驟需要使用者確認，且需要使用者親自執行的步驟會被接回手動處理。[2][6][8]
這種做法反映出 Google 對 agentic browsing 的邊界設計：AI 可處理查詢、比對、填表與流程前段，但當風險升高到資金移轉、身分驗證或不可逆操作時，系統會提高人工介入門檻。[2][6][8]
短期影響最明顯的是 Google AI Pro 訂閱者，以及已經在 Chrome 中習慣保留登入狀態與密碼的使用者；對這群人而言，Spark 可明顯降低跨網站操作成本，特別是在租屋、旅行、比價、會員網站資料查找等情境。[2]
對企業與資安團隊而言，風險面不在於單一瀏覽器外掛，而在於「已授權帳號」被 AI 代理重用。當瀏覽器成為登入與憑證容器時，AI 的行為邏輯會直接影響資料存取路徑與操作責任歸屬。[2][6][8]
對網站營運者來說，這也代表既有反機器人、登入保護、流程驗證與前端防注入機制，未必足以應付會理解頁面語意的 AI agent。網站若存在可被誤解或可被提示操控的文字區塊，便可能成為新的攻擊載體。[2]
就區域影響而言，Chrome 代操功能先在美國上線，Spark 本身則擴大到 160 多個國家；這種分階段推出意味著 Google 可能在觀察真實世界使用情況、風險事件與監管反應後，再決定下一波擴張速度。[2]
從產業趨勢看，這類功能正在把瀏覽器從「工具」變成「執行層」。一旦使用者把搜尋、比價、排程、登入與資料搬運交給 agent，資安防線就必須從終端與網站登入，延伸到 AI 決策與網頁內容可信度。[2][6][8]
第一，對高風險帳號啟用更嚴格的登入控制，並審視是否真的需要讓 AI 共用瀏覽器中已登入的工作帳號與儲存密碼；若任務只需要查詢，不應把可執行權限一併交給 agent。[2][6][8]
第二，將 AI 可處理的任務限制在低風險範圍，例如查詢、整理、比較與草擬流程；凡是付款、送出表單、變更密碼、修改個資或授權第三方服務，都應維持人工確認。[2][6][8]
第三，使用者在啟動 Spark 前，應先檢查其計畫內容是否正確理解提示詞、網頁脈絡與個人資訊；Chrome 官方說明也明示，啟動前要先確認工作計畫，再決定是否開始。[6][8]
第四，網站與企業內部系統應強化對 prompt injection 的防禦，尤其是可能被 AI 讀取的頁面內容、客服對話、公告欄、評論區與文件區塊；凡是會被模型當成上下文的文字，都應視為潛在攻擊面。[2]
第五，管理者應建立 AI agent 使用規範，包含可授權網站清單、敏感操作的人工覆核流程、例外事件通報機制，以及登入狀態與密碼保存政策，避免把瀏覽器便利性直接等同於安全可用性。[2][6][8]
5步驟修補清單