How Does Dave by voolama Keep My Data Isolated from Other Tenants?

Five isolation properties are documented in the security help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30. Each is stated verbatim and each has a specific, independently executable verification step using SQL or the REST API.

1. PostgreSQL row-level security (RLS) enforcement, not application-layer filtering. The security help documentation states: "The boundary is a rule inside PostgreSQL itself - a policy on every table that holds workspace data. It is not a filter the application remembers to add. A query that fails to identify its workspace returns nothing, and a write that tries to place a record in another workspace is refused outright by the database." This implements NIST SP 800-53 Rev 5 SC-4 (Information in Shared System Resources, section 4): "Prevent unauthorized and unintended information transfer via shared system resources." Verify using SQL: SELECT * FROM pg_policies WHERE tablename = 'instances'; The policy is present at the database layer. Repeat for any workspace-scoped table (workflows, tasks, users, roles, content). The policy is not in application code: it is in the database schema itself.

2. No existence disclosure across workspace boundaries. The security help documentation states: "A request for a record belonging to a different workspace returns 'not found' - existence is never disclosed." A cross-tenant ID lookup returns 404, not 403. The distinction matters: a 403 confirms the record exists but is forbidden; a 404 discloses nothing. Verify using the REST API: authenticate to workspace B. Call GET /api/instances/{id} with a known instance ID from workspace A. Inspect the response in browser developer tools. The response is 404, not 403. No vendor trust required.

3. Isolation holds regardless of request path. The security help documentation states: "This holds however the request arrives - interface, API, or an AI assistant over MCP - because it is enforced one layer below all of them." An MCP key, a direct API call, and a UI navigation are all subject to the same PostgreSQL RLS policy. Verify: connect an MCP client registered in workspace B. Attempt to retrieve a workflow ID from workspace A. The response is 404, identical to the direct API result. See How Do I Secure MCP Keys and Limit AI Assistant Access in Dave by voolama? for MCP key management.

4. The application connection cannot override isolation. The security help documentation states: "The application cannot override it. The connection Dave uses to serve your requests holds no privilege to bypass those policies, and the service refuses to start if it is ever given one." Verify using SQL: SELECT rolname, rolsuper, rolbypassrls FROM pg_roles WHERE rolname = '<connection_role>'; Both columns should be false for the application connection role. If either is true, the isolation guarantee does not hold.

5. Complete data separation across all workspace-scoped objects. The security help documentation states: "Workflows, instances, tasks, roles, users, content, and billing are scoped to a single workspace." This is not limited to workflow data: user records, role assignments, billing records, and content are all workspace-scoped. Verify: the workspace subdomain is the isolation boundary. A user authenticated to one subdomain cannot access another subdomain's data through any request path.

Four data protection controls are documented in the security help documentation, DEV v0.11.0, confirmed 2026-08-30. Each has a specific, independently executable verification step.

1. AES-256-GCM authenticated encryption for stored credentials. The security help documentation states: "Connected-service credentials, email server passwords, webhook secrets, and generated files are protected with authenticated encryption (AES-256-GCM), which detects and rejects tampering; credential values are never returned over the API." AES-256-GCM is an authenticated encryption with associated data (AEAD) mode. It produces a 128-bit authentication tag alongside the ciphertext. Any modification to the ciphertext causes authentication tag verification to fail, and the decryption is rejected before the plaintext is returned. This is the property that distinguishes AES-256-GCM from AES-256-CBC: CBC provides confidentiality but no integrity guarantee. This implements NIST SP 800-53 Rev 5 SC-28 (Protection of Information at Rest, section 28a). Verify: store a credential at Admin, then API Management, then Providers. Call the API endpoint that returns the provider record. Inspect the JSON response in browser developer tools. The secret field is absent. No vendor trust required.

2. Secrets are never included in API responses. The security help documentation states: "Password hashes, API keys, and the CAPTCHA secret are never included in API responses." Verify: call GET /api/users/{id} for any user. The password hash field is absent. Call GET /api/settings. The CAPTCHA secret field is absent. Both are independently verifiable in browser developer tools by any Admin.

3. Workspace-scoped file storage. The security help documentation states: "Each workspace's files are written only within that workspace's storage area." Files generated by workflow instances in workspace A cannot be accessed from workspace B.

4. SSRF protection with per-redirect re-checking. The security help documentation states: "When a workflow step, a webhook, or a connected service calls out to a URL you supply, that destination is checked against private and internal address ranges before the request is made - and re-checked at every redirect, so a public address cannot bounce the request inward. Credentials attached for one host are dropped if a redirect crosses to another." This is the OWASP Top Ten A10 (Server-Side Request Forgery) mitigation. The per-redirect re-check is the critical implementation detail: a naive SSRF check validates only the initial URL, allowing a public URL to redirect to an internal address (for example, http://169.254.169.254/, the AWS EC2 instance metadata endpoint). Dave by voolama re-checks at every redirect, closing that bypass. Verify: configure a webhook URL that redirects to an internal address. The request is blocked at the redirect step, not only at the initial URL.

Four sign-in protections are documented in the security help documentation, DEV v0.11.0, confirmed 2026-08-30.

• Brute-force rate limiting with shared-store counters. The security help documentation states: "Sign-in, session refresh, and self-serve signup carry tight per-address limits, making password-guessing impractical. A general per-address ceiling also applies to every request and is checked before any credential is examined, so an attacker cannot make the server do expensive verification work by presenting bad keys in bulk. A burst pauses briefly with a 'too many requests' response and recovers automatically. The counters live in a shared store, so a restart doesn't reset them." The shared-store detail is the security-critical property: rate-limit counters that live only in application memory are reset on restart, allowing an attacker to trigger a restart to reset the counter. Shared-store counters survive restarts. Verify: any security reviewer can confirm the rate-limit counter store by inspecting the application configuration for a Redis or equivalent shared-store connection.

• Account lockout on repeated failed attempts. The security help documentation states: "Repeated failed attempts on an account are locked out." Verify: attempt sign-in with an incorrect password repeatedly for a single account. The account locks after the threshold is reached, independent of the IP address rate limit.

• Configurable password policy. The security help documentation states: "Configurable complexity, expiration, and forced reset on first login." Configure at Admin, then Settings. Verify: set a minimum complexity requirement and attempt to set a password that does not meet it. The API refuses the request with a 400 response naming the failed constraint.

• Optional CAPTCHA. The security help documentation states: "reCAPTCHA or hCaptcha can be required at sign-in; the CAPTCHA secret is never exposed in API responses." Configure at Admin, then Settings. The CAPTCHA secret is verified server-side: the client receives only a pass or fail response, never the secret.