In software that serves many customers from one database, the critical risk is one customer accidentally seeing another's data. RLS addresses this at the deepest level: instead of trusting every piece of application code to add the right filter, the database refuses to return rows a user is not allowed to see.
A policy defines the rule — commonly that a row is only visible when its owner or tenant identifier matches the current user. Every query is then transparently constrained by that policy, so even a forgotten filter in the application cannot expose the wrong data.
RLS is a defence-in-depth measure: it does not replace careful application code, but it provides a backstop enforced by the database. KAZI relies on explicit tenant scoping and database-level protections to keep each account's data isolated.