AI 代理所有權是信任的基礎

2026年5月15日，內蓋夫本-古里安大學、東北大學與 Amrita Vishwa Vidyapeetham 的研究人員，將代理歸因定義為：把觀察到的 AI 代理互動，連結回託管供應商中應負責的帳戶。¹

這個說法聽起來很狹窄。問題本身並不狹窄。代理可能對使用者發送垃圾訊息、抓取系統資料、冒充客服人員、執行資安任務、呼叫工具、花費金錢，或變更基礎架構。受影響的一方看得見行為，卻無法識別部署該代理的操作者。¹

AI 代理所有權就是缺少的信任基礎。每一個自主動作，都應該對應到負責帳戶、工作階段、權限範圍、人類或組織擁有者，以及停止路徑。記錄告訴您發生了什麼；所有權告訴您誰能為此負責。

TL;DR

代理安全不能只停在工具權限、執行環境掛鉤，或最終答案的證據。這些控制很重要，但無法回答問責問題：正在執行的代理由誰負責？

新的代理歸因論文提出一套由供應商居中協調的協定，使用金絲雀標記，把觀察到的有害互動連結到供應商的工作階段與帳戶。¹這項研究面向的是濫用回應與法律責任。產品團隊則需要在自家系統內建立一個更日常、更小型的版本：每一次代理執行，都應帶有所有權紀錄，串起帳戶、工作階段、權限範圍、工具活動、審查路徑與終止開關。

重點整理

給代理平台團隊： - 把所有權視為執行環境欄位，而不是帳務上的事後補充。 - 為每一次代理執行附上擁有者、帳戶、工作階段、工具範圍與停止控制。

給安全團隊： - 沒有所有權的記錄會拖慢事件回應。沒有記錄的所有權則會削弱證據。 - 兩者都要：動作追蹤，以及負責帳戶路徑。

給產品團隊： - 讓使用者看見誰或什麼正在代表他們行動。 - 區分委派動作與委派責任。

給政策與信任團隊： - 為授權回應設計歸因，而不是為了隨意去匿名化。 - 紀錄足以停止傷害、審查濫用並尊重正當程序的資訊。

所有權不是個人檔案名稱

多數產品已經會顯示某種形式的身分。聊天視窗可能顯示工作區、使用者頭像、機器人名稱、API 金鑰標籤，或組織。這層表面資訊能幫助人們判斷情境，卻不能證明所有權。

代理所有權需要更嚴格的契約：

這份清單看起來偏營運，因為所有權本來就是營運問題。當代理發出2,000則不當訊息，或猛烈敲打第三方端點時，一個標籤幫不上忙。回應團隊需要工作階段、帳戶、權限範圍與停止路徑。

代理金鑰需要風險預算談的是權限面：金鑰應授予狹窄、由伺服器強制執行的能力。所有權談的是責任面：每一次使用該權限，都應指回一筆負責紀錄。

歸因論文補上了什麼

這篇論文正式描述了一個代理操作者很快就會認出的缺口。受害者看得到代理的行為。供應商看得到模型呼叫與帳戶記錄。任何一方單獨來看，都看不到兩邊的完整視角。¹

論文提出的協定用金絲雀標記銜接這兩種視角。授權方把標記注入嫌疑代理很可能取用的內容。如果代理把該內容轉送進供應商託管的模型呼叫，供應商就能在狹窄時間窗內搜尋工作階段記錄，找到金絲雀標記，還原工作階段，並把工作階段連結到帳戶。¹

論文區分了簡單與困難情境：

「具效用」這個概念很重要。詐騙代理可能需要目標的情緒線索。網頁代理可能需要可見頁面內容。資安代理可能需要檔名與回應產物。如果操作者過度過濾，代理的任務表現會與歸因證據一起流失。¹

論文中的資安代理實驗把這個取捨具體化。當抑制措施移除任務相關產物時，能察覺金絲雀的對手讓代理解題率從51%降到9%。檔名與可見正文識別碼仍分別保留了77%與70%的歸因證據；語意金絲雀在對抗性語意軌道中，則達到至少98%的真陽性率。¹

這些數字不該變成產品行銷話術。論文測試的是特定代理、包裝層與金絲雀類型。真正應該留下的教訓是：當歸因訊號附著在代理實際需要的內容上時，效果最好。

記錄必要但不足夠

OpenAI 的 Codex 安全文章描述了一種成熟的控制形態：有邊界的執行、核准、受管理的網路政策、憑證儲存、規則、受管理的設定，以及代理原生遙測。²遙測面包括使用者提示、核准決策、工具執行結果、MCP 伺服器使用情況，以及網路 Proxy 允許或拒絕事件的 OpenTelemetry 紀錄。²

OpenAI 也描述了一套安全分流工作流程：使用 Codex 記錄，檢查可疑端點警示周邊的原始請求、工具活動、核准決策、工具結果與網路政策決策。²

這些證據必要。它們仍然需要所有權。

工具追蹤可以說明：

代理執行追蹤是執行環境契約主張，追蹤證明路徑。所有權證明該路徑背後的負責方。強健的系統需要把兩種紀錄在工作階段層級接起來。

Codex 說明這個問題已不再只是理論

OpenAI 於5月14日發布的 Codex 公告提到，每週有超過400萬人使用 Codex，並描述了一種行動工作流程：使用者可以用手機審查輸出、核准命令、切換模型、啟動工作，並追蹤截圖、終端機輸出、差異、測試結果與核准。³同一則公告也指出，Remote SSH 已達一般可用狀態，讓 Codex 能在遠端機器與受管理環境中執行工作串。³

這種產品形態把代理工作推進到多個裝置、機器、工作串、核准、憑證與本地工具之間。單次代理執行可能涉及筆電、手機核准、遠端主機、專案、外掛程式、瀏覽器、Shell，以及版本控制操作。

所有權紀錄必須跟著這次執行移動。否則系統能回答「執行了什麼命令？」，卻失去「命令執行當下，誰擁有這次執行？」這個答案。

Codex 掛鉤讓代理框架成真把掛鉤、核准、Git 監管、證據與品味，視為代理工作周圍的一層操作系統。所有權也屬於同一層。掛鉤可以阻擋高風險動作。追蹤可以解釋已完成動作。所有權則把這次執行連結到能為兩種結果負責的帳戶與操作者。

執行環境所有權契約

團隊不需要為每個內部任務套用完整的金絲雀歸因協定。他們需要的是第一方所有權契約，讓歸因在出事之前就成為日常。

從每次代理執行的一筆紀錄開始：

這筆紀錄應位於聊天逐字稿之下、原始基礎架構記錄之上。產品支援可以使用它。安全團隊可以使用它。法遵可以使用它。工程團隊也可以在復原時使用它。

欄位名稱不是重點。不變原則才是重點：沒有負責的執行紀錄，就不該有代理動作。

所有權需要隱私邊界

如果團隊把歸因當成預設揭露所有人身分的許可，歸因也可能被濫用。所有權論文直接點出這項風險，並把協定框在授權、可稽核的權責機關、政策依據與法律程序之內。¹

產品團隊應該仿效這種克制。

所有權不應變成隨意監控。強健的歸因會為受害者、平台、供應商與操作者提供回應路徑。薄弱的治理，會把同一個信任基礎變成另一個信任問題。

設計原則很簡單：讓每個代理都對系統負責，也讓每次所有權查詢都對政策負責。

所有權與現有代理控制如何搭配

所有權不取代堆疊中的其他部分。

OpenAI 的 Agents SDK 公告指向同樣的分層形態。SDK 讓代理具備受控工作區、檔案與工具檢查、MCP、技能、AGENTS.md、Shell、修補、沙箱執行，以及以 Manifest 為基礎的工作區。⁴AgentTrust 則提出互補的安全論點：在執行前檢查工具呼叫，並回傳 allow、warn、block 或 review 等結構化判定。⁵

這些系統決定代理下一步能做什麼。所有權決定誰為這次執行負責。

AI 代理應該呼叫模型主張，代理應該呼叫訓練過的模型，而不是自行編造估算。所有權把同樣的紀律延伸到權限。系統應該知道一個動作來自人類點擊、代理工作階段、模型工具、排程自動化，還是委派政策。

這種區分能保護使用者。使用者不該被迫猜測：某個動作究竟來自自己、來自以其帳戶行事的助理、來自組織政策，或來自遭入侵的自動化。

代理需要監督介面談的是這個問題面向使用者的一側。所有權提供介面之下的紀錄。審查包是新的最終答案談的是完成成品。所有權提供能接受、拒絕或撤銷該成品的一方。

決策規則

在部署一個會影響其他人或外部系統的代理之前，先問一個問題：

如果明天有人投訴這個代理，我們能否識別該次執行、帳戶、權限範圍、核准事件，以及能停止它的人或團隊？

如果答案是否定的，這個代理就還沒準備好進入生產環境。

產品可能已經有記錄。可能已經有權限。也可能已經有提示，告訴模型要守規矩。這些部分在串成一筆可問責紀錄之前，都不等於所有權。

代理所有權應該變得和請求 ID、稽核記錄與 API 金鑰一樣平常。這項工作聽起來或許官僚，但替代方案更糟：自主系統可以行動，卻沒有人能為行動負責。

FAQ

什麼是 AI 代理所有權？

AI 代理所有權是執行環境紀錄，會把代理動作連結到負責該次執行的帳戶、工作階段、操作者、權限範圍、追蹤與停止路徑。

代理所有權和代理歸因有何不同？

代理所有權是第一方產品契約。系統會在執行前與執行中記錄所有權。代理歸因則處理更困難的事後問題：當受影響的一方本來不知道擁有者是誰時，把觀察到的有害行為連結到負責的供應商帳戶。¹

為什麼只有記錄不夠？

記錄可以顯示命令、工具呼叫、核准與網路決策。但當記錄無法回答誰委派了這次執行、誰擁有權限範圍，以及誰能停止或審查代理時，記錄就失效了。

供應商是否應向任何提出要求的人揭露代理擁有者？

不應該。所有權查詢應要求授權存取、政策依據與稽核。對外揭露應有適當流程。只有當查詢路徑本身也受到治理時，歸因才能保護信任。¹

最低生產要求是什麼？

每一次可能影響外部系統的代理執行，都應具備執行 ID、帳戶 ID、操作者 ID、權限組合、核准紀錄、追蹤連結、停止控制、審查擁有者與保留政策。

參考資料