Self Agent Vault 上線：讓 AI 代登入與付款，如何把真實帳密留在模型之外？

Agent Vault 要處理的，是 AI 助理開始操作網站後，帳密與信用卡應該放在哪裡。若直接貼進對話，這些資料也會進入模型處理的內容。

模型可能需要讀網頁、理解指令，再完成登入或結帳，但做這些工作，不表示它必須直接看見真實卡號與密碼。

Self 於 2026 年 10 月 15 日推出這個產品，將登入與付款交給獨立的憑證處理層，希望縮小敏感資料暴露給 Agent 的範圍。

憑證是證明身分或授權的資料，例如帳密與付款資訊。把它和模型對話分開管理，能減少某些外洩途徑，但不會自動解決所有錯誤購買與越權操作。

這比較適合已經讓助理處理網站工作的使用者評估。如果只是查資料與整理筆記，沒有登入或付款需求，就不必因新產品上線而增加一層整合。

要理解這種分工，先看模型操作表單時，真實資料在哪個階段才出現。

Agent Vault 如何讓模型看不到真實卡號？

依 Self 的官方公告，Agent 會先在表單填入替代標記，真正資料則在受保護的執行環境內換入。

替代標記本身沒有真實卡號的價值，而且只在已授權的工作階段生效。模型因此能安排操作步驟，而不必把付款資訊當成一般文字處理。

可信執行環境扮演什麼角色？

可信執行環境，英文簡稱 TEE，是用來隔離特定程式與資料的一種執行區域。這裡的用途，是在受限制的環境中處理真實卡號，再完成付款。

登入則採相近概念，透過代理層在登入時換入真實帳密。代理層是在系統與網站之間處理資料的服務，所以資料沒有直接交給模型，仍有其他元件需要信任。

因此，「模型看不到」描述的是資料路徑。它能減少模型內容遭讀取時的影響，但不能直接等同所有元件都沒有風險。

官方宣告提供了一種產品架構，使用者仍應查看實際權限、紀錄與撤銷方式。真正導入時，要知道誰能啟動操作，以及操作能到哪一步。

登入與購物授權，為什麼要分開？

因為允許讀取帳戶資料，不一定代表允許建立訂單。讓 Agent 能登入，也不能直接推論它可以變更訂閱、儲存付款方式或購買任何商品。

例如請助理查詢行程，它可能只需要讀取既有預訂。若同時給了購買權限，能力就超過原本任務，所以系統需要把可做的操作說清楚。

官方提到可依交易、日、週與月設定支出限制，也能限定商家並撤銷。這些控制的目的，是讓授權範圍能更接近實際任務。

以下把控制項與它能處理的問題整理在一起。

表格說明，控制不是只設定一個金額。即使消費沒有超過上限，買錯商品、日期或數量，仍然可能不符合使用者的原意。

人應該在哪裡確認？

我會把確認放在商品、總額與收件或服務資料已經清楚之後。這樣使用者核對的是一筆具體交易，而不是籠統地答應「讓助理幫忙」。

這是使用建議，並非本文已替任何人設定付款。憑證保護與交易批准是兩件事，需要在產品流程中配合，才容易維持使用者的控制。

官方相容性與安全宣告，各能證明什麼？

相容清單能說明官方測過哪些用途，但不能保證每個帳戶、地區與網站版本都會成功。登入頁、驗證流程與結帳條件都可能變動。

Self 提到私有測試期間，使用者曾在多個網站完成登入或購買。這是官方回報的使用情境，不能改寫成每個網站都正式認證或合作。

代理之間能共用，是否就不必再管理權限？

官方主打在不同 AI 助理之間使用同一套憑證管理，減少更換工具時重新設定。這有便利性，但每個助理獲得的操作範圍，仍應由使用者決定。

例如一個 Agent 只負責找資料，另一個負責採買，不應因為接到同一個保管服務，就取得完全相同的能力。共用資料管理與共用全部授權，並非同一件事。

團隊也要知道成員離開、工具停用或裝置遺失時，從哪裡取消權限。如果撤銷程序不明確，憑證集中管理的好處，就很難轉化成日常可控的流程。

這些問題不必等到事故後才處理。用低風險案例測一次，就能看出哪些控制真的可用，哪些還需要補充說明。

延伸閱讀：Personal Agent Protocol 草案解析：Poppy 如何讓個人 AI 取得授權、跨網站辦事？。

先用低風險情境，檢查撤銷與紀錄

我會先驗證登入、查看與撤銷，最後才考慮付款。因為這些基礎行為如果無法清楚追蹤，增加購買能力只會讓問題更難處理。

測試可以選沒有重要資料的專用帳戶，先給有限功能，再確認 Agent 看見什麼、網站留下什麼紀錄，以及停用之後是否還能繼續操作。

當需要評估購物功能，先把允許商品、商家與金額寫清楚，並保留最後確認。完成後要回到商家查看訂單，而不是只相信 Agent 說已成功。

密碼藏好了，還有哪些資料可能外流？

購物內容、地址、查詢文件或帳戶頁面的資訊，也可能進入助理工作內容。因此，憑證分離不能代替整體資料範圍管理。

如果任務只需要一筆訂單，就不應讓 Agent 讀取全部歷史紀錄。這樣即使資料處理出問題，影響也較接近本來授權的範圍。

對公司而言，還應確認誰能查看操作紀錄，以及發生錯誤時由誰處理。產品提供功能，不代表組織已經建立好責任分工。

當撤銷、紀錄與交易核對都清楚，這類產品才比較有機會成為可靠的工具。否則，只有「不把卡號交給模型」一個優點，仍不足以支持全面採用。

把撤銷測試放進日常管理

撤銷功能應該在不需要緊急處理時就試一次。因為發生問題後才尋找入口，團隊可能連要停用哪個 Agent、哪張卡或哪個工作階段都不清楚。

可以先安排一個只需查看資料的測試，完成後取消存取，再確認後續操作是否被拒絕。這能檢查權限的開始與結束，而不是只證明登入當下成功。

若使用多人共用流程，也要留下誰批准、哪個助理執行與網站實際結果。這些紀錄應能對到具體操作，才能在訂單有誤時找出原因，而非只看到一段自然語言摘要。

對於訂閱型購買，還需要另外核對後續扣款與取消方式。一次允許購買，不代表使用者理解所有續約條件，所以這些內容應在最後批准前就清楚呈現，並保存核對結果。

保護憑證，也要能看見操作結果

如果助理回報付款成功，仍應到商家確認訂單、金額與狀態。因為憑證處理服務完成一個步驟，不代表商品、日期與數量都符合原本需求。

同樣地，登入成功後也應確認沒有多出不需要的操作。把外部網站結果與助理回報對照，才能知道授權是否被正確執行，而不只是在技術上完成連線。

Agent Vault 常見問題

接上後就可以放心讓 AI 自動購物嗎？

仍要限定商品、商家、金額與批准流程。憑證處理改善，不會替使用者判斷每一筆購買是否符合需求。

模型看不到密碼，代表整個系統沒人能碰到嗎？

不能這樣推論。真實資料仍由特定元件處理，需要分別確認執行環境、存取權限與供應商條款。

官方列出的網站，都是合作夥伴嗎？

測試成功與正式合作不同。應依各方公告判斷關係，不能把一份相容或測試清單當成商家全面背書。

需要為短期優惠立刻註冊嗎？

先確認自己是否有登入與付款的實際需求，再評估方案。短期活動會變動，不應取代對權限與資料路徑的理解。

需要代操作的人，先把授權與資料分工做好

Agent Vault 提供的是一種把敏感憑證移出模型工作內容的方式。對已經依賴助理操作網站的人，值得評估，但採用前要先證明限制、撤銷與紀錄能正常運作。

訂閱 AI 郵報，持續追蹤個人 Agent 的權限與付款工具。從最小的登入情境開始，比直接交出完整購物能力更容易看清產品是否符合需求。

延伸閱讀：TencentDB Agent Memory 是什麼？把 AI 工作記憶分層，本機儲存還要注意哪些事？。

資料來源

• Self Agent Vault 官方發布。
• Self 官方產品資訊。
• Self 官方 X 示範影片。