Why Ranbval exists in an era of leaking API keys
Manifesto · 6 min read · Published 2026-04-06 by Ahsan Tariq
A founder note on why control over credentials is a product, not a checkbox.
Ranbval exists because API keys cannot keep living in plaintext. Every week a new AI provider ships a model you want to try. Your teammate drops the API key in a Slack DM. A junior developer pastes it into an online sandbox to debug. A week later the bill is five figures higher and nobody can trace where the key first leaked. The industry has normalised this. Keys live in .env files, CI variables, laptops, and the one shared password manager that everyone forgot to rotate last quarter. Ranbval was born out of frustration with that pattern — a product-sized answer to a problem that has been treated as someone else's ops problem for too long. Ranbval is designed for the person who still touches code — founders, indie hackers, platform engineers, and small security teams. The Ranbval SDK looks and feels like the provider's own client, but the trust model is flipped: you never hold the raw key; the SDK does, only for as long as it needs to. Our thesis: if decrypt-in-memory, scoped telemetry, and repo-bound policy become the default, a whole category of incidents disappears — without anyone becoming a cryptographer. Ranbval closes the gap between 'we store it encrypted' and 'nothing in your stack ever sees the plaintext key'.
