Multi-Tenant AI Security: How Per-Tenant Encryption Keeps Every Workflow Isolated

When a company adopts a SaaS AI platform, they're usually sharing a database cluster, a job queue, and a model-routing layer with thousands of other tenants. The vendor promises logical separation — rows tagged with a tenant ID, maybe a row-level security policy in Postgres. That's fine for low-stakes data. It's not fine when the rows contain system prompts that encode your proprietary reasoning logic, API keys for your private fine-tuned models, or regulated personal data flowing through an HR or healthcare workflow.

The risk isn't just a rogue query. It's misconfigured policies, framework bugs, cache poisoning, and the ever-present threat of a vendor-side breach that exposes every tenant's data in one event. Logical separation means a single misconfiguration is the only thing standing between your data and someone else's.

The architectural answer is physical or cryptographic isolation — and for most teams that don't want to run a dedicated cluster per tenant, cryptographic isolation is the practical path. That means every tenant's data is encrypted with keys that only that tenant's context can derive. Even if two tenants share the same Postgres instance, a breach of one tenant's key material reveals nothing about another's.

DAVE is built on NestJS 11, Next.js 16, and PostgreSQL 16, and its multi-tenancy model is designed from the schema layer up — not bolted on afterward. Each tenant provisioned on a DAVE instance gets its own encryption context. Sensitive fields — model credentials, workflow payloads, prompt templates, and output logs — are encrypted at rest using keys scoped to that tenant. The platform's 246 REST endpoints enforce tenant context on every request, so there is no API path that can return cross-tenant data even if a caller presents a valid but wrong-tenant token.

Key points of the implementation:

• Credential isolation: When you bring your own model keys (OpenAI, Anthropic, Mistral, or any of DAVE's 8 supported AI provider types), those keys are stored encrypted under your tenant's key material. The platform never sees plaintext credentials in logs or query results.
• BYO model, zero markup: Because DAVE routes your requests directly to your own provider accounts, there is no shared model-call pool. Your tokens go to your account. There is no path for your inference traffic to be co-mingled with another tenant's.
• Payload encryption: Workflow inputs and outputs that traverse the orchestration layer are encrypted in transit (TLS) and at rest. Audit logs record metadata — timing, status, tenant ID — without storing raw prompt/response content in plaintext.
• OAuth2/OIDC SSO integration: Identity is federated to your existing IdP, so DAVE never holds plaintext passwords and tenant authentication is scoped to your identity provider's session controls.

The result is a system where a compromise of the infrastructure layer — the VPS, the database host, the object store — does not automatically mean a compromise of tenant data. An attacker would need to obtain per-tenant key material separately, which is a dramatically harder problem.

Claiming 'SOC 2 compliance' on a landing page is easy. Shipping a platform where SOC 2 controls are enforced at the runtime and data-model level is harder. DAVE ships with explicit SOC 2 and GDPR modes that change real system behavior — not just documentation.

SOC 2 Mode

When SOC 2 mode is enabled, DAVE enforces stricter audit logging, access control reviews, and change-management guardrails across the orchestration layer. Every workflow execution is traceable to an authenticated identity. Privileged operations — modifying tenant encryption settings, rotating credentials, changing workflow permissions — generate immutable audit events. This gives your security team the evidence trail they need for a Type II audit without building a custom logging pipeline.

GDPR Mode

GDPR mode activates data-minimization controls and right-to-erasure pathways. Workflow payloads that contain personal data can be flagged at the workflow-definition level, triggering automatic retention limits and erasure hooks. When a data subject requests deletion, DAVE's erasure pipeline can target that tenant's encrypted data store without touching other tenants. Because personal data is encrypted under per-tenant keys, key rotation or key destruction is a cryptographically sound erasure mechanism — the data becomes unreadable without needing to physically delete every row.

Both modes are self-hostable. You run DAVE on your own Linux VPS or managed cloud, which means the data never leaves your infrastructure boundary in the first place — a significant simplification for GDPR data-residency requirements.

Every security control described above becomes stronger when you self-host DAVE on your own infrastructure. The threat model shrinks dramatically: you eliminate the vendor-breach vector entirely because there is no shared vendor infrastructure. Your data lives in your VPS, your managed Postgres instance, your network perimeter.

DAVE is designed to deploy on any Linux VPS or managed cloud — AWS, GCP, Azure, Hetzner, DigitalOcean, bare metal. The deployment surface is standard: a NestJS API layer, a Next.js frontend, and a Postgres 16 database. There is no proprietary agent to trust, no call-home telemetry, no license server that can see your workflow data.

For teams in regulated industries — financial services, healthcare, legal, government — self-hosting isn't optional, it's the only acceptable architecture. DAVE's self-host path gives those teams a production-grade AI workflow orchestration platform with the compliance posture they need, without forcing them to build the orchestration layer from scratch.

Practically, this means:

• Your AI workflows run inside your VPC, behind your firewall rules.
• Your model API keys never transit a third-party network.
• Your audit logs go to your SIEM, not a vendor's shared logging service.
• Your encryption keys stay in your key management system.

Voolama itself runs on DAVE — the same platform you'd be deploying. That's not a marketing claim; it's the most direct proof point that the self-host path is production-ready.

Whether you're evaluating DAVE or any other AI workflow platform, these five questions will quickly separate genuine security architecture from marketing copy:

1. Is tenant isolation cryptographic or only logical? Logical isolation (row-level security, tenant ID filters) is a policy. Cryptographic isolation is a mathematical guarantee. Ask to see the key management architecture.
2. Where do my model API keys live, and in what form? If the vendor's platform holds your keys in a shared secrets store, a breach of that store exposes every tenant's credentials. Per-tenant encrypted credential storage is the minimum bar.
3. Does the platform route inference traffic through its own accounts? If yes, you are paying an AI markup and your traffic is co-mingled with other customers'. BYO-key direct routing eliminates both problems.
4. What does 'SOC 2 compliant' actually mean at runtime? Ask for the specific controls list. Immutable audit logs, privileged-access management, and change-management enforcement should be demonstrable in the product, not just in a PDF.
5. Can I self-host, and what does the self-host architecture look like? A platform that cannot be self-hosted is a platform where you are permanently dependent on the vendor's security posture. Self-hostability is a risk-management option, not just a cost preference.

DAVE is designed to answer all five questions with a concrete technical answer, not a policy document. The architecture is open enough to inspect, and the self-host path means you can verify every claim in your own environment.

If your team is running AI workflows on shared SaaS infrastructure and hasn't audited the isolation model, this week is the right time to start. The questions in the section above are a practical starting point for that conversation with any vendor, including your current one.

If you're ready to move to a platform with cryptographic tenant isolation, BYO model keys, and a self-host path that keeps data inside your own infrastructure boundary, DAVE is available now. The platform runs on NestJS 11 / Next.js 16 / PostgreSQL 16 — a standard, auditable stack with no proprietary black boxes.

Start with the self-hosting guide to get a DAVE instance running on your own VPS. From there, you can explore the AI workflow orchestration checklist to map your existing workflows to DAVE's 246-endpoint API surface. Your workflows. Your AI. Your rules.