Your data stays yours.

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. Owners and admins can export an Audit Pack from Settings with CSV evidence, retention/deletion evidence, a 13-layer security scorecard, and a printable review summary. Secrets and credential-like fields are redacted from exported payloads.

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. Authorized Stelaah platform operators configure the active provider through a server-side control plane, and provider keys never enter the browser. 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. Deletion requests are handled through a retention workflow rather than a blind hard delete, because some records may need to be retained for tax, accounting, contract, security, or legal reasons. 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 Retention and deletion controls

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.

12 Security review readiness

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, owner/admin Audit Pack export, retention/deletion evidence, a 13-layer 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. For procurement reviews, contact security@stelaah.com and we will answer from current implementation evidence.

13 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.

14 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. Our intended order as we formalize is SOC 2 Type II first, then ISO 27001, with each report made available under NDA once complete. Until then we answer procurement reviews from current implementation evidence rather than a badge. If you have a specific security or compliance question, see the Security & Privacy FAQ and AI Security & Privacy FAQ, work through the Secure Configuration Checklist, or ask us and we will answer plainly.

15 Contact

Security questions or reports: security@stelaah.com.