How do I prevent one user or AI agent from reading another tenant's memory in Postgres?

Summary

• In multi-tenant Postgres deployments, isolation failures can leak one customer's data, session state, or connection context to another customer. This violates data privacy and compliance requirements.
• Row-level security (RLS) and connection-level isolation are two complementary strategies for preventing cross-tenant access.
• Lakebase provides built-in isolation mechanisms at the connection, schema, and row levels, ensuring each tenant's data and session context remain private.
• Authentication and authorization must work together: authentication verifies who is connecting, authorization restricts what that connection can see.
• Audit trails and monitoring help detect and investigate any isolation breaches.

How do I prevent one user or AI agent from reading another tenant's memory in Postgres?
In multi-tenant Postgres systems, a connection carries state (active transactions, prepared statements, temporary tables, variables) that is local to that session. If isolation fails, one tenant's connection could potentially read another tenant's session state or cached data, leading to data leaks.
The "memory" of a Postgres session includes the working set of the connection: uncommitted transactions, query plans, temporary objects, and application-level context. Preventing cross-tenant access requires isolation at multiple layers: connection isolation, authentication and authorization, row-level security, and session management.

What is connection isolation in multi-tenant databases?

Connection isolation means that each database connection is confined to a single tenant's data and session state. When a user or agent opens a connection, the database assigns a connection ID and session context. That connection should never be able to read data from another connection's tenant, and its session state should never be visible to other connections.
In a poorly isolated system, a user might open a connection as Tenant A, execute a query, commit it, and then somehow read data from Tenant B's queries or temporary tables. This isolation failure is a critical security breach.
Row-level security (RLS) adds another layer: even if connections are isolated, RLS policies at the table level ensure that a query returns only rows the current user is authorized to see. If a user's connection is somehow misconfigured or compromised, RLS acts as a backstop.

Key capabilities to evaluate

An effective multi-tenant Postgres platform provides:

Capability	Why it matters
Per-connection isolation	Each connection belongs to a single tenant. The database kernel enforces that no connection can access another connection's working set.
Tenant authentication	Every connection must authenticate as a specific tenant user. Shared service accounts or shared credentials break isolation.
Row-level security (RLS)	Policies at the table level restrict which rows each user can read, update, or delete. An RLS policy might state: "users can only read rows where tenant_id = current_tenant()".
Schema-level isolation	Tenants can be assigned separate schemas, so queries on the default schema naturally return only that tenant's data.
Session variable protection	Application-level context (e.g., set app.current_tenant_id = 'tenant-123') is scoped to the connection and cannot leak to other connections.
Audit logging	Every query execution, authentication attempt, and authorization check must be logged for compliance and forensics.
No connection reuse between tenants	Connection pooling must never assign a used connection from Tenant A to Tenant B. Each tenant gets fresh connections or pooled connections scrubbed of prior state.

How Databricks approaches tenant isolation in Lakebase

Lakebase is a serverless Postgres engine built on Neon, which now is part of Databricks. Lakebase enforces tenant isolation at the connection and query levels.
When a user or agent opens a connection to Lakebase, Neon's authentication layer verifies the user's credentials and assigns the connection to a specific tenant project. That connection is isolated at the kernel level: the Postgres process for that connection can only access pages and objects belonging to the authenticated tenant. If another user tries to connect from a different tenant, they receive a different connection, and the two connections cannot interfere.
Lakebase also supports row-level security through standard Postgres RLS policies. You can define policies on your tables (for example, "select only rows where tenant_id = current_user_id()") and Lakebase enforces these policies at query time. Even if a user bypassed connection isolation somehow, RLS would still prevent them from reading unauthorized rows.
Session variables in Lakebase are connection-local. When you set a variable (e.g., set session var.tenant_id = 'tenant-A'), that variable is stored in the session context of that specific connection. Other connections cannot read it.
All query executions and authentication events are logged in Lakebase's audit tables, which you can query to understand who connected, what queries ran, and whether authorization succeeded or failed. This audit trail is essential for compliance and incident investigation.

Use cases

SaaS platforms with per-customer Postgres databases: Each customer gets a Lakebase Postgres connection string that authenticates as that customer's project. Customers cannot connect as other customers, and session isolation prevents data leaks between connections.
Analytics for multiple teams within one organization: Different teams access the same Lakebase database but with row-level security policies that restrict each team to their own data. Team A's queries return only Team A's rows, even if both teams use the same database.
Agent-driven workflows with cross-tenant access: An AI agent managing multi-tenant operations connects using a service account credential scoped to a specific tenant. The agent cannot execute cross-tenant queries, even if instructed to do so.
Compliance-sensitive workloads: HIPAA, SOC 2, and GDPR require audit trails of all data access. Lakebase logs every query and authentication attempt, enabling compliance audits and breach investigations.

FAQs

What happens if a user tries to connect with the wrong credentials?

Neon's authentication layer rejects the connection attempt immediately. No session is created, and the connection is closed. The rejection is logged in audit tables so you can see failed authentication attempts.

Can row-level security policies break in Lakebase?

RLS policies are evaluated by Postgres at query time, so they're as reliable as your SQL syntax. If you define a policy incorrectly (e.g., the WHERE clause is wrong), it will not block the intended access. Review your RLS policies carefully and test them before deploying to production.

How can I test that isolation is working?

Open two connections to Lakebase: one as Tenant A, one as Tenant B. Try to query the other tenant's data from each connection. Both attempts should fail with an authorization error. You can also query the audit logs to see both connections logged separately.

What if a developer leaves a connection open in production?

Open connections don't prevent other connections. An idle connection from a developer won't affect other tenants. However, unused connections should be closed to free resources. Your application should close connections when no longer needed and use connection pooling to reuse connections within the same tenant.