How One DAVE Workspace Stays Isolated from Another

In a multi-tenant platform, isolation means that the data, configuration, credentials, and activity of one tenant are completely inaccessible to any other tenant, regardless of how the underlying infrastructure is shared. DAVE enforces this at three independent layers, each of which would need to fail simultaneously for a cross-tenant data exposure to occur.

Data layer: Every record in DAVE's database is scoped to a tenant. Row-level security ensures that a query issued in the context of one tenant cannot return rows belonging to another. There is no shared table where tenant A's workflow instances, agents, credentials, or audit log entries commingle with tenant B's. The tenant identifier is a mandatory, non-nullable column on every data entity, and the query layer enforces it on every read and write.

Encryption layer: Credentials stored in each tenant's vault are encrypted with AES-256-GCM authenticated encryption. Each tenant's encryption is scoped to that tenant: the key material is not shared across tenants. Credentials are never returned through the API once stored. A read of a credential record returns a confirmation that the credential exists, not the credential value itself.

Authentication layer: Sessions use JWT-based authentication with stateless, tenant-scoped tokens. A token issued for tenant A cannot be used to authenticate a request against tenant B's resources. Refresh token rotation is enforced: each time a token is refreshed, the previous refresh token is invalidated, preventing replay attacks. Cross-tenant token reuse is structurally impossible because the token's tenant scope is validated on every request.

These three layers are independent controls. A failure at one layer does not compromise the others. Together they produce a boundary that is enforced in code, not in policy.

Beyond the data and authentication layers, DAVE gives each tenant's Admin users a set of controls that define how the tenant behaves, who can access it, and how long its data is retained. These controls are configured at Admin, then Settings and apply exclusively to the tenant whose Admin is making the change. No setting on one tenant affects any other tenant.

Tenant identity. Each tenant has a distinct Tenant Name and Application Name, configured in the General section of Admin Settings. These are not cosmetic: the Tenant Name is the identifier that scopes the tenant's data throughout the system. The Application Name appears in the browser tab and header, making it immediately clear to users which workspace they are operating in. In environments where users have access to more than one workspace, this labeling reduces the risk of a user taking an action in the wrong tenant.

Retention policies. Each tenant independently controls how long its completed workflow instances, artifacts, and audit logs are retained before automatic cleanup. The options are 30, 60, 90, 180, 365, or 730 days, or Forever. The defaults are 90 days for instances and artifacts, and 365 days for audit logs. A tenant that operates under a compliance framework requiring longer retention sets its own retention period independently of every other tenant. A tenant that wants shorter retention for data minimization reasons does the same. Retention policy changes take effect immediately on saving and are applied by a scheduled cleanup job. Expired data is permanently deleted and cannot be recovered.

Compliance audit logging. Each tenant independently enables the compliance standards that govern its audit log. Standard audit logging is always on and cannot be disabled: it captures all mutations, authentication events, and system changes. SOC 2 mode adds read-access logging for sensitive endpoints, covering SOC 2 trust service criteria CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management). GDPR mode adds read-access logging for user data endpoints, covering GDPR Articles 5, 15, 17, 30, and 33. Each standard can be enabled independently. When a compliance standard is enabled or disabled, a timestamped audit.compliance_changed event is logged automatically with a before-and-after snapshot. All audit events include a complianceTags array indicating which standards the event satisfies. These compliance settings are per-tenant: enabling SOC 2 mode on one tenant has no effect on any other tenant's audit configuration.

The tenant boundary is only as strong as the authentication controls that protect it. DAVE gives each tenant's Admin users granular control over how users authenticate, how long sessions last, and what happens when authentication fails. All of these controls are configured at Admin, then Settings, then Access.

Password policy

Each tenant sets its own password complexity requirements independently. The options are: None, Basic (8 or more characters), Standard (8 or more characters, mixed case, number), Strong (12 or more characters, mixed case, number, symbol), and Enterprise (16 or more characters, mixed case, number, symbol, no common passwords). Complexity is validated in real time on the password-change form. Admins can also require users to change their password immediately after an admin reset, and can configure password expiration: all passwords expire, non-admin passwords expire, or no forced expiration. Expiration periods range from 15 to 90 days.

Multi-factor authentication

MFA is configured per tenant. The master switch enables or disables MFA for the tenant. The enforcement policy controls whether MFA is tenant-wide mandatory, tenant-wide optional, or per-user optional. A grace period of 0 to 30 days gives users time to enroll after MFA becomes mandatory. Trusted device duration (0 to 90 days) controls how long a device remains trusted before re-verification is required. Backup codes for account recovery can be enabled or disabled.

DAVE supports eight MFA provider types: Google Authenticator (TOTP), Microsoft Authenticator (TOTP), Authy (TOTP), Duo Security (push and TOTP), YubiKey (FIDO2 and WebAuthn hardware key), Email OTP, SMS OTP, and a configurable Custom provider. Each provider card in the Settings UI includes inline setup instructions. A tenant that requires phishing-resistant authentication can mandate YubiKey. A tenant that needs push notification support can configure Duo Security. The choice is per-tenant and independent of every other tenant's MFA configuration.

SSO and OAuth providers

Each tenant independently configures its own SSO identity providers via the OAuth sub-tab at Admin, then Settings, then Access, then OAuth. Five provider types are supported: Google, Microsoft, GitHub, Okta, and Custom OIDC. Configuration fields include Client ID, Client Secret, Discovery URL (for OIDC providers) or Authorization URL, and the Callback URL, which is auto-generated based on the tenant's subdomain. When one or more OAuth providers are enabled, users see the corresponding login buttons on the login page alongside the standard email and password form. Disabled providers are hidden. SSO configuration on one tenant is completely independent of SSO configuration on any other tenant.

Login security

Rate limiting and account lockout are configured per tenant. The Admin sets the maximum number of consecutive failed login attempts (1 to 20, default 3) and the lockout duration (1 to 60 minutes, default 5 minutes). Lockout events are recorded in the audit log. Admins can manually unlock an account before the lockout period expires from Admin, then Settings, then Users and Roles. CAPTCHA can be added as an additional layer: supported providers are reCAPTCHA v2, reCAPTCHA v3 (with a configurable minimum score threshold), hCaptcha, and Cloudflare Turnstile. Each requires a Site Key and Secret Key from the CAPTCHA provider.

Session management

Session timeout is configured per tenant. The default is 60 minutes of idle time before the session expires and the user must re-authenticate. The range is 5 to 1440 minutes. Sessions use JWT-based authentication with tenant-scoped tokens and refresh token rotation. Tokens are scoped to the tenant: a token issued for one tenant cannot authenticate a request against another tenant's resources.

Every AI provider key, API credential, and secret stored in DAVE lives in a per-tenant credentials vault. The vault is encrypted with AES-256-GCM authenticated encryption. AES-256-GCM is an authenticated encryption scheme: it provides both confidentiality (the value cannot be read without the key) and integrity (any tampering with the ciphertext is detectable). The encryption is scoped per tenant: one tenant's vault key is not shared with or accessible to any other tenant.

Credentials are never returned through the API once stored. When a credential is read back, the API returns a confirmation that the credential exists and its metadata (name, type, last updated), not the credential value itself. This means that even a user with Admin access to the tenant cannot retrieve a stored API key through the DAVE interface: the key is write-once from the perspective of the API consumer.

This design has two important consequences for multi-tenant isolation. First, a credential stored in tenant A's vault cannot be read by tenant B, because the vault is scoped and the API enforces the tenant boundary on every read. Second, a credential cannot be exfiltrated through the API even by a compromised Admin account within the same tenant, because the API does not return the value. The credential is used by the workflow engine when an agent makes a provider call, but it is never surfaced to the user layer.

Provider configuration is managed at Admin, then API Management, then Providers. Each provider record stores the provider type, the base URI, and the encrypted credential. The provider is available to agents within the tenant and only within that tenant.

Tenant isolation prevents one tenant from accessing another's data. Role-based access control governs what a user within a tenant can do. Both are necessary: isolation without internal access control means any authenticated user in a tenant can do anything; internal access control without isolation means a well-governed tenant is still exposed to its neighbors.

DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by the tenant's Admin, so the six defaults are a starting point rather than a fixed set. DAVE enforces 20 permission types at both the API and the frontend level: a user without the required permission cannot perform the action through the UI, and the same check is enforced at the API layer, so bypassing the UI does not bypass the permission.

The Settings page itself is restricted to the Admin role. No other role can view or modify tenant settings, including the authentication controls, retention policies, and compliance audit logging described in this article. This means the controls that define the tenant's security posture are themselves protected by the most privileged role in the tenant.

Role assignment is managed at Admin, then Settings, then Users and Roles. A user can hold multiple roles simultaneously. The Admin role is required to access the Settings page, configure providers, manage users and roles, and view the audit log in its full compliance mode. The Reporting role is required to access the Reports page and its summary cards. All other roles are scoped to their specific functions: Create for agents, Curate for workflows, Use for running instances and completing tasks, Financial for billing and financial administration.

Every role assignment change, every settings change, and every authentication event is captured in the audit log. With SOC 2 mode enabled, read-access to sensitive endpoints including users, roles, and credentials is also logged. The audit log is the record that proves the tenant's access controls were enforced correctly, and it is itself retained according to the tenant's configured audit log retention policy.

Tenant isolation in DAVE is comprehensive at the platform level, but there are two areas where the isolation boundary is defined by the tenant's own configuration rather than by the platform automatically.

AI provider keys are yours. DAVE connects to AI providers using the API keys you configure. Those keys are encrypted in your tenant's vault and are not shared with other tenants. However, the provider account the key belongs to is your account: if you use the same provider account and key across multiple DAVE tenants (for example, a production tenant and a staging tenant), the usage from both tenants appears in a single provider billing view. The DAVE platform does not share your key with another tenant, but your provider account is not isolated between your own tenants if you choose to use the same key. Use separate provider API keys for separate tenants if you need provider-level isolation between your own workspaces.

Retention policy is a floor, not a ceiling. Setting a retention policy controls when data is automatically deleted. It does not prevent a user with appropriate permissions from exporting or viewing data before the retention period expires. If your compliance framework requires that data be inaccessible after a certain period, retention policy is a necessary but not sufficient control: you also need to manage role assignments so that only users who need access to historical data have it.

Audit log retention and compliance mode should be set before you need them. Enabling SOC 2 or GDPR compliance mode activates read-access logging going forward. It does not retroactively log reads that occurred before the mode was enabled. If you anticipate needing a full audit trail for a compliance review, enable the relevant compliance mode at the start of the period you need to cover, not at the point of the review. The same applies to audit log retention: if your compliance framework requires seven years of audit log retention (as SOC 2 recommends), set the retention period to Forever or 730 days before the audit period begins, not after data has already been purged by a shorter retention setting.

These are configuration decisions, not platform limitations. The controls are available and effective when they are configured correctly from the start of the tenant's operational period.