Why AI in CAFM is unsafe without Row-Level Security

Every customer of every legacy CAFM platform is asking for AI. Natural language queries against compliance data. Predictive risk alerts. Automatic gap analysis on uploaded documents. The asks are obvious, valuable, and for most legacy vendors unsafe to deliver.

This post explains why. It is for facilities directors, compliance managers and IT leaders evaluating CAFM platforms with AI features. The technical concept that decides whether AI is safe in your CAFM is called Row-Level Security, and if your vendor cannot answer the question “does your database have it?” with a clear yes, you have a procurement problem.

The shape of the problem

A CAFM platform stores compliance data for many tenants (different estate operators, different property portfolios, different building owners) in the same physical database. Tenant isolation is the property that says tenant A’s users can only see tenant A’s data. In a non-AI world, this is enforced by the application code: every query the application generates includes aWHERE tenant_id = ? filter, and the developer is responsible for never forgetting it.

AI breaks this model. When you put a large language model in front of your data, the LLM may compose queries you didn’t hand-write. It may search across tables, combine evidence, summarise across records, or call tools that hit your database directly. Every one of those code paths must remember the tenant filter. One missed filter = a cross-tenant data leak. In compliance data (where the contents include named buildings, named contractors, named occupants and named regulatory failures) that is a Notifiable breach.

What Row-Level Security actually is

Row-Level Security (RLS) is a feature of modern relational databases that lets the database itself enforce, on every query, which rows a given user is allowed to see.

With RLS turned on, the database executes every query against a policy. A typical compliance-platform RLS policy says something like:

• The current user must belong to the same organisation as the row’s org_id.
• The current user must have the role VIEWER, EDITOR, or ORG_ADMIN.
• The row must belong to a building the user has access to via building-level access control.

The policy is checked before any rows are returned, regardless of who or what asked. Application code, AI agents, MCP servers, BI tools, raw SQL consoles. All of them see only the rows the policy permits. The security is structural, not procedural.

Why legacy CAFM databases don’t have RLS

Most legacy CAFM platforms were built between 2005 and 2015, on databases that either don’t support row-level security at all, or don’t support it in a way compatible with how the application is wired up. Common patterns we see:

• Older SQL Server / Oracle deployments where RLS exists but isn’t used because the app authenticates as a single shared service account. Row-level policies require per-request user identity to be propagated to the DB, which most legacy apps don’t do.
• Custom proprietary stores where there is no concept of row-level policy at all, and tenant isolation is entirely a property of the application’s query templates.
• NoSQL document stores where document-level access control exists but is rarely consistent across collections.

Adding RLS retroactively to a 10-year-old CAFM is not a feature flag. It requires: propagating the user identity through every layer of the application; rewriting every query to operate on the “tenanted” security context; backfilling policies on every table; auditing every code path that hits the database. In practice, that is a 2–3 year programme of work, and most legacy vendors won’t do it because the existing application generates the revenue.

What this means in procurement

If you are evaluating CAFM platforms with AI features, the question that meaningfully separates safe from unsafe is:

“Is your database engine enforcing tenant isolation through Row-Level Security policies, applied before any query reaches the application layer? And does that apply to all of your AI agents, document analysis, and natural language queries, without exception?”

The answer should be a clear yes, with a description of the policies in place. Anything that includes the words “our application code ensures”, “we have a service layer that”, or “our AI feature is read-only”is procedural, not architectural, and procedural is exactly what fails when AI composes a query you didn’t expect.

How Zerix is built

Zerix runs on a modern database engine with native Row-Level Security enforced at the database engine. Every table that contains tenant data has RLS policies that constrain reads and writes by:

• Organisation membership (org_id match).
• Role (VIEWER, EDITOR, ORG_ADMIN).
• Building-level access control where applied.
• Compliance category access where applied.

The Zerix AI Assistant, our AI compliance intelligence, runs against the same RLS-secured connection as the application. When the Assistant retrieves data, it sees only the rows the requesting user is authorised to see. There is no mechanism by which the Assistant can return a row that violates the policy, even if the application has a bug, even if the prompt is malicious. The security is architectural.

Why this is durable for years, not features

RLS is the kind of decision you make at platform birth, not at platform feature-launch. It cuts through how user identity is propagated, how connections pool, how queries are composed, how migrations work, how backups operate. A legacy vendor cannot retro-fit it without a multi-year database rebuild, by which time the AI category has moved on twice. That is what we mean when we say Zerix has a structural moat.

If you’d like to see RLS in action, including reading the actual policies the platform runs against, book a demo. We’ll show you the SQL.