Claude Duet 智能體 憑證隔離:別讓 AI 看到密碼

先説結論
ClaudeDuet智能體憑證隔離機制證明,防範AI越權與資訊泄露的底線,絕不是在提示詞裏叮囑模型保持謹慎,而是從架構上把密碼與支付憑據徹底剝離出模型上下文。
2026 年 10 月 23 日,Anthropic 發文介紹了關於 Claude Duet 智能體 憑證隔離的技術方案。這是一個能在雲端電腦上自主運作的智能體,即便用戶關閉了應用,它也能在後台持續查閲郵箱、起草回覆、預訂行程並執行預設任務。

很多人看到這則消息的第一反應是:智能體終於能替我幹全流程雜活了。但作為企業管理者,我建議你先看它的安全防線。一家做跨境電商的企業的技術負責人曾經問過我:如果讓智能體幫運營人員在後台採買商品或回客戶郵件,到底怎麼保證它不會被黑客投毒把管理員密碼套出來,或者直接划走賬上的流動資金?
Anthropic 這篇技術説明給出了明確的解法:不要寄希望於大語言模型「自覺遵守紀律」。當智能體開始接管發消息、採購付款和刪除數據等高危操作時,安全防禦必須架設在模型之外。
為什麼絕不能把 API 憑證直接傳給 AI 智能體?
很多團隊在搭建內部自動化工具時,最常見的粗暴做法就是把數據庫密碼、第三方平台的 API Key、甚至登錄 Cookie,直接作為系統提示詞或環境變量塞進上下文。這種做法在智能體需要調用外部工具時極其脆弱。一旦智能體讀取的網頁或郵件裏藏着惡意注入指令(Prompt Injection),模型很可能會聽從外部黑客的唆使,乖乖把上下文裏的密鑰當成普通文本打印出來。
Claude Duet 的核心做法,是在大模型工具調用權限上做物理層面的剝離:模型本體永遠看不到真實的密碼、瀏覽器 Cookie 或登錄令牌。
當網站需要輸入密碼時,用戶在專屬界面內填寫,系統使用單次有效的密鑰進行加密,直接交由隔離的雲端瀏覽器容器解密輸入,整個密文不會被模型讀取,模型也無法將其存入記憶。當智能體調用已連接的企業應用時,模型所在環境拿到的只是一個佔位符(Placeholder),真實的訪問令牌由外層的代理服務在請求發出的一瞬間填入。
這意味着,即使網頁裏包含惡意提示詞試圖套取憑證,Claude Duet 也交不出來,因為它的模型上下文中根本沒有這些機密數據。
[ 用戶或外部網頁輸入 ]
│ (含潛在提示詞注入風險)
▼
┌────────────────────────────────────────────────────────┐
│ 大語言模型決策環境 (Claude Duet 上下文) │
│ - 僅持有憑證佔位符 (Placeholder) │
│ - 無法讀取真實 Cookie / 密碼 / 支付令牌 │
└────────────────────────────────────────────────────────┘
│
▼ (僅發出抽象動作指令: "點擊/提交/發起支付申請")
┌────────────────────────────────────────────────────────┐
│ 外部代理與獨立安全攔截層 │
│ ├─ 外部意圖分類器 (獨立檢查是否偏離用戶初衷) │
│ ├─ 敏感資訊分類器 (絕不共享 / 需同意共享兩級分流) │
│ └─ 憑證隔離代理 (動態填充真實 API [Token](/glossary/token/) / 注入密碼) │
└────────────────────────────────────────────────────────┘
│
▼ (通過審批卡彈出確認 / 一次性虛擬卡扣款)
[ 最終高危操作執行 (第三方應用 / 銀行扣款 / 數據刪除) ]
智能體支付授權與敏感操作,怎麼做到既自動化又不失控?
讓智能體接管流程,最怕它失控扣費或誤刪核心數據。在 Claude Duet 的架構裏,Anthropic 設立了兩個核心攔截機制:外部意圖分類器與高危動作審批卡。
首先是意圖校驗。當智能體準備執行發送敏感消息、付款或刪除內容等操作時,系統會啓動一個獨立於主模型之外的自動化檢查程序(基於 Claude Code 的 auto mode 分類器擴展而來)。這個分類器不運行在執行任務的模型內部,因此外部網頁中暗藏的指令無法干擾它的判斷,它只專注評估當前動作是否符合用戶的原始意圖。
其次是支付鏈路的物理隔離。在智能體支付授權場景下,Claude Duet 並不直接綁定用戶的實體信用卡,而是接入類似 Stripe 的 Link 錢包,生成針對單筆交易、限定商戶與具體金額的一次性虛擬卡。用戶必須在審批卡中看清收費明細、目標對象和確切金額,並在自己的錢包應用中手動確認,真實的卡號既不透露給智能體,也不透露給商家。
同時,Anthropic 明確劃定了不可逾越的紅線:像證券交易、賬戶間轉賬、訪問他人賬戶等行為,即便用戶授權也一律禁止執行;而對於付款、刪單、創建新賬號等操作,系統永遠不會開啓「不再詢問」選項,必須每一次都經由人工核准。
企業 AI 工作流隔離與高危操作防護自查清單
如果你的團隊正在評估或搭建自己的內部智能體,建議拿下面這份防護清單逐項比對現有系統。安全防護不能停留在口頭約定,必須固化為系統攔截規則:
| 防護維度 | 常見低安全做法(應避免) | 工業級防護標準(Claude Duet 範式) |
|---|---|---|
| 憑證存儲 | 密碼、API Key 直接明文寫入 Prompt 或模型工作環境 | 上下文僅保留佔位符,由外部隔離代理在網絡層注入憑證 |
| 支付鏈路 | 綁定公司長期可用信用卡,允許 AI 自動輸入卡號 | 接入一次性虛擬卡機制,單次限定商戶與額度,需移動端二次確認 |
| 指令攔截 | 依賴主模型自己在輸出前做「自我反思與對齊」 | 部署獨立於主模型之外的外部分類器,專項檢查意圖偏差與注入攻擊 |
| 敏感資訊外發 | 由模型自行判斷哪些內容屬於公司隱私 | 設立兩級管控:核心憑據絕不允許外發,健康與財務數據需顯式同意 |
| 高危動作授權 | 開啓「全自動免密」,或設置泛化的全部信任 | 扣費、銷單、刪庫操作強制彈出審批卡,永久禁用「記住此操作」 |
從星盒的實踐看
在企業落地實際業務時,AI智能體安全從來不是一個理論命題,而是決定系統能不能真正上線的門檻。
從星盒AI服務 500 多家企業的實測經驗來看,企業在推進自動化時最容易犯的錯誤,就是為了圖省事,把客服智能體或營銷智能體的調用權限放得過寬。我們在為客戶定製營銷智能體與部署全自動化系統時,始終堅持工作流與機密數據隔離的原則。
星盒的定位是專注企業增長的 AI 營銷服務商。在我們的新媒體內容工廠與星盒星盒!企業全能 AI 營銷智能體的架構中,員工在微信中喚起智能體協作時,智能體讀取的是經過嚴格權限梳理的企業專屬知識庫,而內部核心管理權限與外部接口分屬不同的安全邊界。
自動化必須建立在可控的邊界之內。星盒平台已部署的 300 多組實戰智能體,之所以能幫企業把單人日產出提升約 30 倍、將人力成本約降低 90%,核心前提就是讓 AI 專注在內容生成與策略診斷上,把高風險的業務確認權牢牢留在管理者手中。
常見問題
企業智能體如何防止私鑰和密碼泄露?
最關鍵的做法是把憑證徹底移出模型的上下文。模型只負責決策併發出抽象指令,真實環境裏的密碼和私鑰保存在獨立的雲端安全環境或代理服務中,在網絡請求發出時由代理動態填充,智能體本身既無法查看也無法記憶。
智能體自動付款怎麼做權限隔離?
不能直接向智能體開放無限額的支付賬戶。應採用限定額度與特定商戶的一次性虛擬卡方案,並強制在扣款前通過審批卡展示明細,由管理人員在獨立的支付驗證端手動確認授權。
為什麼不能把 API 憑證直接傳給 AI 智能體?
因為大語言模型容易受到間接提示詞注入(Prompt Injection)攻擊。一旦智能體讀取了被黑客篡改的網頁、郵件或外部文檔,惡意指令可能誘導模型將上下文中的明文 API 憑證以文本形式泄露或發送到外部伺服器。
企業部署自主智能體需要哪些外部安全攔截?
企業需要部署獨立於主模型之外的意圖分類器,用於比對任務動作是否偏離用戶初衷;同時要建立敏感資訊外發過濾機制、針對付款和刪除等高危操作的人工審批流,以及隔離運行的沙箱執行環境。
參考資料
- Claude:Blog(2026-10-23):https://claude.com/blog/claude-duet-safety-privacy-and-security
本文由星盒AI 寫稿智能體撰寫和配圖,經自動審核後發佈,內容僅供參考。
相關閲讀
AI 行業熱點
Anthropic 智能體架構 合併子智能體:系統精簡實操指南
Anthropic智能體架構合併子智能體指南指出,盲目堆砌多智能體不僅增加延遲還會丟失細節;把子智能體摺疊為帶技能的單主循環,能讓系統運行速度大幅提升。
2026 年 10 月 25 日 · 6 分鐘讀完
AI 行業熱點
Kimi K3.1 Pro 企業落地:長上下文降價後業務流怎麼改
KimiK3.1Pro企業落地帶來2.8T開源參數與百萬級長文本降價,企業不必再花大精力切碎知識庫做檢索,但長流程智能體需要按吞吐與成本重新分級。
2026 年 10 月 24 日 · 7 分鐘讀完
AI 行業熱點
智能體自動發佈靠譜嗎?Replit自動修復部署實踐
**智能體自動發佈**並非不可控,關鍵不在診斷精度而在分級放權。建立生產環境容錯與權限隔離邊界,是企業安全落地AI運維智能體的核心前提。
2026 年 10 月 23 日 · 7 分鐘讀完