Your API Keys Are in a .env File.

Your AI Infra Deserves Better.

Encrypted vaults, virtual credentials, provider-agnostic routing: the calling architecture your team should have built yesterday.

A few months ago, three of our team members lost API access in a single week. Claude accounts suspended. The trigger wasn’t abuse — just standard non-US dev workflow: proxies, Claude Code, the usual toolkit. One had a $200 balance frozen. Another was one day from a production deadline.

That was the spark. But as we started redesigning how our code talks to language models, we realized the real problem was much bigger than access restrictions.

Our API keys were sitting naked in .env files, passed around on Slack DMs, hardcoded in CI configs. When someone left the team, we scrambled through fifteen repos wondering where their key was still active. When we wanted to try a new model provider, someone had to touch configuration in every project. Every deployment was one stray git push away from leaking credentials.

We weren’t just vulnerable to bans. We were vulnerable to our own infrastructure.

Three layers. One clean calling stack.

1. Keys don’t live in code. They sit in an encrypted local vault — Argon2id-based key derivation. Your code declares intent (“I want this model”), never credentials. A local proxy at 127.0.0.1:27200 injects the right key at runtime. No secrets in git. No secrets in config files. No secrets leaked through a stray push.

2. Identity is decoupled from access. What you hand out to teammates aren’t raw cloud provider keys. They’re revocable virtual credentials with per-person quotas, rate limits, and model allowlists. Someone leaves the company? Revoke in under a minute. A key gets compromised? No rotation cascade across twenty projects — just swap the underlying credential, proxy handles the rest.

3. Every call is traceable. Complete audit trail: who called which model, when, at what cost. Anomaly detection catches usage spikes before they’re surprise bills. When something breaks, you locate the problem instead of staring at a suspended account page.

What changed after we built this

Adding a new model provider went from a half-day config crawl to ten minutes. Key rotation stopped being a recurring crisis. New team members onboarded to our AI stack in a single session instead of accumulating tribal knowledge about which key is in which repo.

The thing we didn’t anticipate: clean key management improved our code quality. When you never think about credentials, you write better prompts and better pipeline logic. When provider switching is trivial, you actually benchmark models instead of sticking with the first one that works.

Also — that initial problem that started all this? Provider bans stopped being existential threats. They became infrastructure events. One key down? The proxy routes to another. Two minutes, zero code changes, zero team disruption.

You should probably build something like this too

If your team uses more than one model provider — or plans to — the .env file approach has an expiration date. It works for a solo project with one API key and one developer. It breaks the moment you add a teammate, a second provider, or any meaningful operational discipline.

You don’t need our exact implementation. But you need the architecture: encrypted vault, virtual credentials, proxy-based routing, and audit trails. Build it. Steal these ideas. Just don’t keep your keys in a .env file and call it infrastructure.

Good AI infra doesn’t know where your developers are sitting. It just routes calls, injects keys, and stays out of the way.

If this architecture resonates, we’re building it at **AiKey**. Enterprise inquiries: aikeyfounder@gmail.com