AppsAutessaDB

Row-level security and access · AutessaDB

Row-level security

AutessaDB has row-level security (RLS) for every caller. A security role carries a row rule per table, a filter in the same shape as a query, that decides which rows its members see, with placeholders such as $CURRENT_USER_ID and $CURRENT_USER_TEAMS so one rule works for everyone. The rule applies whether the request comes from a person, a tool, an agent, a script, an app or an API key.

Goes beyond a typical managed database
Role · Regional sales → table policy: customerswriteCheck: SAME_AS_READSAMPLE

Row filter

regionIN$CURRENT_USER_TEAMS
archivedEQUALSfalse
calleracting asrows visible
persondana@ (team west)312
agentruns as dana@312
API keyown role: reporting1,284
public app visitor$CURRENT_USER_ID unset0

-- the problem

Security written in application code leaks through the next client

When "sales reps see only their region" lives in one app's code, the next script, export or AI agent skips it. AutessaDB evaluates row rules in the database for every request, so a new client cannot accidentally see more than the person or key it acts as.

What you get

  • Row rules use the standard WHERE format, so anything you can filter on you can secure on.
  • Placeholders: $CURRENT_USER_ID, $CURRENT_USER_EMAIL, $CURRENT_USER_TEAMS, $CURRENT_USER_ROLES, $CURRENT_CUSTOMAPP_USER_ID, $CURRENT_CUSTOMAPP_ACCESS_LINK_ID and $CURRENT_CUSTOMAPP_USER.<column>.
  • A placeholder the caller cannot fill, such as a user id for a public app visitor, matches no rows.
  • Edit checks control changes: NONE, SAME_AS_READ (the default in the builder) or CUSTOM with its own write filter.
  • Inserts must land inside what the caller can see; a row the caller's own rules would hide is refused and nothing is saved.
  • Someone covered by several roles sees the union of what those roles allow.
  • Turn on "Contains sensitive records" and set a default role so everyone you share with gets the rule automatically.
  • Errors are plain: "You don't have access to column name" or a note that a row would fall outside what you can see.

-- how it works

How does row-level security work in AutessaDB?

  1. Create a role

    Under AutessaDB roles, create a role and add a table policy for each table it covers.

  2. Write the row rule

    Build the filter in the row predicate builder, for example owner_email EQUALS $CURRENT_USER_EMAIL, or region IN $CURRENT_USER_TEAMS.

  3. Choose the edit check

    SAME_AS_READ keeps people from moving a row outside their own view; CUSTOM sets a separate write rule.

  4. Assign and enforce

    Assign the role to people, teams, company roles, apps or keys, and turn on row-level security for the table.

-- every option

Row rule placeholders and edit checks

optionwhat it does
$CURRENT_USER_ID / $CURRENT_USER_EMAILThe person's user id, or their verified account email.
$CURRENT_USER_TEAMS / $CURRENT_USER_ROLESThe person's teams or company role names; use with IN or NOT_IN.
$CURRENT_CUSTOMAPP_USER_IDA Custom Auth app visitor's account id.
$CURRENT_CUSTOMAPP_ACCESS_LINK_IDA personal access link visitor's id.
$CURRENT_CUSTOMAPP_USER.<column>A column of the signed-in visitor's own row, such as region.
writeCheck NONEUpdates allowed on any row the member can see.
writeCheck SAME_AS_READRows must still match the row rule after the change.
writeCheck CUSTOMRows must match a separate writePredicate.
rlsEnforcedTable setting (owner or ADMIN) that turns row security on, with a default role for grantees.

-- example

Turn on row-level securitybash
autessa autessadb roles list
autessa autessadb roles create --json '{...}'
autessa autessadb tables update-settings --tableId ayXduiaLeFKh --json '{"rlsEnforced":true}'

Full reference in the AutessaDB CLI docs and the API reference.

-- permissions

Who can do what?

accesscan
Table ADMINCreate or change roles for tables they administer (a role can be changed only by an admin of every table it touches).
Owner / ADMINTurn row-level security on and set the default role.
Everyone elseSees and changes only the rows their roles allow.

-- relations

How it connects

autessadb feature

Security roles

Where row rules, edit checks and column rules live.

autessadb feature

Column masking

Pair row rules with masked or hidden columns.

autessadb feature

App backend

Scope each app visitor to their own rows.

autessa platform

AI agents

Agents inherit the rules of the identity they run as.

-- faq

Questions about row-level security

Does AutessaDB row-level security apply to AI agents?

Yes. Every request, from a person, tool, agent, script, app or API key, is evaluated against the roles of whoever it acts as.

Can someone move a row out of their own view?

Not with the default SAME_AS_READ edit check, which requires a changed row to still match the row rule. CUSTOM edit checks use a separate write rule.

What happens if a user is in several roles?

They see the union of what those roles allow.

What if I share a table but set no default role?

On a table marked as containing sensitive records, people you share it with see no rows until a role covers them, so access fails closed.

$ autessa autessadb tables create

Try row-level security in AutessaDB

Row rules decide which rows each caller sees, with placeholders for the current user, teams, roles and app visitors, and edit checks for changes.

Read the AutessaDB guide or install the CLI.

100% customizable, code and all

Make AutessaDB fully your own.

Use it out of the box, then change anything. Ask Autobot, Autessa’s AI builder, for a new field, screen, report, workflow or agent and it builds it into your copy of the app. Or open the code and edit it yourself. Nothing is locked: the app, its data and its code are yours.

Start free and make it yours