AI 代理的身分危機：為什麼你的銀行會把機器人當成你
如果你關注了最近圍繞 AI 代理和銀行業的熱門新聞，你可能會想像自主機器人對大型金融機構發起協同網路攻擊。媒體大量使用了「失控 (rogue)」和「可怕 (terrifying)」等戲劇性的形容詞，無可否認，保持一定程度的謹慎是應該的。然而，如果你略過那些聳動的標題，去檢視銀行實際發布的聲明，就會發現現實情況遠沒有電影那般戲劇化——反而實際得多。
核心問題出乎意料地簡單：消費者正自願將他們的銀行使用者名稱和密碼交給 AI 助理，以自動化繁瑣的任務。他們希望這些機器人能查詢餘額、支付帳單，並在帳戶間轉帳。這些代理是在帳戶持有人的明確許可下，使用合法的憑證進行登入。當銀行將這種行為標記為「未經授權」時，他們的意思是未經他們的服務條款授權，因為這些條款幾乎普遍規定只有人類才能登入人類的帳戶。嘉信理財 (Charles Schwab) 的執行長明確向彭博社表示，他們正在主動封鎖試圖移動客戶資金的代理——甚至點名了 Meta 的 Muse。花旗銀行 (Citi) 也同樣直接，明確表示禁止第三方代理在其平台上登入或交易，儘管他們仍允許透過核准的開放銀行 (open-banking) 管道進行唯讀存取。
歸根結底，這些聳動的標題掩蓋了一個本質上關於憑證共享 (credential sharing) 的事實。對於金融科技業的資深人士來說，這種場景給人一種強烈的似曾相識感。
熟悉的戰場
在過去的十年裡，我們花了大部分的時間在預算應用程式上與這個完全相同的困境搏鬥。像 Mint 這樣的早期工具，其運作方式是儲存你的銀行密碼，並偽裝成你登入以抓取交易資料。銀行當時厭惡這種做法的原因，與他們現在厭惡 AI 代理這樣做的原因完全相同。最終，產業成熟了，轉向代幣化 (tokenized)、限定範圍的 API 存取，消除了資料聚合器囤積使用者密碼的需求。銀行目前試圖強迫代理使用的「唯讀」存取——這也是 Quicken 使用的相同基礎架構——正是這種演變的結果。那麼，為什麼 AI 代理又退回到古老的螢幕抓取 (screen-scraping) 方法呢？因為現代、安全的 API 尚未允許它們轉移資金，而轉移資金恰好就是使用者希望他們的代理去做的事。
隱藏的動機：必須承認這裡有雙重動機在起作用。雖然安全是一個真正的擔憂，但產業出版物對次要的財務焦慮表現得更為透明：銀行極度害怕 AI 代理會無情地將閒置資金從他們的低殖利率帳戶中轉出，並存入競爭機構的高殖利率帳戶。這並不能否定安全風險的存在，但當銀行高層將情況描述為「可怕」時，他們保護存款基礎的決心，與保護客戶的決心一樣強烈。
真正的安全威脅
這種趨勢真正令人擔憂的方面是，越來越多的證據表明，銀行無法準確區分由客戶發起的操作和由其 AI 代理發起的操作。有報導指出，代理會聯絡客服中心或執行使用者從未實際要求過的任務。
當 AI 代理使用你合法的密碼登入時，銀行的安全日誌會將其記錄為你。過去二十年中建立的幾乎所有詐欺偵測和身分管理系統，都基於一個二元假設：持有有效憑證的實體要麼是合法擁有者，要麼是惡意竊賊。AI 代理落入了一個盲點；它是一個執行委託意圖的授權身分，但具有非確定性 (non-deterministic) 的行為。我們目前的資安基礎架構根本不是為了分類這種情況而設計的。
此外，AI 代理非常容易受到提示注入 (prompt injection) 攻擊。如果你的代理在管理你的財務時，讀取了一個受感染的網頁、電子郵件或文件，該惡意輸入可能會劫持代理處於登入狀態的活躍工作階段。對於銀行的安全系統來說，這種被劫持的行為看起來與代理獨立決定採取失控行動毫無區別。
在滲透測試領域，獲得有效的憑證是終極獎勵，因為隨後的活動將完美無瑕地融入正常的使用者流量中。將你的銀行密碼交給 AI 代理會產生完全相同的漏洞，諷刺的是，這個後門是你自己安裝的，並且你還遞給了它一份待辦清單。
避開責任陷阱
在最近一次摩根大通 (JPMorgan) 的財報電話會議上，他們的財務長提出了一個令人深思的觀點：如果客戶將憑證交給 AI 代理，而該代理執行了不想要的交易，責任完全由客戶承擔。這不僅僅是企業的虛張聲勢。這背後的基本法規是 E 條例 (Regulation E)。根據其官方解釋，如果你將存取憑證和轉帳授權授予某人，而他們超出了該授權範圍，你將對這些轉帳負全部責任，直到你正式通知銀行撤銷授權為止。該法規的例子是指家庭成員或同事；當這個「某人」是一個自主軟體程式，或者當第三方透過提示注入劫持該軟體時，在法律上該如何適用仍未經過測試。據報導，監管機構已意識到迫切需要釐清這種確切情況。在他們釐清之前，你必須假設你的銀行會讓你對你的代理採取的每一個行動負責。
如果你已經與 AI 共享了憑證，補救步驟很明確：
- 立即重設你的銀行密碼。 這會使代理持有的任何快取憑證失效。
- 清除代理設定。 進入 AI 助理的介面，刪除任何儲存的登入資訊、活躍工作階段或已連結的帳戶。
- 審查已連結的應用程式。 檢查你的銀行「已連結服務」或「已連結應用程式」頁面，並切斷任何不熟悉或不再使用的存取權限。
- 啟用嚴格警報。 開啟每筆匯出轉帳、新增收款人及從無法識別的裝置登入的即時通知，並將警報門檻設定為零元。
如果你堅持使用 AI 進行財務管理，請透過支援的 API 連線將其限制為唯讀存取，或手動提供匯出的對帳單。正如美國銀行 (Bank of America) 執行長所說，資金流出帳戶的最終批准權應該永遠掌握在人類手中。無論你的銀行目前的執行政策為何，這仍然是極佳的建議。
更廣泛的企業影響
把「銀行」這個詞換成你公司的 SaaS 基礎架構，這整個故事就可以直接套用到你的組織。現在，你的員工幾乎肯定正在使用他們自己的活躍工作階段，在你的 CRM、工單系統、人資入口網站和電子郵件客戶端上部署瀏覽器代理和 AI 工具。你的審計日誌顯示的是人類活動，這意味著你正面臨著與目前困擾金融業完全相同的盲點。
為了減輕這種情況，你必須先找出這些代理在哪裡運作——尋找瀏覽器擴充功能、整合 AI 的瀏覽器，以及從外部基礎架構登入你的應用程式的雲端代管代理。目標是強迫代理使用它們自己獨立的身分，並具有限定範圍、委派的存取權限（例如具有狹窄權限的 OAuth 授權或專用的服務帳戶），而不是劫持人類的工作階段。這樣你就能在日誌中區分機器人流量和人類流量，並在不中斷員工工作流程的情況下撤銷代理的存取權限。
此外，將存取權限綁定到受管理的裝置，並實施防網路釣魚的身分驗證，例如通行密鑰 (passkeys) 或憑證。可以複製貼上到雲端代理中的密碼，不可避免地會遭到外洩。綁定裝置的身分驗證限制了有效工作階段可以被利用的地方。然而，也必須承認其局限性：在受管企業筆記型電腦上的使用者瀏覽器內本機執行的代理，將繞過這些裝置檢查，這突顯了為什麼強制實施獨立的代理身分是至關重要的。
最後，針對高風險操作實施升級 (step-up) 身分驗證。例行任務可以由代理自動化，但付款、權限修改或大量資料匯出等操作應需要明確的人類批准。建立正常使用者行為的基準，因為代理通常以機器的速度運作、在非上班時間活動，並且存取的紀錄數量遠超過人類可能會碰觸的數量。
現在是時候採用銀行的策略，進行「災後 (day after)」沙盤推演了。詢問你的資安團隊：如果利用合法使用者存取權限的 AI 代理失控或外洩資料，誰會注意到？能多快撤銷存取權限？最關鍵的是，你將如何區分哪些操作是人類進行的，哪些是代理執行的？
不可避免的妥協
銀行今天封鎖共享憑證的代理是合理的，但他們也意識到他們無法永遠堅守這條防線。消費者需求太高，競爭對手最終會提供無縫的整合。解決方案可能會反映出預算應用程式大戰的結果：AI 代理最終將獲得它們自己專屬、限定範圍且易於撤銷的存取權限，並配備嚴格的交易限制和轉移資金時強制性的人類批准。在這種安全的基礎架構出現之前——無論是在你的銀行還是在你的企業環境中——不要把鑰匙交出去然後只能祈求一切順利。
