Access keys

Access keys authenticate downstream applications to the public Lumoswitch Runtime inference endpoint. They are not provider keys and must never be interchanged.

Security model

• The complete key is returned once, immediately after creation.
• Lumoswitch stores only the runtime token identity, prefix, and business state; lists show only the name and prefix.
• OpenAI requests use Authorization: Bearer <key>; Anthropic uses x-api-key; Gemini uses x-goog-api-key.
• Disabling or deleting a key removes its access.

Each API configuration has one current access key. During replacement rotation, the previous and new keys can overlap for a short grace period. Editing the configuration updates every active key through configuration synchronization.

Relationship to API configurations

The console flow creates the configuration and initial key together. A configuration keeps its current key during edits; disabling or deleting the configuration affects all active keys.

Limits

After creation

1. Copy the full key immediately.
2. Store it in a secrets manager or protected client environment.
3. Keep it out of Git, images, frontend bundles, and shared screenshots.
4. Run a minimal request.
5. Record the owner, environment, and rotation date.

Rotate safely

Use overlap for safe rotation:

1. Use the configuration card or POST /configurations/:id/access-key/rotate to request a replacement key for the same configuration.
2. Update every downstream client.
3. Confirm that all downstream clients use the new key.
4. Keep the old key only for the selected 60–86400 second grace period.
5. The synchronization worker blocks and removes the old runtime key after the deadline while retaining its usage tombstone.

Respond to a leak

1. Disable the key immediately.
2. Issue a replacement and update clients.
3. Review model and upstream configuration for unexpected changes.
4. Investigate the source of exposure.
5. Rotate upstream credentials too if they may have been exposed.