One secret per job, not one secret for everything#
LumenFlow deliberately keeps identity narrow: the credential that lets you click around the dashboard cannot pair a machine, the code that pairs a machine cannot run your CI pipeline, and none of them can stand in for each other. If something asks you to reuse one of these where a different one belongs, that's a sign to stop and check, not a shortcut to take.
| Credential | What it's for | Who or what holds it | Lifetime |
|---|---|---|---|
| Dashboard session | Acting as yourself in the browser — chat, settings, approvals | Your signed-in browser | As long as your session stays valid |
| CI / workspace API key | The strongest credential: a CI job or self-hosted automation calling the control plane or Sidekick API as a service | Your CI secrets store, or a git-ignored local env file | Until you rotate or delete it |
| Provider (tool) installation | The connection between your workspace and an external tool — email, chat, calendar, tickets | Held by LumenFlow, scoped to that one provider and workspace | Until you disconnect it or the provider revokes access |
| Encrypted connector or model secret (BYOK) | An API key you bring for a model provider, or a custom connector | Stored encrypted, workspace-scoped | Until you replace or remove it |
| Node identity | Your workspace's record of one paired Linux or Windows machine — what it is, what it's allowed to claim | Held in your workspace, not on the machine | As long as the machine stays paired |
| Pairing exchange (single-use code) | Turning "an owner approved this in a browser" into "this exact machine is authorized" | Shown once to the owner/admin who mints it | Minutes — then it expires, used or not |
| Runtime credential | The durable secret the paired machine itself presents on every request | Stored locally on that machine only | Durable, until rotated or revoked |
| Assignment lease | Proof that a machine currently owns one specific unit of work | Held only in the machine's memory for that one assignment | Seconds to minutes — the life of the assignment |
Rotation and revocation#
- Dashboard session — sign out and back in; a workspace admin can end sessions for everyone.
- CI / workspace API key — regenerate it from Settings → Advanced. The old key stops authenticating within moments. Delete it the same way if you no longer need it.
- Provider installation — disconnect and reconnect from the tool's entry in workspace settings. You can also pull access from the provider's own app-management page at any time.
- Encrypted connector/model secret — paste a new key over the old one in Settings; the previous value is discarded immediately. You can also revoke it at the provider's own dashboard.
- Node identity and runtime credential — pair again for a fresh identity, or use the machine's row on the workspace Compute page to issue a new runtime credential (the old one is invalidated the moment the new one is issued), drain it (stop new work, let anything in flight finish), quarantine it (stop it claiming anything at all while you investigate), or revoke it outright.
- Pairing exchange code — it consumes itself the instant a machine exchanges it. An unused one simply expires; mint a fresh one if you need to retry.
- Assignment lease — not something you rotate by hand; a new one is issued with every claim, and releasing, failing, or completing the assignment ends it.
Prohibited storage and transport#
None of these should ever appear as a literal command-line argument you'd retype from shell history, in a repository file, in a chat message, in a support ticket, or copied onto a second machine:
- The CI/workspace API key belongs in a CI secrets store or a
git-ignored local env file — never a bare
export TOKEN=...you'd type interactively, and never insideworkspace.yamlor any file you'd commit. - The runtime credential belongs in the local file the pairing exchange writes on that one machine — never copied to a second machine, pasted into a ticket, or committed.
- The pairing code is shown once, in the browser, to the person pairing the machine. Treat it as burned the moment it appears anywhere else — a chat thread, a screenshot, a shared document — and mint a new one.
- Encrypted connector and model secrets never need to be pasted into a conversation with Sidekick itself; the settings page is the only place that should ever ask for one.
If a request, a ticket, or a piece of software asks you to hand over one of these credentials somewhere other than its own settings page, that request is wrong regardless of how official it looks — pause and verify before you comply.