Multi-Tenant AI Security: How DAVE Keeps Every Team's Workflows Encrypted and Isolated

Most AI workflow tools were built for a single user or a single team. When those tools get stretched into multi-team or multi-client deployments, security is typically bolted on: a shared API key stored in one environment variable, a single database schema where every tenant's workflow data sits side-by-side, and audit logs that mix events from every user into one undifferentiated stream.

That architecture works fine for a demo. It fails in three predictable ways when you go to production:

• Data bleed risk. A misconfigured query, a noisy-neighbour bug, or a compromised admin account can expose one tenant's workflow outputs to another. With AI workflows, those outputs often contain sensitive business data — customer records, financial summaries, internal documents.
• Compliance scope explosion. If all tenant data lives in the same logical store, a single GDPR data-subject request or a SOC 2 audit scope question touches everything. You can't isolate one tenant's data for deletion or review without touching the whole system.
• Credential sprawl. Shared AI provider keys mean one leaked credential exposes every tenant's model access and, potentially, their usage history with that provider.

These aren't edge cases. They're the predictable failure modes of retrofitting multi-tenancy onto a single-tenant design. DAVE was built to avoid all three from the ground up.

DAVE implements per-tenant encryption at the data layer, not just at the transport layer. TLS in transit is table stakes — every serious platform has it. What differentiates a true multi-tenant architecture is what happens to data at rest and at the application layer.

In DAVE's model, each tenant's sensitive workflow data — inputs, outputs, credentials, configuration — is encrypted with key material scoped to that tenant. A breach of one tenant's envelope does not compromise another's. This is the same principle used by enterprise secret managers and cloud KMS systems, applied to AI workflow orchestration.

Practically, this means:

• Workflow payloads (the data flowing through your AI pipelines) are encrypted before they hit the database, using per-tenant keys.
• AI provider credentials stored in DAVE (your OpenAI key, your Anthropic key, your self-hosted model endpoint) are encrypted per-tenant and never exposed across tenant boundaries — not even to other application-layer processes.
• Audit and event logs are partitioned by tenant, so a compliance query for Tenant A never returns rows belonging to Tenant B.

This architecture runs on PostgreSQL 16, which gives DAVE mature, battle-tested row-level and column-level tooling to enforce isolation at the database layer as a second line of defence behind the application layer.

Compliance isn't a one-size-fits-all requirement. A US-based SaaS company pursuing SOC 2 Type II has different control obligations than a European B2B platform handling personal data under GDPR. DAVE ships with both modes configurable at the platform level, so you don't have to build compliance controls yourself on top of a generic workflow engine.

SOC 2 Mode

When SOC 2 mode is enabled, DAVE enforces the logging, access-control, and change-management behaviours that auditors look for in the Trust Services Criteria. This includes immutable audit trails for all workflow executions, enforced MFA via OAuth2/OIDC SSO, and role-based access controls that restrict which users can modify workflow definitions versus only triggering them. These controls are on by default in SOC 2 mode — you don't have to remember to configure them individually.

GDPR Mode

GDPR mode activates data-subject rights tooling: the ability to identify, export, and delete a specific individual's data across all workflow executions within a tenant's envelope. Because DAVE's data is partitioned per-tenant, a GDPR deletion request is scoped to exactly one tenant's data — it doesn't require a platform-wide operation. GDPR mode also enforces data-residency configuration, ensuring workflow data is processed and stored in the region you've designated, which matters when self-hosting on European infrastructure.

Both modes can be active simultaneously for teams that need to satisfy both frameworks — common for European subsidiaries of US companies or any platform selling into regulated industries on both sides of the Atlantic.

One of the least-discussed multi-tenant AI security risks is the AI provider itself. When you route all your tenants' workflow data through a single shared API key to a hosted model, you're creating a data-aggregation point outside your control. The provider's logging, fine-tuning opt-outs, and data-retention policies now apply to every tenant's data, whether those tenants know it or not.

DAVE's BYO-model architecture eliminates this risk at the design level. Each tenant can be configured with its own AI provider credentials — their own OpenAI organisation key, their own Anthropic key, their own endpoint for a self-hosted open-weight model. DAVE supports eight AI provider types, and because you bring your own keys, there is no AI markup and no data aggregation happening at the DAVE layer.

For the most security-sensitive deployments, teams run DAVE entirely on-premises alongside a self-hosted model (Ollama, vLLM, or any OpenAI-compatible endpoint). In that configuration, no workflow data leaves your infrastructure at all — not to DAVE's servers (DAVE is self-hosted), not to a third-party AI provider. The entire stack runs on your Linux VPS or managed cloud instance.

This is what 'Your workflows. Your AI. Your rules.' means in practice: the security perimeter is yours to define and yours to audit.

Encryption and compliance modes protect data at rest and in transit. Identity controls protect data in use — who can see what, who can trigger what, and who can change what. DAVE ships with OAuth2/OIDC SSO as a first-class feature, not a paid add-on.

This means you can connect DAVE to your existing identity provider — Okta, Azure AD, Google Workspace, Auth0, or any OIDC-compliant IdP — and enforce your existing access policies without managing a parallel user directory inside DAVE. When an employee leaves your organisation and their IdP account is deprovisioned, their DAVE access is revoked automatically. No separate offboarding step, no orphaned credentials.

Within each tenant, DAVE's role-based access control lets you separate concerns cleanly:

• Workflow authors can design and modify workflow definitions.
• Operators can trigger and monitor workflows but cannot modify their definitions.
• Viewers can inspect outputs and audit logs but cannot trigger or modify anything.
• Tenant admins manage users and credentials within their own envelope, without visibility into other tenants.

Combined with per-tenant encryption and SOC 2 audit logging, this gives you a complete, auditable access-control story — the kind that satisfies both internal security reviews and external auditors.

Every security control described in this article runs on infrastructure you control. DAVE is a self-hosted platform — you deploy it on any Linux VPS or managed cloud environment (AWS, GCP, Azure, Hetzner, your own data centre). There is no DAVE-managed cloud where your workflow data transits through voolama's infrastructure.

This matters for several reasons that go beyond compliance checkboxes:

• Network perimeter control. You decide whether DAVE is internet-facing or VPN-only. For internal enterprise deployments, DAVE can run entirely air-gapped from the public internet.
• Key management. You control where encryption keys are stored and rotated. You can integrate DAVE with your existing KMS (AWS KMS, HashiCorp Vault, GCP Cloud KMS) rather than delegating key custody to a SaaS vendor.
• Audit log custody. Your audit logs stay in your infrastructure, in your SIEM, under your retention policies — not in a vendor's logging system that you have to request exports from.
• Vendor risk elimination. A SaaS AI platform going down, changing its pricing, or being acquired doesn't affect your production workflows. You own the runtime.

DAVE's NestJS 11 / Next.js 16 / PostgreSQL 16 stack is straightforward to operate for any team comfortable running a Node.js application with a Postgres database. The 246 REST endpoints are fully documented, making it practical to integrate DAVE into existing infrastructure-as-code and monitoring pipelines. voolama itself runs its own production workloads on DAVE — the platform is proven in the environment it was designed for.

If you're evaluating AI workflow platforms for a team, a product, or a client deployment where security and compliance are non-negotiable, the architecture described here is the starting point worth demanding from any vendor. With DAVE, it's the default.