Auth & permissions
Two layers, and they're separate:
- Daslab account auth — how you sign in to Daslab.
- Connection auth — how Daslab connects to your tools.
The second layer is where most of the safety story lives.
Signing in
Sign in with email + magic link, or sign in with Google. SSO via SAML 2.0 / OIDC for organizations on the enterprise tier. SCIM provisioning available for orgs that want centralized user lifecycle management.
Workspaces are the unit of access. You can be a member of multiple workspaces; each has its own roles, scenes, integrations, and audit log.
Per-scene roles within a workspace: owner, admin, member, viewer. Grant a team full control of one scene and read-only on another. Not all-or-nothing.
Connecting tools
When a scene needs Gmail, GitHub, Postgres, or anything else, it asks you to connect. The flow is OAuth (preferred) or API key, depending on what the provider supports.
Once connected, the credential lives in your workspace. Daslab calls the third-party API as you — not as a shared Daslab service account. The third-party sees your user, applies your authorization rules, logs against your name.
This means Daslab can never escalate beyond what your connected account is allowed to do. If your S/4 user can't read a CDS view, the agent can't read it either. If your Gmail account doesn't have admin rights, no admin operation is possible. Permissions are inherited from the source system. We don't bypass.
Customer-owned credentials
Connections are owned by your workspace. We don't have a shared "Daslab Gmail" account or a shared "Daslab S/4" tenant. Every connection is yours.
This applies to LLM keys too — see BYOK. Your Anthropic key, your OpenAI key, your Bedrock account. We pass calls through; you pay your provider directly.
Revoking access
Two paths:
- From Daslab: disconnect the integration in your workspace settings. The credential is purged from our database immediately.
- From the source: revoke the OAuth grant in Google / GitHub / SAP / wherever. Daslab loses access regardless of what we have on our side.
The second path is the safer one for emergencies — it works even if Daslab is compromised or unreachable.
What we never do
- Use one customer's credentials to call APIs for another customer.
- Put credentials in exports or git. Blueprint export seals credential fields into an encrypted vault, leaving only references.
- Cache responses across customers in ways that could leak data.
- Train models on your data. (See Data.)
What's next
Updated 2026-04-30