What is the difference between row-level security and user-centric authorization models?

Row-level security controls access to specific records in a datastore. User-centric authorization models decide access based on the user, their role, their relationships, and the action being attempted. That difference matters because many application risks are not just about reading a row, but about whether a user should be allowed to create, update, or reassign it.

Why This Matters for Security Teams

Row-level security and user-centric authorization both answer the same business question, who may touch which record, but they enforce it at different layers and with different assumptions. Row-level security lives close to the datastore, so it is effective when the main requirement is record filtering across many applications. User-centric authorization lives in the application and evaluates the person, role, relationship, and requested action, which makes it better when permission depends on intent, ownership, workflow state, or business context.

The practical difference matters because security failures often happen when teams treat record visibility as equivalent to record authority. A user may be able to see a row but should not be able to edit, transfer, approve, or delete it. That distinction becomes visible in application logic, audit trails, and exception handling, not just in database queries. In practice, many teams discover this only after a workflow bypass or privilege abuse has already happened, rather than during design.

How It Works in Practice

Row-level security is usually enforced by the database engine or datastore policy layer. The system applies a predicate to every query, so the caller only receives rows that match a rule tied to the session context. That makes it strong for reducing accidental overexposure, centralising enforcement, and preventing developers from forgetting a filter in one code path. It also tends to work best when access decisions are simple and stable, such as tenant isolation, ownership, or department-based visibility.

User-centric authorization is broader and more expressive. The application evaluates whether a user can perform a specific action on a specific object, often using role-based checks, attributes, relationships, ownership, and state. It can separate view, create, update, assign, approve, and revoke permissions, which is essential when the same record may be visible to many people but mutable by only a few. This model is also where business rules usually belong, because the application knows the meaning of the action, the workflow stage, and the side effects.

Row-level security answers, “Which rows can this session retrieve?”
User-centric authorization answers, “Can this user do this action to this object right now?”
Row-level security reduces data leakage risk.
User-centric authorization reduces business-logic abuse and privilege misuse.

The strongest design usually combines both. Use row-level security as a guardrail for data access, then keep action authorization in the application so the system can distinguish read from write, owner from delegate, and normal from exceptional workflows. That separation also improves auditability, because the database can show what data was exposed while the application can show why an action was allowed.

These controls tend to break down when teams assume database filtering alone can enforce complex workflow approvals, cross-record relationships, or delegated actions.

Common Variations and Edge Cases

Tighter access control often increases application complexity, requiring organisations to balance simpler enforcement against richer business rules. The edge cases are where the model choice matters most: shared records, partial ownership, temporary delegation, and records whose visibility differs from their editability. Guidance is consistent on the principle, but implementation details vary because not every platform supports the same level of policy expression.

One common variation is tenant scoping in multi-tenant systems. Row-level security is often the right first line of defence there, because it enforces tenant boundaries mechanically. Another is relationship-based access, where a user can act on records connected to them through a team, case, or approval chain. That is usually a user-centric pattern, because the decision depends on business relationship and action semantics, not just row ownership.

Another edge case is reporting and analytics. Teams sometimes want broad read access for reporting while keeping mutation rights tightly constrained. In that situation, row-level security may be sufficient for exposure control, but user-centric authorization is still needed to protect write paths and privileged operations. The main risk is overloading one model to do the job of both, which creates brittle rules that are hard to test and harder to audit.

When the application has many distinct actions on the same record, user-centric authorization usually becomes the clearer model, while row-level security remains a useful containment layer for data access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-4 — Access Permissions Management	Covers managing access rights to data and functions at a level relevant to row and action controls.
Recommendation — Apply PR.AC-4 to separate read access from action permissions and review them independently.
CIS Controls v8	6 — Access Control Management	Directly addresses account and access governance for enforcing least privilege across records and actions.
Recommendation — Use CIS 6 to define and review who can view, update, approve, and reassign sensitive records.

Practitioner Guidance

What to prioritise: Decide first whether the main problem is record exposure or business-action authority. If the requirement is simply “who can read this row,” row-level security may be enough; if the requirement includes approve, transfer, edit, or revoke, the application needs a user-centric policy layer as well.

What to verify: Verify that read access and write authority are tested separately. A common mistake is to validate only that a user cannot see a row, then miss the fact that the same user can still update it through a different endpoint, bulk operation, or workflow transition.

Practitioner takeaway: Treat row-level security as a data boundary and user-centric authorization as a decision boundary, because strong systems need both when visibility and authority do not perfectly overlap.