Genesis AI: A Passkey-Authenticated Proxy for User-Funded OpenAI Apps

Hook

What if you could build an AI app tomorrow without worrying about API costs spiraling out of control, while actually improving security for your users?

Context

The current state of hobbyist AI development is broken. Developers building experimental ChatGPT wrappers, productivity tools, or creative AI experiments face an impossible choice: either eat potentially unlimited API costs from users (risking financial disaster), implement complex paywall infrastructure before validating product-market fit, or tell users to paste their raw OpenAI API keys directly into text fields—a security anti-pattern that would make any security engineer wince.

This last option has become disturbingly common. Browse Product Hunt or indie hacker communities and you'll find dozens of AI tools with input fields labeled "Enter your OpenAI API key." Users copy their secret keys from the OpenAI dashboard and paste them into random websites, often with no idea whether that site is storing the key, logging it, or using it for purposes beyond the stated functionality. It's the modern equivalent of entering your password on a phishing site, yet it's become normalized because there's been no better alternative for indie developers who can't absorb API costs. Genesis AI proposes a third path: a Bring Your Own Key (BYOK) model where users securely authenticate with their API credentials through WebAuthn passkeys, and requests are routed through an encrypted proxy that never exposes keys to the requesting application.

Technical Insight

The architecture of Genesis AI is deceptively simple but clever in its layering of existing web standards. At its core, it's a reverse proxy that sits between your application and OpenAI's API servers, but the authentication mechanism is what makes it interesting. Instead of your app ever touching the user's API key, Genesis uses WebAuthn (the same technology behind fingerprint and Face ID logins) to authenticate users and associate their encrypted OpenAI keys with their passkey identity.

From a developer's perspective, integration is remarkably frictionless. After the user completes the passkey authentication flow, Genesis returns two critical pieces: a proxy baseURL pointing to their servers, and a temporary JWT token that acts as a stand-in API key. These can be dropped directly into the official OpenAI SDK:

import { genesis } from '@genesis-xyz/ai';
import OpenAI from 'openai';

// User authenticates with their passkey
const { baseURL, apiKey } = await genesis.signIn();

// Use the proxy credentials with the standard OpenAI SDK
const openai = new OpenAI({
  baseURL,  // Points to Genesis proxy, not api.openai.com
  apiKey,   // JWT token, not the user's real API key
});

// Everything works exactly as documented in OpenAI's SDK
const completion = await openai.chat.completions.create({
  model: 'gpt-4',
  messages: [{ role: 'user', content: 'Hello!' }],
  stream: true,
});

What happens behind the scenes is where the security model lives. When your app makes a request to the Genesis proxy with the JWT, their backend validates the token, retrieves the user's encrypted OpenAI API key from their database, decrypts it server-side, and forwards the request to OpenAI's actual API with the real key. The response streams back through the proxy to your application. Your code never sees the actual API key—only the JWT that's scoped to that user's session.

This proxy-based approach has a significant advantage: it works transparently with all OpenAI SDK features, including streaming responses. The Genesis proxy acts as a simple pass-through for the HTTP response stream, so server-sent events flow directly to your application without buffering or transformation. This means real-time chat interfaces work exactly as they would with direct API integration.

The authentication dependency on @passes/polyfill is telling—it suggests Genesis is either using emerging WebAuthn features that aren't universally supported, or wrapping the WebAuthn API with additional functionality for key management. This polyfill requirement means you're betting on both Genesis's infrastructure and their authentication layer remaining stable. The passkey authentication itself happens entirely in the browser using standard WebAuthn protocols, so the user's biometric data never leaves their device, but the encrypted API key must be stored on Genesis's servers to facilitate the proxy flow.

One interesting architectural implication: because all requests are proxied, Genesis could theoretically implement rate limiting, usage analytics, or caching layers without any changes to client code. They could also potentially offer features like automatic failover to alternative models or cost optimization routing, though none of this appears to be implemented in the current version. The centralized proxy is both the system's greatest strength (simple integration, invisible to the OpenAI SDK) and its Achilles heel (single point of failure, trust dependency).

Gotcha

The trust model here is critical and can't be glossed over. While Genesis never exposes API keys to your application code—which is genuinely more secure than users pasting keys into text fields—you're now trusting Genesis's infrastructure with those keys instead. Their servers decrypt and use your users' API keys for every single request. If Genesis's servers are compromised, all stored API keys are potentially at risk. If their proxy goes down, your entire application stops working. If they decide to shut down the service, implement pricing, or pivot the business model, you'll need to migrate every user to a new authentication system.

The 25 GitHub stars and limited adoption signal that this is an early-stage project. There's no published SLA, no clear business model (how is Genesis funding the proxy infrastructure?), and no visible community of production users you can learn from. The repository shows signs of active development but lacks comprehensive documentation around error handling, rate limits on the proxy layer, or disaster recovery scenarios. What happens if a user's passkey device is lost? How do they rotate their API key? These edge cases aren't clearly addressed.

Another significant limitation is the OpenAI-only support. The entire BYOK proxy concept could theoretically work for Anthropic's Claude, Google's Gemini, or any other LLM provider with an API, but Genesis currently locks you into the OpenAI ecosystem exclusively. If you want to offer users model choice or migrate to a different provider, you'll need to implement an entirely separate authentication and proxy system. For a tool positioned as solving infrastructure problems for experimental apps, this lack of provider flexibility is notably constraining.

Verdict

Use if: You're building a prototype, hackathon project, or indie AI app where you want to validate an idea without burning through personal funds on API costs, and you're comfortable with the security tradeoffs of routing traffic through a third-party proxy. This is genuinely more secure than having users paste raw API keys into your app, and the developer experience is clean enough that you can ship something in an afternoon. It's perfect for the "I want to test if anyone actually wants this" phase of product development. Skip if: You need production-grade reliability guarantees, can't accept a third-party service as a single point of failure in your critical path, require multi-LLM provider support, or are building in a regulated industry where data governance and vendor dependencies matter. Also skip if you're already at scale where you can justify the infrastructure investment of building your own auth and key management—at that point, you want the control. For most serious commercial applications, the centralized proxy dependency is too risky, but for indie hackers and experimenters, Genesis AI is a clever solution to a real problem.