Deterministic UX in a Stochastic World: RLS Security Moat

Deterministic UX in a Stochastic World: The RLS Security Moat

Developers are building multi-tenant AI applications at a pace that would have seemed reckless five years ago, from personalized assistants to full data analysis tools. Underneath that speed, a real problem is spreading: teams reaching for probabilistic controls to enforce what should be deterministic security. Enterprise trust in multi-tenant AI depends on moving away from that habit, toward strict, database-level isolation.

The vibe-coding hangover: wrappers vs. isolation

Rapid iteration wins in the early days of any disruptive technology. For AI, that produced a culture of assembling API wrappers, prompt templates, and middleware to get a prototype working fast, and many foundational AI products started exactly this way.

That approach carries a real cost once the application goes multi-tenant. Wrapping an LLM endpoint with a custom prompt is easy. Earning enterprise trust requires something else entirely: deterministic isolation. Enterprises need to know, with certainty, that Tenant A's data will never reach Tenant B, regardless of user error, malicious intent, or a model's probabilistic quirks. "Move fast and break things" works for UI experiments. It's a real threat when the thing that breaks is customer data.

The fallacy of prompt-based security

The most common shortcut in multi-tenant AI is relying on prompt engineering for security. Something like:

"You are a helpful assistant for Tenant A. Do not ever reveal information about other tenants or their data. Only use data provided for Tenant A."

That isn't a security policy. It's a polite suggestion to a black box, and a weak security strategy at that.

Large language models are statistical models, not logic engines. They predict the next token from training data; asking one to "never reveal" something is asking a probabilistic system to enforce a deterministic rule, and it will eventually fail. LLMs also hallucinate, confidently generating plausible but wrong output, which means a model could infer or state data belonging to another tenant if that data ever touched its context window. The same flexibility that makes these models useful makes them vulnerable to prompt injection designed specifically to bypass a system prompt's instructions. Guaranteeing that Tenant B's data never enters Tenant A's context window gets harder, not easier, as the system grows, and managing nuanced prompt rules across hundreds of tenants becomes unauditable fast.

Relying on a model's good behavior for security is close to securing a vault with a handwritten note asking people not to steal anything. It misreads both the technology and what data security actually requires.

The RLS security moat: deterministic boundaries with Supabase

The reliable, auditable answer to multi-tenant isolation is deterministic security at the database level. PostgreSQL's Row Level Security does exactly this, and it's straightforward to set up on a platform like Supabase.

RLS defines policies for which rows a user can access, insert, update, or delete, enforced before any data leaves the database. It functions as a hard boundary around the data, not a suggestion to whatever is querying it.

RLS policies live directly on the database tables and get evaluated by the Postgres server itself, on every query, for every row. A query that violates a policy gets rejected outright; there's no negotiation and no probability involved. With Supabase, RLS integrates with its built-in authentication: a logged-in user carries a JWT with claims like user_id or tenant_id, and Supabase exposes those claims as session variables inside Postgres.

A documents table with a tenant_id column might carry a policy like this:

sql

CREATE POLICY tenant_isolation ON documents
FOR ALL
USING (tenant_id = (current_setting('request.jwt.claims', true)::jsonb->>'tenant_id')::uuid);

That policy ensures a user can only see, modify, or delete documents whose tenant_id matches the one extracted from their own JWT.

The insight that matters most: the LLM operates after the database has already enforced its policies. If a prompt, however clever, leads the model to formulate a query reaching outside its permitted tenant_id, Postgres returns an empty set or an access-denied error. The model can still generate text describing data it thinks exists. The actual data stays unreachable.

> "The LLM can hallucinate all it wants, but Postgres physically rejects the query if the JWT doesn't match the tenant."

That's the guarantee that doesn't bend. RLS lets multi-tenant AI agents run inside a deterministic security perimeter no matter how stochastic their reasoning gets underneath, and Supabase makes the setup accessible without a dedicated security team.

Build for trust

Probabilistic AI is everywhere now, which makes deterministic security more important, not less. Prompt-based security is a comfortable shortcut that skips the actual requirements of data privacy and enterprise trust.

The RLS security moat isn't a feature bolted onto an application. It's a foundational primitive for building multi-tenant AI that a business can actually trust with real data. PostgreSQL's Row Level Security, especially through a platform like Supabase, delivers both a good user experience and a real guarantee of data isolation.

The database should enforce isolation. Hoping the model behaves isn't a substitute.

References

Supabase