Security FAQ
Technical security questions we are asked most often about Curiosity Workspace. For anything not covered here, write to security@curiosity.ai.
Authentication and access
What authentication options are supported?
Local accounts with a password, and single sign-on through an external identity provider. The SSO flow, the supported providers, and the per-provider setup guides are documented under Single Sign-On (SSO):
| Provider | Protocol |
|---|---|
| Microsoft Entra ID (formerly Azure AD) | OAuth 2.0 / OIDC |
| Google Workspace | OAuth 2.0 / OIDC |
| Okta | OIDC |
| Auth0 | OIDC |
| Generic SAML 2.0 identity provider | SAML 2.0 |
Local accounts enforce a password complexity requirement and support time-based one-time passwords (TOTP, RFC 6238) as a second factor, configured per user from their profile. Password expiry is configurable with MSK_PASSWORDS_USER_EXPIRATIONDAYS and MSK_PASSWORDS_ADMIN_EXPIRATIONDAYS.
SSO is the supported way to put an identity provider's own MFA, conditional access, and group-based authorization in front of a workspace. Where your identity provider offers stronger factors than TOTP — hardware security keys, passkeys, or push approval — enforce them there.
Do you support SSO and SCIM?
SSO, yes — see the table above and the SSO guides.
SCIM, not yet. Automated user lifecycle provisioning over SCIM is on the roadmap and is not available today. Users are currently created on first SSO sign-in, or managed through the admin area and the user management API.
How is access to content controlled?
Through access groups. Every user, node type, individual field, code endpoint, AI tool, and AI assistant can be restricted to one or more access groups, and a user sees only what the groups they belong to allow. See the Permission model and the Access control model.
Administrative rights are separate from group membership: being an administrator of an access group grants no workspace-wide administrator privileges.
How are API tokens scoped?
Workspace tokens, endpoint tokens, and connector tokens each carry their own scope. See Token scopes.
Encryption
Is customer data encrypted at rest?
It can be. Curiosity Workspace ships optional AES-256 encryption of graph content at rest, enabled by setting a master key in MSK_GRAPH_MASTER_KEY. The key must be 32 random bytes, Base64-encoded; the workspace refuses to start with a key of any other length. When it is set, every node's content is encrypted before it is written. When it is not set, graph content is written to disk unencrypted and the workspace relies on the encryption provided by the storage layer underneath it.
Enable it where the storage infrastructure is not itself encrypted. Where you already run encrypted volumes (LUKS, AWS EBS encryption, Azure Disk Encryption, GCP CMEK), the master key adds a second, independent layer rather than replacing them.
Back up the key
Losing MSK_GRAPH_MASTER_KEY means losing every value encrypted with it, including in your backups. Store it in a secret manager alongside your other production credentials.
Configuration details are in the Configuration reference and the deployment Security baseline.
Is data encrypted in transit?
Yes. The workspace is designed to run behind TLS termination, and it calls external services (identity providers, model providers, connectors) over HTTPS. Enable HSTS with MSK_USE_HSTS=true and HTTP-to-HTTPS redirection with MSK_REDIRECT_TO_HTTPS=true. See the Security baseline for the full network posture.
How are passwords stored?
Local account passwords are stored as PBKDF2 hashes (HMAC-SHA-512) with a per-user random salt and a configurable iteration count. Plaintext passwords are never stored.
How are secrets such as model-provider API keys stored?
Credentials entered in the admin area — model provider API keys, connector credentials — are held in the graph as secrets. They are never returned by the generic node-reading APIs, and reads of their value are audited. On disk they are covered by the same at-rest encryption as the rest of the graph, so setting MSK_GRAPH_MASTER_KEY is what encrypts them.
Data handling
Where is customer data stored?
In the environment you run the workspace in. Curiosity Workspace is deployed to infrastructure you operate, and Curiosity has no access to the data inside it. See Deployment.
Do you train AI models on customer data?
No. Curiosity does not train models on workspace data. A self-hosted workspace sends data to a model provider only where you configure one, and which provider it reaches is your choice — including a model you host yourself. What leaves the workspace, and how to restrict it, is documented in LLM configuration.
How long is data retained?
Retention is entirely under your control, since you operate the deployment. Nodes scheduled for delayed deletion are visible in the admin area under Operate → Observability → Deletion Queue.
Operations
Is there an uptime or status page?
Yes, inside the workspace. The admin area has an Uptime page under Operate → Observability, which tracks the service's own uptime and availability. The same category also carries Monitoring, Usage Metrics, and Live Activity. See Monitoring.
What is logged?
Authentication events, administrative actions, and workspace activity. The admin area exposes them under Operate → Logs (Workspace Logs, Integrations Logs) and Access → Audit. See Monitoring.
How do I know a build contains a given security fix?
Every published security advisory names the first fixed build. The build a workspace is running is shown in the admin area under Configure → Workspace → About, and upgrade instructions are in Upgrades and migrations.
Reporting
I think I found a security issue — how do I report it?
Email security@curiosity.ai. See Report a Security Issue for what to include, our response times, and the testing rules.