Every major AI provider hands you a string of characters and calls it an API key. You paste it into your environment file, your CI pipeline, your third-party integration — and from that moment, it sits there quietly, holding more blast radius than you probably intended.
The Four Problems With Raw API Keys
At Yoosh we spent several months watching how teams actually use API keys before we wrote a single line of Card infrastructure. What we found was not a security problem in the narrow sense. It was a control problem — teams had no language for expressing intent when handing out access.
No identity
A raw key has no name attached to it at the credential layer. You might add a comment in your notes or a label in the provider dashboard, but those labels are advisory — they do not travel with the key and they are not machine-readable. When an alert fires at 2 AM, you cannot tell which project or teammate triggered it from the key string alone.
No budget
A runaway loop, a misconfigured agent, or a prompt that accidentally triggers recursive calls can exhaust thousands of dollars overnight. Providers offer account-level spend limits, but a single limit shared across all your integrations is a blunt instrument. You cannot say "this research key should never spend more than 20 SOL this month" without building that logic yourself.
No revocation granularity
When a key is compromised, your only option is to delete it. If ten services share that key, all ten go down simultaneously. Teams working around this problem either create one key per service (hard to audit) or accept the downtime risk (hard to defend).
No model scoping
A standard API key can call any model the account has access to. A key meant for a lightweight summarization task can, by accident or by attack, be used to invoke the most expensive model in your tier. There is no mechanism to say "this key may only reach these models."
How Yoosh Cards Solve Each Problem
A Yoosh Card is issued on-chain as a lightweight token scoped to your wallet. Under the hood it resolves to a credential that Yoosh's routing layer accepts — but it carries structured metadata that a raw key cannot.
Named cards
Every Card has a human-readable name you set at creation time, for example
gpt-production or research-claude. That name is
indexed in your dashboard, appears in every usage log line, and is filterable
in real time. When an alert fires, you know within seconds which Card was
active — no lookup required.
Monthly SOL cap per card
You set a spending ceiling in SOL when you create or edit a Card. The Yoosh routing layer enforces this cap at the request boundary — not post-hoc. A request that would exceed the cap is rejected before it reaches the model provider. Caps reset on the first of each calendar month or on a custom cycle you define.
Independent revocation
Each Card is an independent credential. Revoking research-claude
has zero effect on gpt-production. You can suspend a Card, rotate
it, or permanently burn it — all without touching the others. This makes
incident response surgical rather than catastrophic.
Model group whitelisting
At Card creation you specify a model group: economy, standard, or frontier. A Card in the economy group cannot route to frontier models, regardless of what the calling code requests. This is enforced server-side by the Yoosh routing layer, not by client-side logic that can be overridden.
Side-by-Side Comparison
The table below summarizes where a raw API key leaves you exposed and what a Yoosh Card provides in its place.
| Dimension | Raw API Key | Yoosh Card |
|---|---|---|
| Identity | — | Named + indexed |
| Budget control | — | Monthly SOL cap, enforced at edge |
| Revocation | — | Per-card, zero blast radius |
| Model scope | — | Whitelist by model group |
| Audit trail | — | Per-card usage log, real-time |
What This Looks Like in Practice
A typical Yoosh user creates three to five Cards for a production application: one for the user-facing chat path, one for background summarization, one for internal tooling used by engineers, and sometimes a short-lived Card for a one-off experiment. Each has its own cap and model scope. The experiment Card is burned when the experiment ends. The chat Card has a conservative monthly ceiling. The internal Card is restricted to economy models.
When usage spikes unexpectedly, the dashboard makes it immediately clear which Card is responsible — not which account. That specificity is the difference between a five-minute diagnosis and a two-hour postmortem.
A Card is not just an API key with a name. It is a contract between you and the model — scoped, budgeted, and revocable.