Virtual Keys vs Master Key: Designing Blast Radius

Every API key is a liability the moment it leaves your control. The question isn't "will a key leak" — over a long enough horizon, one will — it's "how much can the leaked key do?" Good key design answers that with the smallest possible number. NemoRouter splits keys into two kinds with very different powers: a single master key that manages, and many virtual keys that use. The split is the whole point.

Two kinds of key, two jobs

The master key is the root of management authority; it can create and delete keys and orgs. The virtual key can do exactly one thing: make inference calls, under the limits and budget you set for it. That asymmetry is deliberate — the powerful key never travels, and the traveling keys aren't powerful.

The rule: customer traffic never uses the master key

This is non-negotiable on NemoRouter. Every LLM inference request — from an SDK, the API, the playground — authenticates with a virtual key, never the master key. Management operations (creating a key, an org) originate from server-side routes that hold the master key and never expose it to a client.

Why virtual keys make a leak survivable

Because each virtual key is independently scoped, a leaked one is a contained incident, not a crisis:

• Revoke just it. Delete the leaked key; every other key keeps working. No mass rotation.
• It was already capped. A virtual key carries its own budget and rate limits, so even before you notice the leak, the damage is bounded by the cap you set.
• You can see what it did. Per-key spend tracking means the leaked key's activity is fully attributed — you know exactly what happened.

The design turns "a key leaked" from a fire drill into a routine revoke-and-replace, because you scoped the blast radius in advance.

Display keys safely

A key you can read off a screen is a key that can be shoulder-surfed, screenshotted, or logged. So the full secret is shown exactly once — at creation — and never again. After that, the dashboard shows only a safe label: the name plus the last four characters (sk-...a1b2). There's no "reveal" button, because there's nothing to reveal — we don't store the full key in a form anyone can retrieve. Lose it, rotate it; you never get the old one back, and neither does an attacker.

Scope keys to jobs

The practical advice that falls out of this: create a virtual key per use, not per user. One key for the nightly batch, one for the chat feature, one for staging. Then:

• a leak is scoped to one job's blast radius,
• spend is attributed per job for free,
• revoking one job's key doesn't touch the others.

A single shared key for everything re-couples what virtual keys exist to separate — you lose the per-job attribution and a leak takes down all of it at once.

The takeaway

Key security is blast-radius design. Keep one powerful master key server-side for management and never let it travel; issue many narrow virtual keys for actual traffic, each capped, tracked, and revocable; show the full secret once and only the last four after. Then the inevitable leak is a contained, recoverable event — not the end of the world. Manage keys in the dashboard; they're free on every tier.