Skip to main content

Security overview

Comind applies security at multiple layers - from authentication and network encryption through to fine-grained record-level access control. This page summarizes the key mechanisms and calls out known limitations.

Authentication​

Comind uses an OpenIdDict-based auth server for token issuance and validation. The platform supports SSO, LDAP, and Active Directory integration for enterprise identity providers. See Single sign-on (SSO) for configuration details.

Two-factor authentication is available through SSO. Enterprise customers configure 2FA at the identity provider level. Comind does not currently offer a standalone TOTP-based 2FA login - if your organization requires 2FA, enable it in your SSO provider before connecting to Comind.

AI agent access​

MCP-based AI agent connections use a dedicated apiv2_ai scope in auth tokens. Each customer subscription receives its own OAuth clientId, so AI agent access is scoped per tenant.

Authorization​

Comind enforces a four-layer ACL model that evaluates permissions in order:

  1. Workspace - top-level access to the workspace itself
  2. App - access to a specific app within the workspace
  3. Record - access to individual records
  4. Field - visibility and editability of specific fields on a record

Groups provide team-based access control across all four layers. See ACL evaluation order for the detailed evaluation logic and precedence rules.

Data security​

Encryption in transit​

All traffic between clients and the server is encrypted with SSL/TLS. Cloud-hosted deployments sit behind Cloudflare, which provides CDN caching and DDoS protection in addition to TLS termination.

Multi-tenancy and data isolation​

Comind runs a shared MongoDB instance across all subscriptions. Tenant isolation is enforced through row-level filtering on a tenant ID - every database query is scoped to the active subscription. There is no per-tenant database separation.

Backups and disaster recovery​

The platform includes backup and disaster recovery provisions. For self-hosted deployments, administrators manage their own backup schedules and retention policies.

Application secrets​

Sensitive configuration values - auth tokens, passwords, API credentials - are stored in COMIND_SECRET_* environment variables on the server. These values are server-only and never sent to the browser.

Known limitation: secrets are currently stored as plain text in environment variables. This is a recognized gap.

Audit trail​

Comind maintains a full version history on records with field-level diffs. Every change is tracked - who made it, when, and exactly which fields were modified. Under the hood, change tracking relies on a MongoDB oplog watcher that captures mutations in real time.

Hosting options​

  • Cloud-hosted - managed by Comind, behind Cloudflare, with production running as Windows services
  • Self-hosted - on-premise deployment for organizations with specific compliance or data residency requirements

See server requirements for hardware and software prerequisites.

Known limitations​

  • No standalone 2FA - two-factor authentication requires an SSO provider. Organizations not using SSO cannot enforce 2FA.
  • Plain-text secrets - COMIND_SECRET_* environment variables store sensitive values as plain text. A more secure secrets management approach is planned.
  • Shared database - all tenants share a single MongoDB instance with row-level filtering rather than physical database separation.