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一致应用策略。结果是代理获得了所需系统的访问权，同时凭据和网络策略始终处于平台控制之下。