How We Handle Tenant Isolation When Every Customer Brings Their Own Database

Multi-tenancy is hard. Multi-tenancy where every customer brings their own database, schema, and access patterns is a fundamentally different engineering problem. At Vigilense, we built our isolation model from the ground up for BYODb, and it goes far beyond logical separation.

In the cloud, each tenant's data, compute, and network are fully separated at the infrastructure level. This ensures that even in the "AI Storm," where automated reasoning engines are running thousands of queries, your data remains in a "Sovereign" silo.

Why BYODb Makes Isolation Harder

Most multi-tenant platforms control the data layer. They decide the schema and the storage engine. BYODb removes that luxury. You cannot rely on a single shared database with row-level policies. You need:

• Credential vaults that never co-mingle secrets.
• Query sandboxing to prevent a detection rule from reaching another tenant's data.
• Network segmentation that treats every customer connection as its own trust boundary.

The Six Isolation Layers

Our model is built in depth. Compromise of any single layer does not expose data because the remaining five enforce boundaries independently.

1. Identity Layer

Every request is authenticated with tenant context before it touches any business logic. We enforce MFA and SSO (SAML 2.0/OIDC). Sessions are short-lived and use device-trust validation to prevent token replay.

2. Application Layer

The tenant ID is injected into every downstream operation via middleware. If a code path attempts to execute without tenant context, the request fails immediately. This makes unscoped queries impossible.

3. Data Layer

We offer three levels of isolation based on your compliance needs:

• Standard: Row-Level Security (RLS) on shared tables.
• Enhanced: Dedicated schema per tenant within a shared instance.
• Maximum (Sovereign): A fully dedicated database instance. No shared processes, no shared memory.

4. Encryption Layer

We use a layered key hierarchy:

• Master Key: HSM-protected (Hardware Security Module).
• Tenant KEK (Key Encryption Key): Unique to you; wraps all your data keys.
• Crypto-Shredding: If a tenant leaves, we destroy the KEK, rendering all data permanently unrecoverable.

5. Network Layer (The "PrivateLink" Standard)

Tenant traffic is isolated via full VPC isolation. We support AWS PrivateLink and VPC Peering, meaning your security telemetry never traverses the public internet to reach our "brain."

6. Compute Layer

This is where we differentiate. Each tenant's workloads (including our AI SOC Analysts) run in dedicated containers. A "noisy neighbor" or a high-intensity AI investigation in another tenant's environment cannot degrade your performance or access your memory.

The AI Safety Factor: Causal Reasoning Boundaries

As we deploy AI agents to perform 3-Layer Blast Radius investigations, isolation becomes even more critical. Our AI agents are "Context-Locked." They are physically unable to generate a query that traverses outside of your specific VPC and credential set. We do not just "tell" the AI to stay in its lane; we build the lane out of iron.

How We Test the "Blast Radius"

Architecture diagrams are promises; testing is proof.

• Annual 3rd-Party Pentests: Focused specifically on cross-tenant privilege escalation.
• CI/CD Boundary Tests: Every code change is tested for "unscoped query" vulnerabilities.
• Chaos Engineering: We deliberately misconfigure network policies in a sandbox to ensure our secondary layers (Encryption/Identity) hold firm.

The Bottom Line

Tenant isolation in a BYODb architecture is not a feature. It is a system of interlocking controls. We built this because our customers are trusting us with their most sensitive telemetry. We earn that trust with engineering rigor, not marketing language.

View our full security posture in the Trust Center.