RLS は Row-Level Security の略で、データベースが表の 1 行ごとに、読める人と書き換えられる人を判断する仕組みです。全社の案件が 1 つの表に入っていても、営業の担当者には自分の案件の行だけを返す、といった決まりをデータベースの側に書いておけます。PostgreSQL の説明書では、表ごとに RLS を有効にし、行を見せる条件（ポリシー）を書く形になっています。
利点は、アプリの側の確かめ漏れを受け止められることです。見せる範囲の確認を画面のプログラムだけで行うと、抜けが出ることがあります。確認を書き忘れた画面や、あとから足した読み出し方（API など）から、見せてはいけない行が出てしまいます。RLS なら、どこから読んでもデータベースが同じ条件で確かめます。AI に社内のデータを探させるときも、頼んだ人の権限のまま読む作りにしておけば、AI が拾える行も、その人が見てよい行に限られます。
設定を誤ると、全部見えてしまいます。PostgreSQL の説明書によれば、RLS を有効にしていない表は、表を読む権限のある人に全部の行が見えます。表の持ち主や特別な権限を持つ利用者は、通常は RLS の対象外です。アプリが表の持ち主の権限でつないでいると、条件は効きません。条件を何本か書くと「または」で組み合わさるので、全員に見せる条件が 1 本混ざると、全部の行が見えることがあります。反対に、有効にしたのに条件を書かなければ、1 行も見えません。作ったら、役割ごとの試しのアカウントで、見えてよい行だけが見えるかを試験します。
見せる範囲そのものは、閲覧権限として先に決めておきます。RLS を持つかどうかはデータベースの種類によって違うので、使うデータベース（MySQL・MariaDB など）の機能を、作る前に確かめます。