Row-Level Security for Non-Human Identities

The query hit the database, but the wrong rows showed up. It wasn’t a human mistake. It was a service account with broad read permissions pulling data far beyond what it needed.

Non-human identities — API keys, service accounts, machine users — are everywhere. They automate processes, run background jobs, sync systems. But most Row-Level Security (RLS) setups are built for humans. When machines query the database, they often bypass granular rules. This is where breaches, leaks, and compliance failures begin.

Row-Level Security is the mechanism that filters rows based on identity. When the identity is a person, mapping roles to allowed rows is straightforward. When the identity belongs to a program, you need a stronger approach. A machine doesn’t have a user interface reminding it of boundaries. It will take whatever the query returns.

To lock down non-human identities, start with explicit role mapping. Assign every service account a unique identity in the database. Do not reuse human roles. Build RLS policies that match service identities to precise row filters. Use attributes like organization ID, resource tags, or tenancy markers so every automated query receives only the rows it is supposed to see.

Audit logs must track non-human identity access with the same rigor as human requests. Monitor query frequency and payload size. A sudden spike or a request for cross-tenant data from a background job is a red flag. Combine RLS enforcement with token scoping so credentials cannot be reused outside their defined purpose.

The cost of ignoring RLS for non-human identities is high — regulatory action, lost trust, leaked data. The solution is simple but requires discipline: every identity, human or not, must pass through the same row-level gates, no exceptions.

Want to see non-human identities locked down with Row-Level Security in action? Build it today on hoop.dev and see it live in minutes.