
長跑 Agent 的權限邊界審批卡、意圖檢查與憑證隔離原文Claude Duet 的安全、隱私與憑證隔離設計https://claude.com/blog/claude-duet-safety-privacy-and-security一個關掉電腦還在跑的 Agent麻煩在哪常跑的 Agent 有個分水嶺它是不是在你關掉窗口之后還在干活。傳統(tǒng)的對話式助手每個動作都在你眼皮底下發(fā)生出錯最多是一句胡說。而一個自主 Agent用云端計算機替你讀收件箱、起草回復、下單、跑例行任務它在時間上和你錯開了——你不在場的那幾個小時就是它自由發(fā)揮的窗口。這時候防幻覺解決不了問題真正要防的是三件更具體的事它會不會替你把不該發(fā)的東西發(fā)出去、會不會在你沒同意的情況下動錢、會不會被人從網頁里塞一句話就把你的密碼交出去。Anthropic 在 Claude Duet 的發(fā)布文里把設計拆成了三條原則我覺得這三條幾乎是通用模板跟具體哪家模型無關你的信息要有分寸地處理發(fā)出的消息先過一道檢查你保留對它替你做什么的控制權Agent 永遠看不見你的密碼、瀏覽器 cookie、登錄令牌。下面按這三條往下拆重點看它們各自落了什么機制而不是記結論。一、審批卡把要不要做變成一個人能回答的問題讓 Agent 停下來問說起來容易做起來有兩個坑問得太少出事問得太多人會麻木地連點。Anthropic 的做法是在發(fā)送可能敏感的消息、付款、刪除任何東西之前彈一張審批卡卡上必須同時給出三樣東西動作是什么、目的地是哪里、內容是什么——內容里包括每一個收件人。然后等用戶點。這里有個細節(jié)值得抄審批卡本身在模型外面渲染旁邊還并行跑一個自動檢查判斷這個動作是否匹配你原本的意圖。這個檢查基于 Claude Code 的 auto mode 分類器擴展而來關鍵在于它不在干活的模型里跑——所以頁面里藏著的指令影響不了判定結果。想一下攻擊面就明白了如果要不要批準也由同一個模型判斷那么一段注入文本既能驅動動作又能說服審查者等于自己給自己發(fā)通行證。另外兩條規(guī)則很實用可以直接搬到自己的 Agent 上類別規(guī)則例子絕對禁區(qū)即使你批準也不做證券交易、賬戶間轉賬、訪問別人的賬號不認別再問我批過多少次每次都重新問付款/轉賬、刪除訂單、創(chuàng)建賬號第二類是最容易做錯的地方。很多 Agent 框架都提供本次會話內允許此類操作的記憶圖省事把付款也塞了進去結果一次心軟等于永久授權。官方也承認審批頻率是個需要長期調的參數(shù)理由是審批疲勞——請求太多人會不看內容直接點過去。這句話對做產品的人比對做安全的人更有用審批卡的數(shù)量本身就是一種安全預算給多了等于沒有。二、敏感信息兩級不是能不能發(fā)而是發(fā)之前先分級Agent 替你發(fā)消息最難的一步是決定哪些信息不該出現(xiàn)在這條消息里。你去讓它給團隊發(fā)周報它應該只寫大家本來就有權限看到的內容而不該把績效面談的細節(jié)帶上。Duet 為此單獨訓練了一個分類器和主模型分開跑在每條外發(fā)消息發(fā)出前檢查是否含敏感信息并把信息分成兩級絕不分享登錄憑證、完整卡號與銀行賬號、政府證件號。這類東西即使你親自要求Agent 也被指示不要發(fā)出。需要同意才分享健康、財務狀況等私人信息。你明確批準才能外發(fā)而且你自己的請求本身就算同意——給我牙醫(yī)發(fā)條消息說明牙疼這種不需要再彈一次卡。被攔下來之后Agent 還有一個動作可以做重寫這條消息把敏感部分去掉再拿給你確認。這個改寫而不是失敗的設計比直接報錯友好得多也讓攔截從阻斷變成了協(xié)作。官方在文中也明確說了局限還在研究預覽階段這些防護偶爾會漏掉一些東西也會把無害的消息標出來。這話得當真——分類器是概率件它的錯誤率決定了你能不能只靠它。所以審批機制不能省兩層要疊著用。三、憑證隔離讓它被釣魚變成一個不成立的問題這一節(jié)是整篇里最工程化的部分也是最值得抄的。原則很硬Agent 永遠看不到密碼、cookie、登錄令牌也不能把它們寫進記憶。這些東西只經過模型訪問不到的獨立機器審批和安全檢查也在那里跑。密碼。站點要密碼時你是在 Claude 應用內的表單里輸入的不是在網頁里。這個表單用一把單次密鑰加密密碼密鑰只存在于那臺安全云瀏覽器機器上、只用這一次密文原樣傳到瀏覽器由瀏覽器替你敲進站點。模型既看不到明文也沒有辦法保存或復述。這個設計直接改了釣魚的形態(tài)Agent 不持有你的憑證所以沒法被釣出密碼也沒有任何隱藏指令能讓它泄露一個它根本沒有的秘密。但反向的風險也出現(xiàn)了——登錄表單本身成了靶子任何東西都能偽裝成請輸入密碼。所以 Duet 的登錄表單只在你主動發(fā)起的登錄過程中、在應用內部出現(xiàn)永遠不會通過鏈接、短信、郵件或 claude.ai 之外的網站發(fā)給你。登錄令牌。連接受托的第三方服務時Agent 需要一個令牌。做法沿用 Claude Managed Agents 的思路真實憑證永不進入 Agent 干活的那臺機器進去的是占位符由機器外的一個代理在實際請求發(fā)出的瞬間把真值填進去。瀏覽器。瀏覽器跑在自己專屬的云端虛擬機里和模型、和 Agent 的工作機都分開。Agent 只能通過一組固定命令驅動它打開這個頁面、點這里、輸入這個。站點執(zhí)行的代碼留在瀏覽器機上站點代碼和 cookie 到不了 Agent 的記憶和你已連接的應用Agent 的任何命令也讀不出 cookie?;貋淼闹挥许撁嫖谋竞拖螺d文件——因為 Agent 得讀它們才能干活這也正是為什么其他檢查必須存在以及為什么要疊上瀏覽器提示注入的防護。通過瀏覽器上傳的文件走和外發(fā)消息同一套敏感信息檢查。還有一條容易被忽略Agent 要主動表明自己是 Agent?,F(xiàn)在它瀏覽器發(fā)出的請求帶一個可識別的 User-Agent出口 IP 段是公開的站點可以據(jù)此決定怎么對待它上線前他們還聯(lián)系了幾家大型網站給對方禁止 Duet 訪問的選項有些站選了。四、一個最小的審批網關骨架上面這些機制落到代碼上第一層其實很薄一個純粹的規(guī)則判定。下面這段是我按原文規(guī)則重寫的示意實現(xiàn)不是官方代碼也沒有對應任何 SDK。fromdataclassesimportdataclass,fieldfromenumimportEnumclassDecision(Enum):ALLOWallow# 規(guī)則層放行直接執(zhí)行NEED_APPROVALapproval# 渲染審批卡等人點DENYdeny# 硬禁區(qū)批準也不放行HARD_DENY{trade_security,move_money,access_other_account}NO_REMEMBER{pay,delete_order,create_account}dataclassclassAction:kind:str# 動作類型target:str# 目的地商戶域名 / 賬號 / URLpayload:str# 正文或金額recipients:list[str]field(default_factorylist)defgate(action:Action,remembered:set[str],approved:bool)-Decision:ifaction.kindinHARD_DENY:returnDecision.DENYifaction.kindinNO_REMEMBER:returnDecision.NEED_APPROVAL# 批過多少次都重新問ifaction.kindinrememberedandapproved:returnDecision.ALLOWreturnDecision.NEED_APPROVAL參數(shù)逐個說action是一次待執(zhí)行的動作target和recipients是審批卡要展示的目的地信息缺了它們卡片就沒法讓人做判斷remembered是這個會話里用戶勾過別再問我的動作類型集合approved是本次審批卡的結果。返回值是三態(tài)而不是布爾因為需要人確認和絕不允許是兩種完全不同的處理路徑混成 False 會讓上層分不清該彈卡還是該報錯。調用鏈是這樣Agent 產出Action→ 進gate得到三態(tài) → 若是NEED_APPROVAL就渲染卡片必須帶上 target、recipients、payload→ 用戶批準后再交給一個在模型外跑的意圖檢查 → 都通過才進執(zhí)行器。注意這個函數(shù)只做規(guī)則層語義上的這個動作是否匹配用戶意圖它答不了那需要另一個獨立跑的判斷單元。付款那條還要再加一層原文用的是錢包如 Stripe 的 Link出的一次性卡限商戶、限額你真卡號不給 Agent 也不給商戶。這層在代碼里體現(xiàn)為執(zhí)行器的約束不在gate里。五、怎么驗證自己的實現(xiàn)沒白做官方文里提了他們的測試方法我覺得這套可以直接拿來當驗收清單評測任務按日常任務形狀構造每個任務出三個變體正常版、帶注入指令版、誘導它做超出授權范圍的版除了自己構造的用例還并行跑真實使用的影子流量對整個系統(tǒng)建威脅模型把所有倉庫和信任邊界都圈進去每個新的憑證相關功能先在隔離的臺架上做紅隊通過后才發(fā)外部滲透測試公司拿著源碼測云瀏覽器和登錄表單是后續(xù)單獨一輪。不用五條全做但三變體和新憑證功能先隔離紅隊這兩條成本低、收益最大。尤其是第一變體之外的第三變體——誘導越權絕大多數(shù)自測都缺這一檔。收尾這篇的價值不在Anthropic 又發(fā)了個 Agent而在它把一件通常被含糊處理的事拆成了可實現(xiàn)的四層規(guī)則層決定哪些動作永遠不做、審批層決定哪些必須問、分類層決定哪些信息不能出去、隔離層決定憑證根本不進模型。四層各管一件事任何一層失效都還有下一層兜著。要記的就一句安全性不來自把提示詞寫得更嚴而來自讓模型沒有能力做那件事——它拿不到憑證、讀不到 cookie、看不見審批卡的判定邏輯能力邊界畫在模型外面。