AI agent 真正權力喺執行框架:跨平台權限未跟得上工具擴張
Tech News

AI agent 真正權力喺執行框架:跨平台權限未跟得上工具擴張

圖片:via iThome — https://www.ithome.com.tw/news/178100
TechLab 編輯部(譯)·

Mozilla 報告拆解工具、記憶同寫入權限點樣改變安全邊界

AI agent 開始幫手改程式、發訊息、查內部資料,安全問題已經唔止係模型會唔會答錯。佢睇到咩、記低咩同做到邊一步,好大程度取決於包住模型嗰層執行框架(agentic harness)。iThome 報道引述 Mozilla 最新報告,指呢層軟件正成為 AI 產品競爭重點,而跨框架權限仍有明顯空位。

換模型容易,換唔走已批出去嘅權力

所謂 agentic harness,可以理解成模型對外嘅手腳同門匙。佢負責揀工具、保存記憶、安排多步任務、執行程式,同埋決定幾時要問人批准。兩套系統用同一個模型,只要工具清單、記憶策略、sandbox 或權限規則唔同,做出嚟嘅結果同風險已經可以差好遠。公司就算轉用另一個模型,原有工具憑證、資料出口同批核漏洞亦唔會自動消失。

呢點亦拆開咗「接到 MCP 就處理好權限」呢個常見誤會。MCP 統一咗 agent 點樣發現同呼叫外部工具,2025 年 11 月版授權規格亦用 OAuth 2.1、resource binding 同逐步加權限等機制保護連線。**連到某個 MCP server 只代表通過連線授權,每次操作應唔應該批准,仍要另外判斷。**同一張 token 可唔可以改十個檔案、向外傳資料或動用預算,仍要由 host、工具同公司政策自行判斷。

「讀取安全、寫入危險」只夠做第一層分類

Mozilla 將問題集中喺寫入操作,理由幾直接:列出日曆通常可以重複做,寄出電郵、刪除資料、push 程式碼或者落單就可能收唔返。報告話現有生態大約有十多套框架、十套 harness 同三種 peer protocol,但仲未有可攜式規則,統一標示邊類寫入可自動做、邊類要人批、邊類要封死。呢個係 Mozilla 按自己盤點得出嘅結論,唔應當成全行業完成過正式認證嘅統計。

讀取亦唔可以一概當低風險。Agent 如果同時睇到內部程式碼、客戶資料同對外網上工具,一次 prompt injection 已可能叫佢將內容送出去。Google Cloud 嘅 MCP 安全指引亦建議為 agent 建立獨立身分,只批任務所需嘅最低權限,同時分隔唔同用戶同 agent 嘅記憶。實際設定時,資料敏感度、對外傳送能力同寫入後果要一齊計,單靠 read/write 兩格未夠細緻。

93% 批准率有警號,但適用範圍要講清楚

Mozilla 宣傳文章提到,用戶批准 agent 要求嘅比例最高達 93%。追返原始出處,呢個數字來自 Anthropic 嘅 Claude Code telemetry,講緊該產品用戶批准權限提示嘅比例;Anthropic 公開文章冇交代樣本數、統計時段同提示類型分布。換句話講,佢足以顯示 coding agent 有 consent fatigue,但唔可以推算成所有 AI agent 用戶都有 93% 機會亂批權限

狂彈確認視窗亦唔代表管得嚴。當讀檔、跑測試、改檔同連網逐項問一次,人好快會慣性撳批准;誤批之後,系統紀錄仲可能只見到「用戶同意」,睇唔到對方當時有冇掌握完整影響。較合理嘅做法係預先批出窄範圍,例如指定目錄、網域、資料表同金額上限;去到刪除、發送、付款或 production 變更,就顯示完整內容、差異同影響範圍,再交人確認。

公司而家可以點收窄風險

跨框架標準未成熟,IT 團隊可以先把權限政策放喺 agent 外圍:每個任務用獨立身分同短效憑證,預設封鎖未知工具,sandbox 限制檔案及網上出口,高風險寫入要獨立批准,同時保留輸入來源、工具參數、政策判斷、批准者同實際結果。撤銷權限亦要即時生效。2026 年 2 月出現過一份 Agent Authorization Profile 草案,嘗試用 OAuth、JWT 同任務限制表達呢類規則,但文件已在 8 月 6 日到期,仲未成為正式業界標準。

Mozilla 本身推動開源 AI,報告自然重視開放同可攜性;但佢指出嘅權限斷層,亦得到雲端供應商安全指引同授權草案呼應。公司部署 Codex、coding agent 或內部 AI automation 時,最值得先盤點每個 agent 手上有咩憑證、資料出口同寫入能力,再諗自動化可以放到幾盡。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook