Workspace isolation#
Every piece of data in LumenFlow is scoped to a workspace. Access controls are enforced at multiple layers to ensure no data crosses workspace boundaries — even in the event of an application bug.
Authentication#
When you sign in, LumenFlow creates a secure session tied to your identity and workspace. This session determines what data you can access and what actions you can take.
Role enforcement#
Roles are checked before any data operation:
- You authenticate and receive a secure session
- Your session includes your workspace and role
- Every request validates your permissions before processing
- Database-level enforcement provides a second layer of protection
Token model#
LumenFlow issues several credential kinds. Each has its own prefix, scopes and revoke path. Credentials and scopes lists all of them. A request outside a credential's scopes is refused with HTTP 403 and reasonCode: "insufficient_scope", naming the required and granted scopes, and the refusal is written to the audit log. A revoked or unknown credential is refused with 401.
A read scope covers read requests (GET, HEAD, OPTIONS) and a write scope covers every other request; neither implies the other. Workspace API keys carry read and write, or the scopes you chose when you created or regenerated the key. Keys that existed before scopes keep read and write access. Choose a narrower scope when you create or regenerate a key, for example read only for a dashboard integration.
A workspace API key with the write scope is the strongest credential — treat it like a service-account key.
Access control is enforced at the database level. Even if application code has a bug, the database prevents cross-workspace data access.