Your data stays yours.

Stelaah is built so your work is private, protected, and portable. Isolation is enforced where it counts, at the database, and you can take your data with you at any time. Here is how it actually works.

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.

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.

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.

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.

Every member can turn on two-factor authentication with an authenticator app. Owners and admins can require it for the whole workspace, immediately or after a set number of sign-ins, and can reset it for a member who loses their device.

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.

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.

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.

Stelaah’s database runs on Supabase and Postgres, hosted in the United States, 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.

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.

Owners and admins can turn Aria off for the whole workspace. When it is off, Stelaah sends no workspace content to an AI service, including meeting transcription, the cloud voice and background summaries, and this is enforced on our servers, not only in the interface. The AI providers we use are listed in our Subprocessors list, and the full terms are in our Aria AI Terms.

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.

Workspace owners and admins can define retention policies by record class, place legal holds, request deletion, record export readiness, anonymize customer-controlled relationship data, and view active purge blockers. The retention gate separates customer-facing data from compliance records, and records evidence for retention scheduling, anonymization, blocked purge attempts, and completed purge decisions.

Retention periods are configured by business need, jurisdiction, and record type. Stelaah provides the policy engine and evidence trail; customers should review their legal obligations before setting schedules.

Security reviewers commonly ask whether data is encrypted, where it is stored, how access is enforced, how vulnerabilities are reported, whether operational evidence can be exported, and whether a production audit or penetration test exists. Stelaah’s current answers are straightforward: TLS in transit, managed encrypted storage at rest, United States hosting by default, database row-level security for tenant isolation, two-factor authentication, a workspace AI switch, an owner and admin Audit Pack export, retention/deletion evidence, a 13-layer security scorecard, documented responsible disclosure, and server-side handling for application secrets.

The scorecard is product evidence, not a substitute for third-party attestation. We do not claim a formal SOC 2, ISO 27001, HIPAA, PCI, FedRAMP certification, or completed external penetration test until one is actually complete. Stelaah cannot sign a HIPAA Business Associate Agreement today, so please do not store protected health information in Stelaah. For procurement reviews and security questionnaires, contact security@stelaah.com and we will answer from current implementation evidence.

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.

We would rather show real than impressive. Stelaah does not hold a formal security certification today. 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.

Security questions or reports: security@stelaah.com.

Related: Data Processing Addendum, Subprocessors, and Privacy Policy.