共用 API 金鑰與服務帳戶會抹去個別代理程式與請求發起者之間的區別。日誌只會顯示憑證，無法辨識代理程式，也看不出是哪位支援工程師代表客戶行事。規模小時，這只是造成不便；到了企業規模，卻可能引發重大風險。無法歸屬來源的帳務、病歷或基礎架構變更，會造成合規缺口、增加事件鑑識難度，還會迫使團隊採用權限過度寬鬆的政策，進一步提高風險。

多代理程式工作流程通常會經過協調器、工具代理程式與 MCP 伺服器。若沒有身分傳遞，最終系統只能選擇信任中介者，或拒絕請求。當下游系統信任原始權杖時，Agent Identity 支援權杖直通；代理程式必須以自身身分行事時，則可使用 OAuth2 用戶端憑證；此外也支援 OBO 交換，產生代表「代理程式代使用者行事」的權杖。如此一來，記錄系統便能套用正確的個別使用者權限，且不必修改代理程式。

身分必須能用於實際控管，才真正有價值。TrueFoundry 為每個代理程式設定允許清單（使用者、團隊、應用程式及其他代理程式），並管理其對模型、MCP 伺服器與服務的對外連線權限。撤銷授權後，閘道會立即回傳 403。將這些控管集中管理，可避免在代理程式中重複實作脆弱的存取邏輯，並提供單一位置，讓團隊能在規模或風險變化時稽核、撤銷及收緊權限。

TrueFoundry 支援多種身分模式：可使用 TrueFoundry 簽發的權杖快速完成導入，也可採用由 IdP 支援的身分，並對應至 Okta、Entra 或任何 OIDC 提供者中的 subject 宣告。此外也支援 AWS 工作流程的 SigV4 簽署。代理程式無論部署於何處，都能納入治理：透過代理的代理程式可進行傳入政策控管，嵌入式代理程式則可進行輸出治理。這表示團隊可以分階段推行，先註冊高風險代理程式，再逐步擴大涵蓋範圍，無須重新設計部署架構。

在閘道集中管理身分，也會讓風險集中：權杖交換、快取與撤銷都會成為關鍵基礎架構。請預期需要增加營運工作，例如監控權杖生命週期、擴充閘道，以及強化交換流程的安全性。同時也要評估 OBO 流程與 SigV4 簽署在高負載下的延遲和故障模式。TrueFoundry 透過權杖快取、重新整理邏輯與 OpenTelemetry 追蹤處理了許多相關問題，但平台團隊仍須將閘道納入 SLO 與事件應變手冊。