2026 年 9 月初,fosrl 在 Hacker News 上发布了 Pangolin 的全新模块——一个用 WireGuard 隧道替代传统 API Key 来认证 LLM 调用的 AI Gateway。Pangolin 本身并不是新项目:它在 GitHub 上已经有 22,718 stars,定位是"现代网络与安全平台,提供应用、基础设施、AI 工作负载的安全访问与连接"。这次发布的是它面向 AI 场景的关键扩展——不再用 OpenAI / Anthropic 那种 static bearer token 鉴权,而是让每个用户通过桌面客户端登录企业 IdP(Okta、Azure AD、Google Workspace 等),自动建立一条 WireGuard 隧道回到 AI Gateway;网关凭借 WG peer header 识别用户身份,用户调用 Claude / GPT / 自建模型时全程不需要任何 key。这条设计的工程意义在于,它正面回应了过去 18 个月里整个 AI Agent 安全讨论里反复出现的一个核心痛点——Agent 调用 LLM 时的凭据到底应该放在哪里、谁来管理、泄漏了怎么办。Pangolin 的答案是:凭据根本不出现。身份是网络层的,不是应用层的;鉴权是隧道级的,不是 token 级的;模型调用从用户桌面的 WG 隧道进入网关,网关已经知道对面是谁。这是一条把"零信任网络访问"(ZTNA)思想延伸到 AI 工作负载的具体工程实现,也给企业级 Agent 平台提供了一个全新的凭据治理基线。
## 一、传统 AI Gateway 的凭据困境:为什么 API Key 是 Agent 时代的隐患
在 Pangolin 之前,几乎所有 AI Gateway 的设计都建立在一个简单假设上:用户拿一个 OpenAI / Anthropic 颁发的 API Key(或 Gateway 自己颁发的虚拟 key),Gateway 用这把 key 去鉴权上游模型,记录用量,做 budget 限制。这套设计在 LLM 时代的早期还能用,因为只有少量开发者在使用 API;但到了 2025-2026 年 Coding Agent / Computer Use Agent / 办公 Agent 大规模铺开的阶段,它暴露出了至少四个具体隐患。
第一个隐患:Key 必然出现在 Agent 的代码、配置文件、prompt 上下文里。Coding Agent 几乎一定会在某个时点把 API Key 写进 `.env`、写进 shell history、写进自己给自己写的 prompt 里。一旦出现这种情况,Agent 自身就被 prompt injection 攻击者盯上了——任何能让 Agent 把自己的 environment 复述出来的 prompt,都能成为 API Key 泄漏的攻击向量。OpenAI 在 2026 年 8 月的 Agent Message Board 事件里,被独立审计发现"智能体的工具调用轨迹里有 7% 被伪造",Key 出现在 Agent 上下文里几乎等于"必然会被某种形式的提取攻击盯上"。
第二个隐患:Key 轮换很难落地。理论上所有安全指南都建议"定期轮换 API Key",但实际操作里几乎做不到——Coding Agent 已经在使用 Key,轮换 Key 必须所有 Agent 同时停机、批量替换、重启,而且轮换期间旧 Key 不能立即吊销,否则正在跑的 Agent 会突然失败。这种"必须全停才能换"的机制让 Key 轮换在生产环境里近乎不可能。
第三个隐患:Key 一旦泄漏,无法精确定位"是谁泄漏的"。OpenAI / Anthropic 颁发的是一把全局 key,所有用这把 key 的客户端都共享同一个身份。如果这把 key 被贴到 GitHub commit、被分享到 Slack、被打包进 docker image,事后追责只能看到"这把 key 在某个时间被某个 IP 用过",无法反推到具体个人。这与企业 IdP 提供的"每个用户、每次会话、每个动作都精确定位"的审计能力形成鲜明对比。
第四个隐患:自建/On-prem 模型无法用同一套凭据体系接入。当企业有自建模型(例如内网 DGX Spark 上的开源模型)时,通常的做法是给自建模型单独签发内部 API key、与公有云 key 分别管理——结果是用户要记两套 key,运维要维护两套轮换流程,审计要交叉对比两套日志。Pangolin 的 HN 发布里特别指出:"This tunnel-based approach also means self-hosted and on-prem models aren't an afterthought bolted onto the gateway. They work the same way public cloud models do."
## 二、Pangolin 的核心机制:WireGuard 隧道 + SSO = 无 Key 鉴权
Pangolin 的 AI Gateway 模块在工程上做的事并不复杂,但每一步都精准踩在"凭据治理"这个痛点上。它的运行机制大致是这样的(参考维护者 @oschwartz10612 在 HN 评论里的技术说明)。
第一步:用户在桌面应用里登录企业 IdP。Pangolin 的桌面客户端支持 OIDC 协议,可以对接 Okta、Azure AD、Google Workspace 等主流身份提供商。用户登录后,桌面客户端拿到一个 IdP 颁发的 token,该 token 用于与 Pangolin Gateway 建立受信任的控制面连接。
第二步:控制面连接 + WireGuard 公钥交换。桌面客户端通过 WebSocket 与 Pangolin Gateway 建立命令与控制(C2)通道——这条通道用用户 IdP token 鉴权。客户端把自己的 WireGuard 公钥通过 C2 通道发给 Gateway;Gateway 为这个用户动态创建一个 WG peer 配置;客户端的 WG 握手完成,形成一条从用户桌面到 Gateway 的加密隧道。
第三步:DNS override + 隧道内 DNS 解析。桌面客户端建立隧道后,会接管用户机器的 DNS——所有 DNS 查询都进入隧道。Gateway 在隧道内提供 DNS 解析:如果是网关范围内的资源(如 `api.openai.com`、企业内 `llm.internal`、自建模型 endpoint),由 Gateway 直接给出 IP;否则把请求转发到公网 DNS。这一步是把"模型调用请求"与"普通互联网请求"区分开来的关键——所有走模型的请求都会落在 Gateway 控制的 IP 段里。
第四步:模型调用 = 隧道内请求 + WG peer 身份识别。用户在桌面客户端里用 Claude Code / Cursor / 任何 Agent 框架发起模型调用时,请求会通过 override DNS 解析到 Gateway 的 IP。Gateway 收到请求后,不需要读任何 HTTP header 里的 token,只靠 WG 包头识别这是哪个 peer 的流量,然后把请求路由到对应的上游模型(公有云或自建)。网关日志里记录的身份是"这个请求来自 WG peer X",而 peer X 在 Pangolin 控制面里关联的是某个 IdP 用户。
这套机制的核心工程创新在于把鉴权从应用层下沉到网络层。传统 AI Gateway 在 HTTP 层做鉴权(读 Authorization header),而 Pangolin 在 WireGuard 层做鉴权(读 WG packet header)。前者的弱点是"凭据会在 HTTP 请求里出现",后者的优点是"凭据根本不出现"——用户桌面的 Agent 进程从生到死都不会看到任何 OpenAI/Anthropic key,因为它压根不需要用 key 去鉴权,鉴权在它看不到的网络层已经完成了。
## 三、对企业 AI 治理的真实工程启示
把 Pangolin 的设计与传统 API Key 模式、虚拟 Key 模式、传统 ZTNA 模式做一个四向对比,可以提炼出几条对企业 AI 治理非常有用的工程启示。
启示一:凭据治理不能停留在"如何管 key"这个层面。传统思路是"key 怎么生成、怎么存、怎么轮换、怎么审计",这些都是必要但不充分。Pangolin 模式直接消除了"key"这个对象本身——这是一个更激进的工程方向。任何依赖密钥、token、证书的应用层鉴权,在面对规模化 Agent 部署时都会遇到"凭据泄漏面"的问题;真正可持续的解决方向是把鉴权下沉到网络层、硬件层、生物特征层等"用户不可见也不可泄漏"的层面。
启示二:身份必须是企业 IdP 级别的,不能是 AI Gateway 自己签发的。Pangolin 通过 OIDC 把企业 IdP 作为唯一身份源,这样用户身份与企业内所有其他系统(Slack、Jira、AWS Console、GitHub Enterprise)共享同一套治理。如果 AI Gateway 自己签发"虚拟 key",无论起名多花哨,都绕开了企业的统一身份治理——审计、合规、离职交接都会出现断层。
启示三:自建/On-prem 模型与公有云模型必须使用同一套鉴权机制。Pangolin 通过 WG tunnel connector 把内网模型拉到同一隧道里,用户视角下"切模型"等于"换 endpoint",但凭据体系不需要切换。这条对应到企业 AI 治理的核心需求:内部团队不应该因为模型是自建的就额外承担一套凭据管理负担。
启示四:桌面客户端 + 隧道模式可能不适合所有 Agent 类型。Pangolin 的模式天然要求用户有一台桌面/笔记本(可以装客户端、可以跑 Agent 进程),这条对人类开发者很合适,但对"Agent 跑在服务器上、API 被另一个系统调用"的场景就不合适——服务器进程没有"桌面客户端"可装,需要的是反向网关模式。这种局限在企业 Agent 平台建设时必须考虑:对开发者友好 ≠ 对所有场景友好,Pangolin 模式适合第一公里(开发者本地),但 Agent 平台必须为生产部署另备一套鉴权方案。
启示五:网络层鉴权需要清晰的"信任域"边界。WG peer 身份识别成立的前提是"Pangolin Gateway 控制的所有 WG peer 都是可信用户"——如果企业内部有一台不可控的笔记本也接入了隧道,Gateway 就会信任这台笔记本上的所有请求。所以 Pangolin 模式在企业内部必须有"哪些设备可以加入隧道"的强制策略(类似 ZTNA 里的 device posture check)。这一条在传统 ZTNA 解决方案里很成熟,但在 AI Gateway 领域还比较新。
## 四、与 OWASP ASI03 Identity & Privilege Abuse 的对位
把 Pangolin 的设计与 OWASP Agentic Top 10 里的 ASI03 Identity & Privilege Abuse 威胁对照,可以更清楚地看到这条设计的工程价值。ASI03 关心的是"Agent 继承或越权获得超过用户授权的权限"。传统的 API Key 模式下,Agent 拿到的 key 可能是高权限 key(例如公司购买的 OpenAI 组织 key),这把 key 本身没有"用户身份"的语义——任何拿到 key 的进程都能以"公司"的身份调用模型,无法精确定位"是公司里的谁"。
Pangolin 模式直接把"用户身份"绑进了网络层——WG peer 与 IdP 用户是 1:1 绑定的,Gateway 看到的每一次模型调用都能精确追溯到具体个人。这条对位与微软责任矩阵里"Agent identity and delegated token management"完全对应:在 IaaS/PaaS 模式下,这项责任完全或部分由客户承担;Pangolin 模式提供了一个开箱即用的"客户身份 + 网关鉴权"解决方案,直接减轻客户的实施负担。
更重要的是 ASI09(Human-Agent Trust Exploitation)与 ASI10(Rogue Agents)这两条 OWASP 威胁——它们分别关心"Agent 冒充人类"和"未授权 Agent 在环境中行动"。传统 key 模式下,这两种威胁都很难被网关层检测——key 是 bearer token,网关无法判断调用 key 的到底是合法 Agent、Agent 的 prompt injection 受害者,还是攻击者直接盗用了 key。Pangolin 模式通过"网络层身份"补上了这个缺口:WG peer 是物理设备级别的,不可被 Agent 进程随意复制;攻击者即使拿到了 Agent 的所有代码和环境配置,也无法把流量伪造成从某个特定设备发出。
## 五、零信任思想向 AI 工作负载的延伸
Pangolin 这套设计在更宏观的视角下,代表了零信任网络访问(ZTNA)思想向 AI 工作负载的延伸。ZTNA 过去十年的核心思想是"不信任任何用户/设备/网络位置,每次访问都要重新鉴权"。在传统 IT 场景里,ZTNA 解决的是"用户从咖啡馆连回公司内网"的安全问题;到了 AI 时代,核心问题变成了"Agent 调用模型时,谁能以谁的身份、调用哪些模型、用多少预算、做多少动作"。
Pangolin 把 ZTNA 的关键能力——基于身份的细粒度访问控制、动态 peer 配置、设备级别身份、最小权限隧道——完整搬到了 AI Gateway 场景。用户在桌面上登录 IdP,触发 ZTNA 风格的"动态鉴权 + 动态授权";Agent 进程发起的模型调用,在网络层就被 ZTNA 机制识别为"来自该用户设备的合法请求",并由 Gateway 强制实施"该用户能调哪些模型、能用多少 token"的策略。
这条 ZTNA → AI Gateway 的延伸,在企业 IT 治理史上其实是一个非常自然的演进。从 VPN 到 ZTNA 是"信任网络"到"信任身份"的转移;从 API Key 到 WG tunnel 是"信任 token"到"信任设备身份"的转移。两次转移的本质都是把"信任的根"从一层容易泄漏的中间层下沉到一层更难伪造的基础层。VLAN / 防火墙时代的信任根是网络位置(可信 IP 段);API Key 时代的信任根是 token 字符串;ZTNA 时代的信任根是用户身份 + 设备身份;Pangolin 模式的信任根是"用户在 IdP 里登记的设备 + 该设备的 WG 私钥"。
## 六、对开源生态与 Agent 平台的具体影响
Pangolin 这次发布对整个 AI Agent 开源生态有几个具体的影响。
第一,"无 key 鉴权"成为 AI Gateway 的新基线。任何还在用"用户提交 OpenAI key 给我们管理"模式的 AI Gateway,都将在 2026 年下半年开始面对"凭据泄漏面"的合规质询——尤其是在企业市场,合规审计会直接问"你们的 key 存在哪、谁有权看、泄漏了怎么定位用户",传统模式回答不出这些问题。Pangolin 模式提供了一套可以参考的实现样本,后续会有更多 Gateway 跟进。
第二,OIDC 集成成为 AI Gateway 的必备能力。Pangolin 把 Okta、Azure AD、Google Workspace 作为一等公民身份提供商,而非可选附加功能。后续任何要做企业市场的 AI Gateway,都必须在核心架构里支持 OIDC,而不是把"虚拟 key"作为主路径。
第三,自建模型与公有云模型在网关层被强制统一。Pangolin 通过 WG tunnel connector 把企业内部 DGX Spark、自建 LLM 集群、内网推理服务统一拉到同一隧道,让用户在切换模型时不需要切换凭据体系。这条能力对企业 IT 的意义是:"用自建模型"不再是一个需要单独治理的边界场景,而是与公有云模型同等的一等公民。
第四,Agent 自身的凭据治理有了新的工程选项。Agent 不再需要去取 key、藏 key、保护 key;Agent 只需要发起模型调用,由网络层的 WG 隧道自动完成鉴权。这条对 Coding Agent / Computer Use Agent / 办公 Agent 三类主流 Agent 都适用——任何把 API Key 暴露在 Agent 进程内的设计,都可以借由 Pangolin 模式被消除。
回到 HN 发布那条自我描述:"That tunnel is the auth, so there is no key to generate, embed, rotate, or leak, because the gateway already knows who's on the other end of the connection"——这句话其实点出了 2026 年下半年企业 AI 治理最重要的工程转向之一:把鉴权从"应用层 token 字符串"下沉到"网络层设备身份",把凭据治理从"key 管理"推进到"key 不存在"。Pangolin 不是第一个提出这个思路的项目,但它把这条思路在 AI Gateway 场景里做到了可自托管、可对接企业 IdP、可同时覆盖公有云与自建模型的完整形态。对所有在认真做企业级 Agent 平台的团队来说,这套设计都值得被摆在"凭据治理"那一章的开篇位置。
