Show HN: Pangolin – SSO and WireGuard instead of API keys for LLM access
github.com/fosrlYou have seen Pangolin (https://github.com/fosrl/pangolin) on here before for our open-source zero-trust network access suite of tools. We are launching a new AI gateway that takes a different approach to auth. Rather than authenticating requests to AI providers with API keys, it authenticates the network connection itself via a desktop app.
Each user gets a WireGuard tunnel back to the gateway, established after they log in through their existing identity provider (Okta, Azure, Google, etc) via a desktop app. 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. Compare that to most AI gateways, which are really just a proxy in front of static bearer tokens you'd get from OpenAI or Anthropic directly.
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. Drop a lightweight tunnel connector inside your cluster (even a DGX Spark) and it joins the same network, so on-prem models show up in the gateway next to public cloud ones. Users switch between them without changing endpoints or juggling separate credentials for internal infrastructure.
For machines or users who can't run the desktop client, we still support traditional virtual keys, plus the usual gateway features: session logging, budgets, usage analytics, and governance.
It’s fully self-hostable. Community Edition is free for everyone. Enterprise Edition is free for individuals and small businesses. There is also Pangolin Cloud which is fully hosted.
Comments
Other Pangolin maintainer here! A little more on how the WireGuard connection authenticates the connection if you are curious: the client makes a websocket connection to the server to receive command and control. That is authed with the user’s token obtained from logging in. It shares its new WG public key with the server and the server provisions a peer and the WG handshake completes. Now we have an outbound WG tunnel from the client to the server. Next the client overrides the DNS of the computer. All DNS queries make it into the tunnel where we grab them. If they are within our range of resources we give a direct reply, otherwise we send it upstream to public servers. So now we have an IP when Claude makes the request which is on the other end of the tunnel. Claude makes the request, it gets routed to the server and hits. Because we trust the WG connection packet headers on the server side we can associate this peer with an identity inside of the gateway. No key required.