AI Agent 安全不能只靠答得好：從 Hassabis 訪談看權限與責任
Hassabis 在 WSJ 訪談談 AI Agent 安全、責任與標準機構。搭配 DeepMind 官方框架，理解能力評測、權限限制、提示注入和人工批准如何影響實際風險。
AI Agent 安全，得從它能動手做多少事開始看。讓 AI 提供建議，和讓它直接寄信、改資料或操作帳號，中間隔著真實的後果。
DeepMind 共同創辦人 Demis Hassabis 在 WSJ 10 月 21 日上架的職涯訪談，談到 AI 事件的責任與未來風險。他主張，趁系統能力進一步放大前，做好護欄與安全測試。
AI Agent 是能朝目標連續採取步驟的系統。它可能查資料、使用工具，再依結果調整做法。因為工作流程越來越長，人也越難逐步盯著。
因此，安全還得檢查權限如何取得、外部資訊能不能改變行動，以及出事時能不能及時停止。回答語氣再客氣，也無法替代這些限制。
我會先看一個 Agent 的權限邊界與留下的紀錄，再看展示影片有多流暢。理解這個取捨，得先知道錯誤如何變成行動。
Agent 的風險，會隨行動權限放大
Agent 造成多大後果，取決於模型能力，也取決於它拿到的工具與權限。因為草稿還能修改，同一個錯誤判斷，在草稿箱與正式系統裡，可能有完全不同的影響。
在 WSJ 原始訪談約 5 分鐘處，主持人提到 AI 代理入侵相關報導。Hassabis 回答，責任必須看具體情境，同時把這些事件視為業界需要認真對待的警訊。
他主張把護欄和安全測試做足，也再次提出設立標準機構、測試與認證前沿系統的想法。這是他提出的治理方向，影片本身並沒有完成對每起事件的責任調查。
約 6 分 15 秒，他把問題拉到如何安全引入通用人工智慧，以及社會希望怎樣生活。他強調，藝術、人文與哲學等領域都應參與，未來不能只由技術人員決定。
這個立場提醒我們，風險有兩個層次。產品團隊要處理眼前的權限與錯誤，社會也要討論哪些應用可接受、哪些後果需要更嚴格的限制。
用一個假設情境來看：同樣把客戶名字看錯，產生一份內部草稿還能修改，直接把帳單寄給錯誤對象，就會牽涉資料外流與後續處理。
因此，導入時可以先讓 Agent 分析與準備，再逐步開放行動。因為行動範圍有限，團隊有時間觀察它在哪些條件下容易誤判，也避免一次交出整個帳號的操作能力。
權限還應對應任務。一個只需查詢訂單的流程，通常沒有理由同時取得修改所有客戶資料的權力。可用工具越少，錯誤能擴散的範圍也越容易掌握。
能力評測，能告訴我們什麼與漏掉什麼
能力評測能提供特定測試條件下的證據，但不能單獨保證每一種部署都安全。所以讀報告時，要同時看測了什麼、怎麼測，以及結果適用的範圍。
DeepMind 的前沿安全框架用能力門檻安排評估與減緩措施。2026 年 4 月 17 日的 3.1 版加入較早追蹤部分風險的能力層級，目的是在更嚴重的門檻前取得訊號。
依官方更新說明，風險評估還包含系統化辨認威脅、分析模型能力，以及判斷風險是否可接受。這比只看一個安全分數更接近實際部署需求。
另一份 7 月公布的研究測試情境認知與隱藏行動的能力。前者是理解自己處在什麼環境，後者是推理如何繞過監督。
研究把這些能力視為成功規避控制的前提，並嘗試建立「能力不足以完成危險行為」的安全論證。這是測試設計，不能據此斷言所有模型都已在真實環境中秘密行動。
對採購者來說，重點是產品部署後多了哪些條件。接上網路、企業資料或高權限工具，會改變模型能接觸的資訊，也可能改變一個失誤能造成的後果。
假設某套 Agent 在測試中只整理公開資料，實際上線卻能讀取內部合約並發送郵件，因為可用權限不同，原本的測試就沒有完整覆蓋新增的工作範圍。
因此，評測要和用途一起看。模型版本改了、工具增加了，或任務從讀取轉成修改，原本的安全結論都可能需要重新檢查。
外部資訊進入工具後，指令邊界要守住
外部內容應是 Agent 要處理的資料，不能自動取得指揮它的地位。如果這條邊界模糊，使用者交辦的工作就可能被第三方內容帶離方向。
提示注入就是利用這個弱點。攻擊者把惡意要求藏在網頁、文件或郵件裡，試圖讓系統把讀到的文字當成新的操作指令。
Google 的分層防禦說明列出惡意內容辨識、模型訓練、可疑連結處理與特定操作確認等做法。官方採取多層措施，也反映單一防線難以涵蓋所有情況。
可以想像一個假設例子：使用者要 Agent 摘要報價，附件卻要求把完整客戶名單傳到某網址。後者來自待閱讀文件，沒有因此獲得使用者的授權。
好的系統需要辨認指令來源，也要在工具端限制資料能流到哪裡。即使模型一時判斷失準，外部傳送限制仍有機會阻止錯誤變成外洩。
這也是為什麼「請小心」不夠具體。若 Agent 本來就能把所有檔案送到任何網址，安全提示就只能仰賴它每次都做對判斷，卻缺少後面的限制。
反過來，工具只提供必要欄位、限制可寫入位置，或把對外傳送獨立成需批准的步驟，就能讓風險在不同環節受到控制。
使用者也需要看得懂被擋下的是什麼。如果系統只顯示模糊錯誤，大家可能為了完成工作而關掉保護。清楚說明受阻的動作，更有助於重新安排流程。
把批准點放在會產生後果的地方
批准機制應讓人能做有資訊的決定。它要出現在動作發生之前，也要呈現即將改變的內容，才能減少誤按與形式上的確認。
例如在一個假設客服流程中，Agent 可以自行整理退款資料，但送出退款前，要顯示訂單、金額、原因與收款對象，讓負責人有足夠資訊核對。
若畫面只問「要繼續嗎」，使用者既不知道 Agent 推到了哪一步，也看不出動作是否超出原來要求。因此，確認按鈕雖然存在，判斷條件卻不完整。
每個小動作都要求批准，也會讓人疲乏。因為後果不同，查詢公開資料、整理私人草稿，和刪除正式紀錄、公開發布內容，可以採取不同的控制強度。
DeepMind 6 月的 AI Control 路線說明也區分了回應方式。低風險、可逆動作可以延後檢視並修復，高風險動作則需要在執行前阻止傷害。
同一份官方說明提出，權限應依驗證過的行為逐步開放，並結合監控、預防與回應。這是系統層面的控制，補足只期待模型永遠理解正確的做法。
停止機制也要考慮工具仍在執行的情況。使用者按下取消後，後續寄送或寫入是否一併停止，需要在設計時就定義，不能只讓聊天視窗不再顯示新文字。
批准與停止的價值，都在於它們能改變實際行動。若後端已完成不可逆操作，才詢問是否同意，使用者就失去了介入的時機。
責任要能回溯，系統才值得逐步放手
可回溯的紀錄能幫團隊找出問題，也讓責任討論有證據可依。除了最後成果，系統還應記下原始要求、使用的資料、工具動作與批准內容。
當一筆資料被改錯，團隊需要知道是模型誤解、來源有誤、工具權限太大，還是人批准了不完整的畫面。因為出錯位置不同，這些原因對應的修正方式也不相同。
例如模型把兩個同名客戶混在一起，可能需要更清楚的識別欄位。如果工具允許跨部門修改資料，則要收緊權限。只換一段提示詞，未必碰到出錯的環節。
監控本身也有成本與盲點。紀錄誰能看、保存多久，以及是否包含敏感資料，都需要設計。如果留下所有內容卻沒人能及時處理，也不會自動降低風險。
前面提到的 DeepMind 路線因此同時關注監控覆蓋、抓到問題的比例與反應時間。對企業而言，也可以把這種思路轉成自己的維運問題，而非只問工具有沒有紀錄功能。
Hassabis 提出的標準機構構想，指向更廣的外部檢驗需求。但具體產品今天能做哪些操作，仍要由開發者與部署者清楚說明，讓使用者有依據決定是否交付。
我會先從可逆、範圍明確的任務使用 Agent，再依實際表現擴大權限。對會影響他人資料、金錢或公開內容的工作，能核對、能停止、能追查，是交辦前就該具備的條件。
延伸閱讀：Cloudflare 推動 Trusted Agent Delegation，網站如何辨識 AI 代理與背後使用者？
延伸閱讀：METR 獨立評估獲 Anthropic 員工級存取：AI 安全評估能看見什麼？
歡迎免費訂閱 AI 郵報，持續追蹤有原始來源、說明適用條件的 AI 進展。
FAQ：AI Agent 安全常見問題
AI Agent 安全，和一般聊天機器人差在哪裡？
Agent 可能連續使用工具並改變外部系統，因此要看行動權限與實際後果。聊天回答的品質只是其中一部分。
有人工批准，就能避免所有錯誤嗎？
不能。人可能看漏，也可能因資訊不足而批准錯誤動作。批准畫面需要清楚呈現對象、內容與後果，並配合工具權限限制。
Hassabis 已經決定 AI 出事由誰負責嗎？
他在訪談中說責任取決於具體情境，並倡議更強的測試與標準。這段回答沒有替所有事件提供統一的責任判定。
