Skip to main content
A credential you can read off a screen is a credential you can leak. Once you’ve copied a new key, you almost never need its plaintext again — you need to recognize it: which key is this, in which environment, is it the one the failing agent uses. OrcaRouter’s console answers that without ever re-printing a working secret: every key is rendered in a masked form that keeps just enough characters to identify it and hides the rest. This page covers what the masked form looks like, when plaintext is and isn’t shown, and how to safely mask api key values in your own logs and tooling.

​
1. Why mask api key values on display

The full key is a bearer credential: anyone who reads it can call the gateway as you, up to that key’s limits. Console views get copied into screenshots, screen-shares, support tickets, and bug reports constantly — so showing the live secret in a list of keys would turn every one of those into a credential leak. Masking solves this by separating two needs that usually get conflated:
  • Identification — which key is this? Answered by a stable, masked fingerprint you can read at a glance.
  • Use — what is the secret? Answered exactly once at creation, and behind a deliberate role-gated reveal after that.
The console satisfies the first need everywhere and gates the second, so the default surface — the keys list you stare at all day — never carries a usable secret.
A masked key is not a working credential. It cannot authenticate a request. Only the full plaintext (sk-orca-…) you copied at creation, or re-revealed through the gated endpoint, can call the gateway.

​
2. What the masked form looks like

The console shows the key’s brand prefix, then a fixed run of asterisks, then the last four characters — enough to tell two keys apart, not enough to reconstruct either.
You createdConsole shows
sk-orca-9f3aK2…long…7Qm4sk-orca-9f3****7Qm4
The first segment keeps the sk-orca- prefix and a few leading characters; the final four characters are the tail you’ll recognize when you cross-reference a log line or an error. Everything in between is collapsed to a fixed mask — the asterisk run is a constant, so its width never reveals the key’s true length.
Pair the masked tail with the key’s environment label and name when you need to find a specific key fast — the four-character tail plus a prod / staging tag is almost always enough to pick the right one out of a list without ever revealing plaintext.

​
3. When plaintext is shown — and when it isn’t

There is exactly one moment the full key is yours to copy, and a single gated path to retrieve it again.
When you mint a key, the console displays the full sk-orca-… plaintext one time. Copy it into your secret manager then. Every subsequent view of that key — the list, the detail panel, search results — shows only the masked form.
You can re-reveal an ordinary key’s plaintext on demand, but it’s a deliberate action behind the Developer+ role — not something the default list ever exposes. Re-revealing a gateway-scoped key (is_firewall_gateway) requires the Admin (or Owner) role, because that token can read registered MCP server credentials.
Listing keys, opening a key’s detail, searching, and every read of the token object return the masked form. The plaintext is never included in a list or search response.
Because re-reveal is gated and a gateway-scoped key needs Admin to read again, treat the creation-time copy as your one reliable capture. Save it to your secret manager immediately. If you lose an ordinary key’s plaintext you can re-reveal it (Developer+); if you can’t reveal it and can’t recover it, rotate to a fresh key rather than working around a key you can no longer read.

​
4. One concrete example: identifying the leaked key

Say an alert fires — a key is making calls from an unexpected IP — and the log line carries the masked tail …7Qm4. You don’t need the plaintext to act:
  1. Open the console Keys list (/console/token). Every row shows its masked fingerprint — sk-orca-9f3****7Qm4 and its environment label.
  2. Match the …7Qm4 tail (and the prod tag) to the offending row. The masked form is precisely the identifier you need here — no secret is exposed in the list, the alert, or your screenshot of it.
  3. Disable that key to pause it, or delete it to revoke for good — both are masked-safe actions that never print the plaintext. See Manage keys and Leaked key response.
The whole triage runs on the masked fingerprint. The plaintext stays in your secret manager where it belongs.

​
5. Masking in your own logs and tooling

The gateway masks its own surfaces; you control your side. The same principle applies to anywhere a key might land in your stack:
  • Never log the Authorization header or the raw sk-orca-… value. If you must record which key made a call, log the same shape the console uses — the prefix and last four characters — not the full secret.
  • Store plaintext only in a secret manager, never in source control, CI logs, or a config file checked into a repo. The key is masked in the console precisely so your own systems are the only place the live secret lives.
  • Scope keys narrowly so that even a leaked credential has a bounded blast radius — one model, one IP range, one spend cap. See the Least-agency checklist.
Masking reduces display exposure; it does not reduce the power of a key that does leak. A masked fingerprint in a log is safe, but the live key in a secret manager still authenticates fully — which is why narrow scope and fast rotation matter just as much as masking.

​
6. How this fits the rest of key hygiene

Masking is one layer of a defense-in-depth posture for credentials:

Manage keys

Create, disable, and revoke keys — the lifecycle behind every masked row in the list.

The token object

Every field a key carries, including the limits that bound a leaked key’s blast radius.

Key rotation

The zero-downtime handoff to a fresh key when you can’t recover or trust an old one.

Leaked key response

What to do the moment you suspect a credential is exposed.
For the bigger picture of how keys, policies, and workspaces nest to give each agent the narrowest identity, see Scope & keys. The rule is simple: the console shows you enough to recognize a key and never enough to leak one. Keep the plaintext in your secret manager, lean on the masked fingerprint everywhere else, and rotate the moment a key’s identity is in doubt.