1 Tenant isolation, enforced at the database
Every record in Stelaah is scoped to a single workspace and protected by row-level security in Postgres — not just hidden in the interface. Access is default-deny, so one workspace can never read or write another's data, even if a request tries to. This is the foundation everything else builds on.
2 Three-tier access
What a person can see and do follows three layers in order: their plan, then the workspace's settings, then their own role and grants. The interface decides what to show; the database decides what they are allowed to query. The two are kept in lockstep so the visible surface never exceeds the enforced one.
3 Encryption
Data is encrypted in transit over TLS and encrypted at rest in our managed Postgres database and object storage. Application secrets and third-party API keys are held server-side, in protected function secrets, and are never shipped to the browser.
4 Authentication and roles
Access requires authenticated sign-in, and every action resolves to an identified user. Owners, admins, and members see what their role allows, and per-person grants and restrictions let you tune access without rebuilding anything. Administrative "act-as" actions are attributed to the real signed-in user.
5 Backups and recovery
Our infrastructure provider maintains automated backups with point-in-time recovery. Within the product, user data is never hard-deleted by default — deletions are recoverable for a window before permanent removal, with restore points, so a mistake doesn't mean lost work.
6 Audit logging
Meaningful changes are recorded with the actor, a timestamp, and before/after values, in tenant-scoped, append-only logs. That gives you a reliable paper trail of who did what, and when, inside your workspace.
7 Secure development
Changes follow a documented implementation protocol and a security review before they ship, and any new kind of data must carry row-level security in the same change that introduces it. Database schema and migrations are version-controlled and idempotent, so the security model is reproducible rather than improvised.
8 Infrastructure
Stelaah runs on Supabase and Postgres, with files kept in object storage protected by the same workspace scoping as your records. Physical data-center security is handled by certified underlying cloud providers. See the third parties we rely on in our Subprocessors list.
9 Honest AI
Aria works from your real records and labels what it generates; when it isn't sure, it says so, and it never invents a number and presents it as fact. We do not use your workspace content to train third-party foundation models, and you choose your AI provider in settings. The full terms are in our Aria AI Terms.
10 Your data is yours
You own your data and can export everything in a structured, common format at any time. Our handling of personal data you store is governed by our Data Processing Addendum, under which you are the controller and Stelaah is your processor.
11 Responsible disclosure
If you find a security vulnerability, please report it to security@stelaah.com rather than exploiting it. We support good-faith research conducted without harming users or data, and we will not pursue action against researchers who follow responsible disclosure.
12 Compliance and certifications
We would rather show real than impressive. As Stelaah grows, formal certifications will follow, and we will list them here when they are real — not before. If you have a specific security or compliance question, ask us and we will answer plainly.
13 Contact
Security questions or reports: security@stelaah.com.
Related: Data Processing Addendum, Subprocessors, and Privacy Policy.
Back to top