LangSmith Auth Proxy：如何保障AI代理沙箱的網路安全性

在企業環境中，標準筆記本通常配備端點保護、瀏覽器過濾、裝置管理、網路控制和金鑰掃描等安全工具，以防範開發者意外洩露憑據或安裝惡意軟體。這些措施之所以必要，是因為開發者擁有廣泛許可權——他們執行程式碼、安裝依賴、在系統間複製資料，並認證到內部和外部服務。如今，AI代理將這一問題的規模和形態提升到了新高度。你可能不再只是給一個開發者提供筆記本，而是需要同時管理成千上萬個“不受信任的開發者”——這些代理可以代表你編寫程式碼、執行命令、安裝軟體包併發出網路請求。

對於人類開發者，環境通常預設保持開放，因為他們需要探索、除錯和安裝工具。但對於代理，預設策略可以完全不同。如果任務已明確，網路訪問範圍可以大幅收窄。例如，若代理僅需訪問GitHub和某個LLM提供商，它就不應能連線任意網際網路主機。如果需要憑據，該憑據甚至不應存在於執行時內部。這就是沙箱網路成為代理基礎設施一等公民的原因。

LangSmith沙箱為代理提供了隔離環境來執行程式碼和操作檔案系統，不影響主要基礎設施。但隔離只是第一步，代理仍需呼叫外部API——模型提供商、GitHub、軟體包倉庫、內部服務等。沙箱認證代理（Auth Proxy）正是為了控制代理行為與外部世界之間的邊界而設計。

其工作原理如下：代理或沙箱程式碼發出出站請求，請求透過Auth Proxy；代理檢查針對該目標配置的策略；代理可以阻止請求、允許請求或附加頭資訊；然後請求繼續到達目標，而憑據從未暴露給執行時。例如，一條簡單規則可以是：當沙箱呼叫api.openai.com時，注入包含LangSmith工作區金鑰的Authorization頭。另一條規則可以是：針對api.github.com的特定路徑注入GitHub令牌。

這種模型帶來了三大好處：第一，憑據不必進入執行時。代理可以呼叫API，卻無法讀取API金鑰，從而降低了提示注入、惡意依賴、意外日誌記錄和模型錯誤造成的損害。第二，網路訪問明確化。如果代理只能與特定服務通訊，這應作為基礎設施策略編碼，而非交由代理判斷。第三，團隊獲得更清晰的關注點分離：代理聚焦任務，沙箱提供隔離，代理處理網路授權和憑據注入，應用或認證服務管理使用者級訪問和令牌重新整理。

Auth Proxy支援多種策略配置，其中最重要的能力是根據請求特徵注入頭資訊。頭資訊型別包括：workspace_secret（引用LangSmith工作區中儲存的金鑰）、plaintext（原樣儲存返回，適用於非敏感頭）、opaque（只寫，加密儲存，API從不返回）。沙箱程式碼無需知道API金鑰，無需.env檔案，無需將金鑰掛載到檔案系統。它只管呼叫API，代理根據匹配規則自動新增正確頭資訊。

憑據只是網路問題的一半。代理還需出口策略，因為它們可能安裝依賴、抓取指令碼、呼叫API，並遵循不受信任內容的指令。如果每個沙箱都有開放網際網路訪問，被攻破或混亂的代理可能到達不應訪問的位置。同一個代理邊界也能成為團隊定義預期目標的地方：允許模型提供商API而阻止其他一切；允許代理所需的GitHub API路徑但不允許任意GitHub相鄰域名；允許某個包倉庫但僅限於內部映象；阻止已知惡意或不受信任的包倉庫；防止意外呼叫未授權的第三方服務。對於包管理尤其重要，因為如果編碼代理可以執行pip install、npm install或curl | bash，它就能獲取並執行程式碼。安全問題不僅在於沙箱能否容納執行，更在於能否控制程式碼來源和資料傳送目的地。

對於更高階的用例，靜態配置可能不夠。LangSmith Fleet中的代理可能需要委派訪問和OAuth令牌重新整理，同時仍將實際憑據處理置於代理執行時之外。其他高階場景包括：短生命週期的OAuth訪問令牌、每個使用者作用域的令牌、由內部認證服務生成的憑據、需要根據目標或當前使用者上下文重新整理的令牌。針對這些情況，Auth Proxy支援帶回撥的動態憑據。你在proxy_config下配置一個回撥端點；當沙箱向匹配主機發出請求且代理沒有快取憑據時，代理呼叫你的回撥端點，傳入目標主機和埠；你的端點返回要注入的頭資訊，代理在配置的TTL內快取結果。回撥返回一個簡單的JSON物件，代理將其頭資訊注入出站請求。如果回撥失敗、返回格式錯誤的JSON或非2xx狀態，代理將關閉失敗並拒絕沙箱請求，而非不加憑據地傳送請求。這使沙箱網路層能夠參與認證流程，而無需向沙箱暴露重新整理令牌或長期憑據。

一旦控制了沙箱網路路徑，代理就能超越憑據注入，向幾個自然方向擴充套件：DNS重對映——團隊可將公共包倉庫請求解析到內部Artifactory或包映象，或將LLM API請求指向內部閘道器；網路日誌——代理活動成為代理行為的審計軌跡；請求轉換——代理可以對出站請求應用確定性轉換，例如編輯PII、新增組織後設資料、強制請求形狀或阻止違反策略的負載。

更廣泛的觀點是，代理基礎設施需要位於執行時之外的控制平面，不暴露給代理指令和決策。Auth Proxy為沙箱代理提供了更安全的預設設定：將憑據保留在環境之外，透過受控層路由出站流量，並跨語言、SDK、包管理器和CLI一致應用策略。結果是代理獲得了所需系統的訪問權，同時憑據和網路策略始終處於平臺控制之下。