Why we chose multi-tenant isolation over single-tenant for security

The intuition

Every enterprise security review asks the same question: "Do you offer single-tenant deployment?" The intuition is obvious — a dedicated database, dedicated servers, no risk of cross-tenant data leak. More isolation equals more safety.

We push back.

For agent workloads, multi-tenant with proper isolation is actually more secure. Not less. And we'll walk you through the threat model.

Why single-tenant feels right (and is, for traditional SaaS)

The intuition makes sense if your threat model is SQL injection, container escape, or a bug in the application layer that leaks data. Dedicated VMs, dedicated databases, dedicated networks — if something goes wrong, the blast radius is one customer.

"Traditional SaaS threats live in the infrastructure and application code. Single-tenant reduces blast radius. This logic is sound for a CRUD app."

But agent workloads have a fundamentally different threat model. The primary risk is not the infrastructure. It's the model itself.

The agent threat model is different

Consider what can go wrong with an autonomous agent:

The LLM receives a prompt injection attack and executes unintended actions
The model hallucinates and calls the wrong API or modifies the wrong record
An attacker uses social engineering to manipulate the agent's behavior
The agent's weights are fine-tuned on poisoned data

None of these are solved by single-tenant infrastructure. A dedicated database doesn't protect you from a compromised model. A dedicated VM doesn't prevent prompt injection.

What single-tenant does do: it makes your deployment a more attractive target. Fewer eyes on the code. Less frequent patches. A security event is quieter. An attacker who compromises one customer's instance has fewer witnesses.

"Single-tenant is a smaller, less-monitored surface. Multi-tenant means the same hardened code path, the same observability stack, the same patch cycle benefits everyone."

In multi-tenant, every customer uses the exact same code path. When we patch a vulnerability, we patch it once and deploy it once. When we run security audits, we audit once and that covers everyone. When we monitor for abuse, we see the patterns immediately because they're in one system.

How we do isolation in multi-tenant

The trick is proving that isolation is real. Here's what we implement:

1. Kernel namespaces per agent run

Every agent execution runs in its own network namespace, PID namespace, and mount namespace. No two agents can see each other's processes or network connections.

2. Network policies (deny-all default)

We use Kubernetes NetworkPolicy with an explicit deny-all default. Agents can only reach approved integrations.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-isolation
spec:
  podSelector:
    matchLabels:
      tenant: "TENANT_ID"
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: "orchestrator"
  egress:
  - to:
    - podSelector:
        matchLabels:
          type: "approved-integration"
    ports:
    - protocol: TCP
      port: 443

3. Per-tenant encryption keys

Every tenant's data is encrypted with a unique key held in a hardware security module. Even if someone gets disk access, they can't decrypt another tenant's data.

4. Row-level security on every table

The database itself enforces isolation at the row level. A query from tenant A cannot return rows from tenant B, even if a bug bypasses the application layer.

CREATE POLICY tenant_isolation_policy ON agent_executions
    AS SELECT
    USING (tenant_id = current_user_tenant());

CREATE POLICY tenant_isolation_policy ON secrets
    AS SELECT
    USING (tenant_id = current_user_tenant());

CREATE POLICY tenant_isolation_policy ON integrations
    AS SELECT
    USING (tenant_id = current_user_tenant());

Operational benefits (which compound security)

Multi-tenant also makes incident response faster:

Single observability stack. All logs, traces, and metrics flow to one system. Pattern matching and anomaly detection is more effective.
No version skew. Every customer runs the same version. If there's a bug, we fix it once and deploy it once.
Single security audit. One audit covers everyone. No "well, this customer's version is on v1.3 so different rules apply."
Faster incident response. When something goes wrong, we see it immediately across the entire fleet. Correlation becomes trivial.
Easier testing. We test one code path. That same code path runs in production for everyone.

The cost trade-off is real

Single-tenant is operationally cheaper at small scale. One customer, one database, one VM. Done.

Multi-tenant is 10x the ops cost — you need strict isolation, careful resource scheduling, more observability, incident response tooling, and security audits that cover shared infrastructure.

The question is: what do you trade that cost for? For us, it's not additional safety. The safety comes from the isolation mechanisms, not from having separate infrastructure. The cost buys you operational visibility and incident response speed — which, paradoxically, makes you more secure than single-tenant.

When single-tenant actually makes sense

We're not ideological about this. We offer single-tenant for customers who need it:

Regulatory air-gap requirements. Some industries require completely isolated infrastructure for compliance.
Sovereignty requirements. Some countries mandate that data never leaves national borders and never shares infrastructure.
Specific contractual obligations. Some enterprise deals require dedicated resources as a contract term.

In those cases, we deploy single-tenant. But we charge honestly for it — we pass the 10x ops cost to the customer. And we're honest about what single-tenant buys you: isolation of the compute layer, not of the threat model. The agent itself still has the same risks.

The security conversation is changing

Enterprise security is moving away from "isolation through separation" and toward "isolation through control." Multi-tenant with strong isolation mechanisms is becoming the standard for AI workloads. Single-tenant infrastructure gives you a false sense of safety — and often introduces new risks through operational complexity and version fragmentation.

The next time a prospect asks "do you offer single-tenant?" — the real question they're asking is "are you secure?" Our answer is: yes, and multi-tenant is how we prove it.