Security at Saielo

How encryption works (in detail)

Each Saielo account has a unique 256-bit Data Encryption Key (DEK). The DEK is generated server-side on first use by a cryptographically secure random source, then stored in our database in wrapped (encrypted) form — never in plaintext.

The DEK is used to encrypt the contents of your plan: the answers from onboarding, the projections, the check-in history, and your conversation threads. Encryption uses AES-256-GCM, the modern authenticated encryption standard.

The DEK is wrapped using a single master key that Saielo holds as a server-side secret in our Supabase Edge Functions environment. This master key is operated and protected by Saielo. It is not stored on your device, and it is not derived from your password.

When your authenticated mobile session needs to read your plan, our server unwraps your DEK and returns the plaintext key over the secure session channel. Your device then decrypts the plan locally and re-encrypts (or discards) it when you close the app.

What this means: Saielo, as the operator of the master key, can technically unwrap your DEK and read your plan content. We do so only as the application's design requires — to serve your authenticated mobile session, and to power AI features you choose to use.

What this protects against

Database compromise without the master key. If our database were exfiltrated as ciphertext only — for example, a Postgres dump leaked or copied without our Edge Function secrets — the attacker would see encrypted blobs they could not decrypt. The protection against this scenario is real.

What this does not, alone, protect against:an attacker who obtains both our database contents and our master key — for example, an insider with full operator access, or a sophisticated breach that reaches our secret store. We mitigate this through Supabase's role-based access controls, least-privilege secret access, and a small operator footprint (currently: the Saielo founder alone). We are honest that the protection is operational, not cryptographic.

Lawful access requests.Saielo retains the ability to produce plan contents in response to a valid legal order, because we hold the master key. We will narrow this capability when our architecture supports it (see “What is next” below).

What this does not protect against

Honest disclosure: encryption is one layer of defense. It does not protect against:

• Compromise of your device. If someone has unlocked physical access to your iPhone, your plan is readable.
• Compromise of your account credentials. If someone gets your sign-in credentials, they can sign in on a new device and decrypt your plan.
• Future regulatory requirements. If a future law requires us to weaken our encryption, we will explore every alternative — including ceasing operation in that jurisdiction. We have not accepted any backdoor.

What is next

The encryption model above is conventional server-side at-rest encryption. We have chosen it for now because it lets Saielo offer features like account recovery and AI assistance without imposing irreversible passphrase responsibilities on you on day one. We are explicit that this is a different posture from a zero-knowledge architecture in which Saielo would be technically unable to read your data.

We are evaluating a future shift to a client-derived key model in which the master key would no longer be server-resident, and Saielo would lose the ability to decrypt your plan. When and if we make that change, we will describe the new model on this page before we ship it, including the migration plan for existing data and the trade-offs we are asking you to accept.

Until then: assume Saielo can decrypt your plan if compelled, and treat the strength of our other commitments (no advice, no bank linking, no data sales, no third-party sharing) as the load-bearing privacy guarantees Saielo offers today.

Reporting a security issue

If you discover a security vulnerability, please email [email protected]. We will respond within 48 hours. Responsible disclosure is appreciated and will be acknowledged publicly with permission.

We do not currently run a paid bug bounty program. We may add one as the user base grows.

Audits and certifications

Saielo is a young product. We have not yet undergone formal security audits (SOC 2, ISO 27001, etc.) — these are typically pursued at scale. As we grow, we will pursue them.

What we have today: a deliberate architecture, the use of standard cryptographic primitives, no shortcuts on user data protection, and a public commitment to keep it that way.