Your API Keys Don't Belong in Environment Variables

Every few months, the same story plays out.

A platform you trust announces a security incident. Their recommendation to customers is some variation of: "review your environment variables and rotate anything sensitive."

The latest example, as I'm writing this, is Vercel's April 2026 security bulletin, which involved unauthorized access to internal systems and a recommendation that customers audit their stored environment variables. Vercel is handling it well, and this post isn't about them. It's about the pattern.

Because the pattern is the problem.

The pattern

Somewhere in your deployment pipeline (Vercel, Netlify, Railway, Render, Fly, Heroku, AWS Parameter Store, GitHub Actions, a dotenv file on a server) you have an environment variable named something like ANTHROPIC_API_KEY or OPENAI_API_KEY.

That value is the actual upstream key your provider issued you. It has full access to your account. It can burn through your rate limits, rack up your bill, exfiltrate your data through completions.

And it's sitting in a system you don't control.

Every platform that stores that key is a potential breach point. Not because those platforms are careless. Most are extraordinarily careful. But "securely store a secret for thousands of customers" is one of the hardest problems in software, and it fails eventually. Always has. Always will.

The real question

It's not "which platform is safest to store my API keys in?"

It's "why is my upstream API key anywhere outside my own vault?"

What good looks like

The pattern that actually works, the one used by every serious enterprise security team, is simple:

The upstream key lives in one place you control
Every app, deployment, script, or teammate gets a scoped, revocable token instead
Those tokens route through a proxy you own, which holds the real key
Compromise a token? Revoke it in one click. The upstream key never moves.

This is the same pattern banks use for card numbers, payment processors use for PANs, and identity providers use for passwords. Nobody stores the primary secret in a hundred places. They store it once, and hand out revocable references.

API keys should work the same way.

Why it doesn't already work this way

Because until recently, there wasn't good tooling for it in the AI API space. The providers give you one key, and every tool, script, CI runner, and teammate wants that key directly. So it ends up everywhere.

That's the gap Strake fills.

How Strake changes the math

Strake is an API proxy for AI providers (Anthropic, OpenAI, and others). You give it your upstream key once. It gives you back an endpoint and as many revocable tokens as you want.

Every place that used to hold ANTHROPIC_API_KEY now holds a Strake token scoped to that single endpoint. If a platform storing that token gets breached (Vercel, a CI provider, a leaked .env, whatever) you revoke the token from your dashboard. The upstream key doesn't move. You don't rotate anything with Anthropic. You don't update fifteen other places.

The blast radius of a breach goes from "rotate my production API key and update every deployment" to "click revoke."

"But isn't Strake just another place to store keys?"

Yes. And this is the right question to ask about any service that holds secrets, including mine.

Strake doesn't reduce the probability of a breach to zero. No service can. What it changes is what happens when something goes wrong, and how much surface area is exposed in the first place.

The attack surface is smaller. Strake's only job is holding one type of secret. It doesn't also run your deployments, host your code, resolve your DNS, or store a thousand other customer secrets for a thousand other use cases. Fewer features means fewer ways in. A platform that does many things has many paths to compromise. A service that does one thing has one.

The blast radius is smaller. If Vercel, Netlify, or any full platform gets compromised and your upstream API key was in their env vars, you're rotating that key with your provider, then updating every deployment, CI runner, teammate machine, and script that referenced it. That's an afternoon of frantic work minimum, more if you've lost track of where the key lives. If Strake gets compromised, you revoke all tokens in your dashboard and rotate one upstream key. That's a minute.

The architecture is narrow by design. Strake does one thing: hold an upstream API key and issue revocable tokens that route through a proxy. There's no deployment platform layered on top, no data store holding your source code, no domain system, no CI pipeline. The smaller the service, the smaller the space where something can go wrong. This isn't a claim that Strake is impervious. It's that the surface area an attacker would have to compromise is dramatically smaller than a full platform's.

Least privilege for everyone downstream. Even if you don't fully trust Strake, the apps, CI runners, teammates, and deployments that currently hold your real upstream key never need to see it again. They get scoped tokens. That's a concrete security improvement for the rest of your stack regardless of how you feel about any single vendor in the chain.

The goal isn't "trust Strake blindly." The goal is to move upstream keys out of a dozen systems that weren't designed to hold them, and into one that was, with a revocation model that works in seconds instead of hours.

What to do right now

If you're holding upstream AI provider keys in any deployment platform, CI system, or teammate's machine, you're sitting on the same risk that has bitten every other class of secret over the past twenty years. Strake or not.

A few practical steps:

Inventory every place an upstream AI key currently lives. You'll be surprised.
Audit who has access to those systems. Former teammates. Third-party integrations. CI runners.
Move to a proxy pattern. Strake, your own homegrown version, or an enterprise gateway. The specific tool matters less than the pattern.
Make key rotation a one-minute task, not a one-afternoon task. If rotating takes more than a minute, you won't do it when you should.

The last word

Security incidents will keep happening. That's not cynicism. It's just how complex systems work. The only question is whether an incident at one of your platforms means a frantic afternoon rotating keys and redeploying everything, or a single click in a dashboard you control.

That's a choice you make now, not after.