Multi-tenant software stores many customers' data in the same tables. The common way to keep them apart is application code that adds a tenant filter to every query. That works until one query forgets the filter, and then one customer can read another's data. Row-level security moves the rule into the database: a policy on the table decides which rows are visible, and every query passes through it whether or not the application remembered.
In PostgreSQL, a table with row-level security enabled applies its policies to normal queries, typically comparing a tenant column with a value set for the current connection or transaction. Two details decide how strong it is. By default the table's owner bypasses the policies, which matters because applications often connect as the owner; FORCE ROW LEVEL SECURITY makes the policies apply to the owner too. And the policy should fail closed: if the tenant setting is missing, the query should return nothing rather than everything.
For AI agents, the stakes are higher than for a typical app. An agent issues many varied calls, often composed by a model, and the system has to hold its boundaries no matter what the model asks for. Isolation enforced in the database does not depend on every code path being right.