Security, policies and audit

Sovaria decides every request with three layers: who is calling (session or key), project access policies (which services and actions a caller may use), and row-level security in the database (which rows).

#Project access policies

Policies are short rules written in Sovaria's policy language and managed under Policies. They cover tables, documents, storage, realtime channels and functions. Templates cover the common cases (owners only, signed-in read, staff write, own folder, own channel).

# Signed-in users may read the catalogue; only staff may change it
ALLOW IF ctx.actor.is_anonymous == False AND ctx.action == "SELECT"
ALLOW IF "STAFF" IN ctx.actor.roles

#Test before you ship

• Simulation runs a request against your policies without touching data and shows which rule decided it.
• Security advisor (Policies → Advisor) flags tables without row-level security, public buckets and risky keys.
• Test session on a user lets you run real queries as that user.

#Audit log

Sign-ins, key and policy changes, deploys, migrations and admin actions are recorded. See them in Logs & Audit, export them, or stream them to your own tools with log drains.

sov logs api

#Isolation guarantees

• Projects never share data, users or keys.
• Every console page and API call checks membership on the server — a URL alone never grants access.
• Secrets (function secrets, OAuth client secrets, SMTP passwords) are encrypted at rest and never returned after you save them.
• Query values are bound by the database, never spliced into SQL.

Found a vulnerability? Please report it to tech@sovaria.in.