Why does Postgres RLS create risk when organisations use it for complex authorization decisions?

Why This Matters for Security Teams

Postgres row-level security can look like a neat way to centralise access control, but it becomes dangerous when teams ask it to make decisions that belong in an authorisation layer, not a database predicate. Once policies mix tenant scope, role logic, time, data sensitivity, and application state, the model becomes difficult to reason about and easy to misapply. That is exactly where non-human identities are often over-privileged, especially when secrets, service accounts, and application tokens are not tightly governed. NHI Mgmt Group’s research shows that 97% of NHIs carry excessive privileges, which makes any weak database-side control far more consequential.

The problem is not that RLS is bad. The problem is that it is narrow. It is strong at filtering rows, but it is not a full policy engine for complex, context-rich decisions. Security teams also underestimate how often database access pathways are reused by admins, jobs, and integrations, which creates blind spots that policy authors do not always test. For broader context on the underlying NHI risk landscape, see the Ultimate Guide to NHIs — Key Challenges and Risks and the Top 10 NHI Issues.

In practice, many security teams discover the weakness only after an administrative shortcut, a bad tenant claim, or a direct database connection has already exposed data.

How It Works in Practice

RLS evaluates a policy against each row, typically using session context such as current user, tenant identifier, or application role. That works when the question is simple: should this session see this row at all? It works less well when the real decision depends on who is asking, why they are asking, what time it is, whether the request came from a trusted service, and whether the action is read, write, export, or delete. In those cases, the authorisation logic is better handled in the application or a dedicated policy engine, with the database enforcing only the last mile of row filtering.

Current guidance suggests separating identity, authorisation, and data access as much as possible. Databases should not be the place where all business rules converge. If the tenant context comes from user-controlled input, SQL injection can subvert even a carefully written policy. If credentials are long-lived or shared across services, a compromised NHI can bypass the intended path entirely. That is why broader identity governance and secret hygiene matter as much as the RLS clause itself, as reflected in The 2024 ESG Report: Managing Non-Human Identities and the NIST Cybersecurity Framework 2.0.

• Use RLS for row isolation, not for complex business authorisation.
• Pass trusted tenant and principal context from the application, not from user input.
• Keep credential scope narrow, short-lived, and tied to a specific workload identity.
• Test direct database access paths, batch jobs, and admin tooling separately.

These controls tend to break down in multi-tenant analytics platforms with shared service accounts and ad hoc reporting access because the same database session can be reused across conflicting trust boundaries.

Common Variations and Edge Cases

Tighter database-side policy often increases operational overhead, requiring organisations to balance simplicity against governance precision. That tradeoff becomes sharper in regulated environments, SaaS platforms, and systems with many background jobs, where engineers want one control to cover many cases. Best practice is evolving, but there is no universal standard for using RLS as a primary authorisation engine.

One common edge case is hybrid enforcement. Teams may use RLS for tenant isolation while using the application layer for entitlement checks, approver workflows, and time-based exceptions. That is often the safer pattern because it limits the database to what it can express cleanly. Another edge case is direct database access by analysts or support teams. If those paths are not isolated, audited, and credentialed separately, RLS assumptions can fail even when the policy itself is correct. The broader lesson aligns with NIST SP 800-53 Rev. 5 Security and Privacy Controls, which pushes organisations toward layered, testable controls rather than overloading one mechanism.

Where RLS is used for complex authorisation, the risk increases further if policy changes are not versioned, reviewed, and regression-tested. A small SQL change can alter who sees what across large data sets. That makes operational discipline, not just policy syntax, the real control. In mixed-trust environments with BI tools, replicated data, and privileged operators, RLS is most fragile when teams assume every caller behaves like the application service that was originally designed for the policy.

Related resources from NHI Mgmt Group

• Why do Microsoft-centric identity and device stacks create risk for organisations with mixed endpoints and external identities?
• Why do PowerShell execution policies create risk if organisations treat them as a security boundary?
• Why do shared vaults create risk when organisations rely on standing credentials for privileged access?
• Why do complex LLM workflows create risk without observability?