Virtual keys
A virtual key is the credential an application presents to the gateway (Authorization: Bearer zea-…). ZeaLLM stores only a SHA-256 digest and the last four characters. The plaintext secret exists once, at reveal time.
Lifecycle
| Status | Meaning |
|---|---|
PENDING | Key request waiting for a reviewer |
PENDING_REVEAL | Approved; secret not yet shown |
ACTIVE | In use |
BLOCKED | Gateway rejects calls (admin block or budget) |
REVOKED | Permanently destroyed |
EXPIRED | Past expiry date |
Request statuses: PENDING, APPROVED, REJECTED, CANCELLED.
Ownership
| Type | Who owns it | Typical use |
|---|---|---|
PERSONAL | The requesting user | Experiments, notebooks |
SERVICE_ACCOUNT | A team | Production apps — survives membership changes |
Service accounts require a team.
What is configured on a key
- Alias (display name)
- Access group — which model groups the key may call
- Environment —
DEVELOPMENT,STAGING,PRODUCTION - Budget and duration (
1d,7d,30d) or a budget tier - RPM / TPM
- Expiry — 30 / 90 / 180 days, or never
- Optional application and policy attachment (otherwise policies inherit org → team → key)
Who can do what
| Action | Who |
|---|---|
| Request | Any writable user |
| Approve / reject | Platform admin, org admin, or that team's admin |
| Reveal / rotate / revoke | Owner, original requester, team admin, or platform admin |
| Block / unblock | Team admin or platform admin |
Rotate mints a new secret once; the old secret stops immediately. Block, revoke and rotate take effect on the gateway as soon as Redis invalidates the cache (or after the in-memory TTL if Redis is down).