# We already have Auth0 and row-level security. What does this add?

*Published on 2026-10-13T00:00:00.000Z*

*By CipherStash Team*

A layer below them. Your identity provider says who is asking. RBAC decides what they may attempt. Database grants and RLS decide which rows come back. Once a query is allowed, the database returns plaintext. CipherStash decides whether a value can become plaintext, and for whom, inside the key derivation. You keep the other layers.

## Content

## The layers

**Identity.** Your identity provider tells you who is asking. It says nothing about data.

**Application permissions.** RBAC or ABAC decides what a caller may attempt. It is enforced in application code, and bypassed by anything that reaches the database another way.

**Database grants.** What a database principal can reach. Usually the application's service account, which can reach everything.

**Row-level security.** Which rows a query returns for a given principal. The rows it returns are in the clear.

**CipherStash.** Whether the values in those rows can be decrypted, and for whom.

The gap the first four leave is at the bottom. Once a query is allowed, the database reads and returns plaintext. A leaked service credential, a backup, a read replica, a support tool, an agent with a connection string: all of them see the same plaintext the application sees, because the checks live above the data.

## How the last layer works

Every value is encrypted under its own key. Deriving that key needs ZeroKMS to authorize the request, and the request carries an identity. With OIDC federation the request is made as the signed-in user, and a value can be locked to that user so only they can decrypt it. Your own backend, holding valid workspace credentials, cannot decrypt another user's locked values.

RLS is the closest neighbour, and the two compose. On Supabase, RLS controls which rows a caller may query and encryption controls whether the values in those rows can be read.

## Technical evidence

- [Provable access: identity-bound decryption](/docs/solutions/provable-access)
- [Supabase integration: RLS and encryption together](/docs/integrations/supabase)
- [Glossary: RBAC, ABAC, IdP](/docs/reference/glossary)

## Related notes

- [Our agent already has a database user with the right grants. Why isn't that enough?](https://cipherstash.com/notes/our-agent-already-has-a-database-user.md) — Because the database user identifies the agent's workload, not the person it is acting for. Make requests as the signed-in user and lock values to them, and the agent can decrypt those values only on that user's behalf.
- [We don't need to search encrypted data. Why would we need you?](https://cipherstash.com/notes/we-dont-need-to-search-encrypted-data.md) — Most teams don't, and search is optional per column. CipherStash is for data-level access control, and that works with search switched off everywhere.