這是誰發出的請求？代理身分驗證入門——Keycard 產品負責人 Kamil Potrec

Keycard 產品團隊成員 Kamil Potrec 主張，代理（agent）的認證與授權已不能再被視為可有可無的選項，因為非確定性的代理如今正以當初並非為它們設計的憑證，代替使用者行事。這場演講大部分時間都花在憑證架構問題上——使用者、代理、MCP 伺服器與後端服務之間如何交換 Token、為何目前個人存取權杖（personal access token）與服務帳戶的做法行不通，以及為何單靠 SDK 無法解決。演講最後提出一套控制平面（control plane）與閘道（gateway）的設計，並附上幾點實作警告。

Potrec 是從廠商立場發言：Keycard 販售的是代理身分、政策、稽核與閘道的控制平面，他也請聽眾到攤位逛逛，並造訪 agentbaseline.org——該公司已在那裡釋出參考實作。以下簡報依論點輕重順序重建他的主張：當今憑證散亂的失效模式、他認為應取而代之的 OAuth 與工作負載身分（workload identity）模式、阻礙這套模式落地的規模問題、為何只靠 SDK 強制執行行不通，以及閘道的取捨。

今日的代理憑證鏈，無法交代究竟是誰採取了行動

Potrec 走過標準的代理架構，並點出大家常跳過的部分：使用者與代理之間如何互相認證。使用者會取得一個不透明的存取憑證——通常是個人存取權杖（PAT）——用來識別其身分，並讓代理自行判斷是否該行動。若代理在本機執行，這一步有時會被整個略過。代理另外還需要自己的憑證，最常見的是用來與模型供應商溝通、以便進行推理的 API 金鑰。當模型決定呼叫工具時，通常會連上遠端的 MCP 伺服器，而這又需要另一組憑證。

針對這組 MCP 憑證，Potrec 列出他觀察到的三種做法：代理直接把使用者的 Token 透傳過去；代理自己持有一把靜態金鑰；或是愈來愈常見的動態憑證機制。在前兩種情況下，MCP 伺服器只看得到使用者的身分，無法分辨呼叫方究竟是代理、Alice 的 CLI，還是其他工具。

MCP 伺服器往往包裝在既有基礎設施之外——內部 API、資料庫、對代理不友善的外部系統——而且必須同時替許多使用者行事。單一使用者的 PAT 範圍太窄，於是維運人員轉而使用服務帳戶，結果服務帳戶變成許可權的集散地。Potrec 指出這並不新鮮：這與傳統 SaaS 的服務對服務通訊如出一轍。真正新鮮的是，代理並不是確定性的軟體。

他舉的發票例子，把歸屬問題的缺口具體化了。代理被要求檢視一張近期發票，拿回來時上頭標著「待處理」，接著——不論是出於惡意，還是因為它「實在太熱心」——它決定把這張發票寄給某個使用者。沒有人能判斷這究竟是 Alice 提出的要求，還是代理自己的決定。

憑證散亂造成四種截然不同的失效模式

Potrec 一一列舉當前情況的問題所在，這份清單是全場演講中最清楚的診斷：

他把業界過去的容忍態度定調為一場經過盤算的賭注：在代理出現之前，大家假設安全性由開發者以安全的方式交付軟體來處理，並接受了這樣的風險。代理打破了這個假設，因為如今有第二個行為者能代替使用者行事。他的比喻是：每家公司都玩過那種遊戲——找到同事沒鎖的筆電，然後在 Slack 上發「今天我請大家吃甜甜圈」。人們後來學會了鎖螢幕。他說，代理則是無時無刻不在上演「沒鎖筆電」的戲碼，而且用的還是使用者的憑證。

OAuth 加上工作負載身分就是答案，而且這套模式早已存在

Potrec 的處方，是別再讓使用者自己去翻找存取 Token——他稱之為糟糕至極的使用者體驗——改由代理對外說明該如何取得存取權，把使用者端向外部系統請求授權的能力一併嵌入。這麼一來，就能產生針對特定互動範圍、僅限使用它的那個工具、並在互動結束時即失效的動態憑證。他指出，OAuth 本來就在做這件事。

另一半，是讓代理在取得任何憑證之前先完成認證。他點名工作負載身分聯邦（workload identity federation）、私鑰認證、憑證，以及以 URL 為基礎的授權，並表示用哪一種機制並不重要，重點是要用。代理完成認證後，同樣的模式會再重複一次：代理不再授予服務帳戶長期許可權，而是先判斷遠端服務需要什麼授權，取得針對該次互動的 Token，然後繼續執行。

他的關鍵簡化是：把推理迴圈拿掉，代理就只是軟體。因此傳統軟體與代理可以共用同一套模式，整個技術堆疊都能用這種方式重新實作。

規模把一套乾淨的模式變成四個棘手難題

Potrec 自問為何以前沒人這麼做，並以規模作為答案。世上沒有單一的 API——而是有數百個，每個都以不同方式認證使用者，各自背後還有自己的授權伺服器。先前圖上只有一個區塊可以對之授權，如今使用者端卻得橫跨數百個服務來完成。代理的型別也不只一種：有些是買來的，有些是自己打造的（他舉 Claude Code 為例），還有些根本無法修改。此外也沒有單一的樞紐，因此代理之間的委派流程必須被持久化並驗證，包括中間究竟串了幾個樞紐。最難的問題是歸屬：成千上萬的使用者必須對代理採取的各種任意行動表示同意。

由此他推匯出一套可用系統的必要條件：

• 代理身分：依每個代理——甚至可能是每個工作階段——核發，並與啟動該代理的人分開。
• 委派語意：表達哪些使用者可以透過哪些代理行事，以及哪些代理可以代表其他使用者行事。
• 具範圍、短效期的憑證：每一次行動都適用，且任何地方都不得存在萬能主金鑰。
• 聯邦式信任：橫跨既有的上百個系統，因為它們不可能全部重寫。
• 自適應仲介（broker）：即時且安全地交換舊有憑證，因為傳統軟體會無限期地存在下去。
• 政策：明訂哪些行動需要人工核准、哪些代理可以自動執行。
• 稽核：記錄每一筆請求由誰授權、又是誰促成的。

接著他走過一次單一的代理對 MCP 伺服器互動，說明其中牽涉多少工作：伺服器公佈資訊、使用者端探索資訊、代理取得憑證並向伺服器完成認證、伺服器驗證簽章、確認簽發者可被信任、驗證 Token、套用並強制執行當下政策、可能還要再取得憑證以觸及外部系統，並且把每一步都記錄下來。他請現場舉手錶決 LLM 是否每次都能完美做到這些，並表示全場一致認為做不到。

SDK 行不通，因為代理會持續存在，而憑證始終搆得著

Potrec 承認，業界過去確實用共用函式庫、中介軟體，以及寫一次、經較大群體審查、再重複使用的 SDK，解決過類似問題。接著他列出 SDK 在此行不通的原因。採用必須全面普及，只要出現缺口，SDK 就形同廢物。SDK 必須為環境中每一種語言各寫一份，而 LLM 擅長其中一些，但恐怕不是全部。你無法修改的程式碼——他提到 codec——根本搆不著。一旦有 bug，就得修 SDK，然後再逐一追查每個曾使用它的系統。

前四個問題在代理出現之前就已存在。新的問題出在行為面：代理行事樂觀、可能被操縱，而且「在試圖繞過我們的控制上，已被證明非常堅持」。使用者端程式碼可以妥善快取並儲存憑證，但若代理在自己的執行環境裡找到憑證，那就是個問題。SDK 也無法對代理隱藏憑證。他說，設計目標就是讓每一個 Token 都搆不著代理。

閘道換來撤銷與衰減，但得付出代價

這套架構把憑證移入安全隔離區——一個負責儲存與仲介憑證的執行期授權系統或保管服務——並讓代理流量全數經過閘道。代理向閘道要求特定目標（例如 GitHub）；閘道認證呼叫方、諮詢授權伺服器、驗證政策、取出憑證、注入請求，然後轉發出去。Potrec 的主張是，這創造了一層實體控制：除非代理以確定性的方式攻擊閘道或授權服務，否則根本沒有路徑能碰到憑證。

flowchart TD
    A["代理"] -->|"請求目標，例如 GitHub"| B["閘道"]
    B -->|"呼叫方是誰"| C["執行期授權服務／保管庫"]
    C -->|"政策檢查、具範圍憑證"| B
    B -->|"注入憑證"| D["下游服務，例如 GitHub"]
    B -->|"每筆請求皆記錄"| E["稽核日誌"]

除了隱藏機密之外，他認為閘道還帶來三項好處。撤銷變得即時，因為閘道會即時檢查每一筆請求——短效期 Token 仍得等時鐘到期，而分散式系統之間的撤銷至今仍是未解難題。請求衰減也變得可行：許多舊有服務只提供管理、讀取或寫入許可權，但能檢視請求內容的閘道，可以允許讀取郵件卻擋下寄送郵件。可觀測性也提升了，因為閘道就坐在網路路徑上，不必更動下游服務就能看到每一筆請求。

代價同樣講得明白。它多了一層網路跳躍與延遲。唯有靠強力的網路控制把代理逼進閘道，它才行得通。它對本機工具執行毫無作用。它不解決身分問題——代理仍需要憑證才能向閘道認證。它把所有憑證集中到單一目標背後，等於引誘攻擊。橫跨眾多系統的 TLS 攔截在技術上很困難。而且在分散式系統中，開發者仍得在每個閘道上設定路由、政策與聯結器，還得有人明確規定代理 A 是否可以透過它觸及代理 B。此外，還得有人負責維運它。

Keycard 押注的是共用控制平面，而非單一產品

Potrec 把 Keycard 定位為解決重複建置問題的答案：單一控制平面，負責核發代理身分並與既有系統聯邦、對所有請求提供政策與稽核、提供用於注入與探索的使用者端 SDK、提供處理認證的服務端 SDK，並為想要這些控制的團隊提供閘道。他強調，客戶可依自身是打造聊天應用還是完整協作平臺，自行挑選所需元件，而 Keycard 對使用情境「相當不預設立場」。

他最後的建議是全場最值得引述的一段：

「代理認證已經不再是選項。沒錯，我們幾十年來勉強在沒有它的情況下活了下來。但代理最近已經證明，它們不能被信任。」

他補充，現實很混亂，任何打造這些元件的人都該採用開放標準並保持互通，因為「我們不可能靠單打獨鬥贏得這場遊戲」；團隊也不該「YOLO 硬上」——LLM 不會正確落實這些機制，所以用來強制執行這些控制的程式碼本身，也必須接受安全檢查。他請聽眾到攤位，並造訪 agentbaseline.org——他說那裡收錄了近期釋出、涵蓋上述能力的軟體工廠參考實作。

尚未化解的張力，正是 Potrec 點出卻未解決的那一個：閘道集中了控制，也集中了風險；而政策層仍得靠人工為成千上萬名使用者撰寫規則，去同意代理的各種任意行動。他的答案——開放標準、聯邦、稽核——是一個方向，而非完成品，這也與一場請聽眾把剩餘問題帶到攤位上的廠商簡報相符。