Skip to content
keyforge

Privacy

The privacy story is the product. This page lists every fact about what happens to a key you paste into KeyForge.

What happens when you test a key

  1. Your browser POSTs to /api/proxy/<provider> with the key in the x-keyforge-key header. The body contains an action like validate or models; it does not contain the key.
  2. The Next.js route handler reads the key from the header, hands it to the provider adapter, and immediately discards it from local scope.
  3. The adapter calls the upstream provider (OpenAI, Anthropic, etc.) with the key in the standard auth header for that provider.
  4. The upstream response is returned to your browser. The key is not retained in any in-memory cache, queue, or log.
  5. The route handler exits. The key is unreachable.

What we do not do with your key

  • We do not log the key, the auth header, the request body, or any field that contains the key.
  • We do not persist the key to any database, file, or disk.
  • We do not include the key in error messages, OG images, share URLs, JWT payloads, analytics events, or telemetry.
  • We do not run analytics on the key value, hash the key, or aggregate keys across users.

Shareable result links

The optional "share redacted result" feature signs a JWT with the provider id, the last 4 chars of the key (for visual identification), the validation status, and a list of model ids. The full key is never in the JWT. The signing secret never leaves the server. Share links can be revoked by rotating the signing secret.

Rotation reminders

If RESEND_API_KEY is configured, you can opt into a 90-day rotation reminder. The signed JWT contains your email, the provider id, and the expiry timestamp. The full API key is never sent to the email service. We do not maintain a database of subscribers — the JWT is the only record.

Server-side logging

Vercel and any deployment platform sees the request method, path, response status, and aggregate latency. Headers — including x-keyforge-key — are not included in our application logs. If you self-host, you control the logging stack.

Browser-side storage

We use localStorage only to remember your theme preference. We use sessionStorage briefly for the paste-to-route handoff (the pasted key is stored once and immediately consumed by the destination page). We never set cookies tied to your key.

Third-party requests

The browser only talks to the KeyForge origin. No analytics, ad networks, font CDNs, or trackers. Outbound requests go from our server to the upstream provider you tested, and that's it.

Reporting a security issue

See the security page and /.well-known/security.txt for our disclosure contact.