Multi-Tenant AI Security: Per-Tenant Encryption, SOC 2, and GDPR in Production AI Workflows

Traditional SaaS multi-tenancy is a solved problem: row-level security, scoped JWTs, separate S3 buckets. AI workflows introduce a new class of risk that most platforms haven't caught up with.

Consider what flows through a typical AI orchestration run: the raw user prompt, retrieved documents from a vector store, intermediate chain-of-thought reasoning, the final model output, and the API credentials used to call the model. Every one of these artifacts is potentially sensitive — and every one of them can leak across tenant boundaries if the platform wasn't designed with isolation as a first principle.

The failure modes are subtle. A shared embedding cache can expose one tenant's document chunks to another's retrieval query. A global API key pool means one tenant's runaway workflow burns another's budget. Shared log aggregation pipelines can commingle audit trails, making GDPR data-subject requests nearly impossible to fulfill accurately.

• Prompt and context leakage — shared memory or cache layers that don't scope by tenant.
• Credential sprawl — one compromised key affects all tenants on the platform.
• Audit trail pollution — commingled logs that can't be cleanly scoped to a single tenant for compliance review.
• Model output storage — LLM responses stored in shared tables without tenant-level encryption.

Solving these problems requires architectural decisions made at the platform level — not bolt-on middleware applied after the fact.

"Encryption at rest" is table stakes. Per-tenant encryption is a meaningfully higher bar: each tenant's data is encrypted with a key that is scoped exclusively to that tenant, so a breach of one tenant's key material does not compromise any other tenant's data.

In a well-designed system, this means:

1. Tenant-scoped key derivation — each tenant gets a unique encryption key (or key hierarchy) derived from a master key using a deterministic, auditable process. The platform never stores plaintext tenant data alongside a shared key.
2. Encrypted columns for sensitive fields — prompt payloads, model outputs, retrieved context, and stored credentials are encrypted at the column level in the database, not just at the disk level.
3. BYO key support — enterprise tenants can supply their own encryption keys, ensuring the platform operator never has access to plaintext data even in theory.
4. Key rotation without downtime — the system supports re-encryption of tenant data on key rotation, with zero workflow interruption.

DAVE implements per-tenant encryption across its PostgreSQL 16 data layer, scoping encryption to each tenant's partition. Combined with DAVE's BYO-model architecture — where tenants supply their own AI provider API keys and those keys are stored encrypted per-tenant — there is no shared credential surface for a bad actor to target.

The practical upshot: if you're running DAVE for three enterprise clients, a compromise of Client A's environment has zero cryptographic access to Client B's or Client C's data, prompts, or keys.

SOC 2 Type II is an audit of operational controls over time — not a point-in-time certification. For AI workflow platforms, auditors are increasingly scrutinizing controls that didn't exist in the traditional SaaS SOC 2 playbook.

The five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) all have AI-specific interpretations:

• Security (CC6-CC9) — logical access controls must extend to AI model endpoints, not just application layers. Who can trigger a workflow that calls a model? Are those calls logged with sufficient fidelity for audit? DAVE's OAuth2/OIDC SSO integration and 246-endpoint REST API surface both support scoped, auditable access at the workflow level.
• Processing Integrity (PI1) — AI outputs must be traceable. Auditors want to see that a given output was produced by a specific model version, with a specific prompt, at a specific time, for a specific tenant. DAVE's workflow execution logs capture this provenance chain.
• Confidentiality (C1) — data classified as confidential (e.g., customer PII fed into a summarization workflow) must be protected throughout its lifecycle in the platform. Per-tenant encryption directly satisfies this criterion.
• Privacy (P1-P8) — if personal data flows through AI workflows, the platform must support data subject rights: access, correction, deletion. This requires tenant-scoped data stores that can be queried and purged cleanly.

Running DAVE in SOC 2 mode activates the platform's compliance-oriented configuration: enhanced audit logging, stricter access control enforcement, and data retention controls aligned to your audit period. This is not a separate product tier — it's a runtime configuration designed for teams that are themselves pursuing or maintaining SOC 2 certification.

GDPR compliance for AI workflows is more demanding than for traditional data processing pipelines, for one core reason: AI models can memorize, interpolate, and surface personal data in ways that are difficult to predict or audit after the fact.

The obligations that catch teams off guard:

• Data minimization in prompts — Article 5(1)(c) requires that personal data processed is adequate, relevant, and limited to what is necessary. Feeding full customer records into a prompt when only a name and account number are needed is a compliance risk. Workflow design matters.
• Lawful basis for AI processing — if your workflow processes personal data (e.g., a customer support summarization workflow), you need a documented lawful basis. Legitimate interest assessments for AI processing are increasingly scrutinized by DPAs.
• Data subject access requests (DSARs) — if a data subject requests their data, you need to be able to retrieve everything the platform holds about them, including prompt history and model outputs. This is only tractable if your data is tenant-scoped and queryable by subject identifier.
• Right to erasure — Article 17 requires deletion of personal data on request. In a shared-table architecture without tenant-level isolation, this is operationally painful. In DAVE's per-tenant model, erasure is scoped and auditable.
• Cross-border transfers — if your AI provider is in a different jurisdiction, the data transfer must be covered by an appropriate mechanism (SCCs, adequacy decision). DAVE's BYO-model architecture means you choose your provider and jurisdiction — the platform doesn't route your data through a shared inference layer.

DAVE's GDPR mode enables the platform-level controls: data residency configuration, retention policy enforcement, and the audit log fidelity needed to respond to DPA inquiries. Self-hosting DAVE on infrastructure in your chosen region means you control the entire data perimeter — no shared cloud inference, no third-party data processing agreements with the platform itself.

For teams with serious compliance obligations, self-hosting an AI orchestration platform isn't a cost decision — it's a security architecture decision. When you self-host DAVE on your own Linux VPS or managed cloud environment, several things become true that are structurally impossible on a shared SaaS platform:

• No shared compute surface — your workflows run on infrastructure you control. There is no noisy-neighbor risk, no shared hypervisor to worry about, and no platform operator with access to your runtime memory.
• Network perimeter control — you decide which AI provider endpoints are reachable from your DAVE instance, and you can enforce this at the network layer. A misconfigured workflow cannot exfiltrate data to an unauthorized endpoint if your firewall rules prevent it.
• Audit log ownership — your logs stay in your environment. You can pipe them to your SIEM, retain them for your audit period, and produce them for auditors without involving the platform vendor.
• Encryption key custody — your keys, your HSM, your KMS. The platform vendor has zero access to your key material.
• Vendor risk reduction — your SOC 2 and GDPR posture is not dependent on the platform vendor's compliance status. You are the data controller and the data processor. Your auditors only need to review your environment.

DAVE deploys on any Linux VPS or managed cloud — AWS, GCP, Azure, Hetzner, your own bare metal. The NestJS 11 / Next.js 16 / PostgreSQL 16 stack is standard, auditable, and well-understood by security teams. There are no proprietary runtimes or black-box components to explain to an auditor.

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 we can offer that the platform is production-ready for real compliance workloads.

If you're evaluating DAVE for a multi-tenant or compliance-sensitive deployment, here's the practical starting point for your security review:

1. Define your tenant boundary model — are your tenants internal teams, external clients, or business units? The answer shapes how you configure tenant provisioning and key scoping in DAVE.
2. Choose your infrastructure region — for GDPR, pick a region that satisfies your data residency requirements before you deploy. DAVE runs anywhere; the region decision is yours.
3. Configure BYO model keys per tenant — each tenant should supply their own AI provider API keys. This eliminates shared credential risk and gives each tenant full visibility into their own model spend.
4. Enable SOC 2 or GDPR mode — activate the appropriate compliance runtime configuration for your audit requirements. These are not mutually exclusive.
5. Integrate with your IdP — DAVE's OAuth2/OIDC SSO support means you can plug into your existing identity provider (Okta, Azure AD, Google Workspace) and inherit your existing access control policies.
6. Review the 246-endpoint API surface — scope API access to the minimum required for each integration. DAVE's REST API supports fine-grained access control; use it.
7. Establish your audit log pipeline — pipe DAVE's execution logs to your SIEM or log management platform from day one. Retrofitting audit log coverage after a compliance incident is painful.

Multi-tenant AI security is not a feature you add later. It's an architectural commitment you make at platform selection time. DAVE was built with these requirements as first-class constraints — not as an enterprise add-on tier, but as the default production posture for teams that take compliance seriously.

Your workflows. Your AI. Your rules.