Per-principal paths
Application operations are scoped to the current principal, with row-level security reinforcing those data boundaries in the database.
For an AI assistant, privacy is a set of data paths, permission boundaries and action controls—not a promise that information never moves. Here is what Habit can responsibly say about those boundaries today.
Data boundary
When you connect a provider, relevant data can move between that provider, Habit’s application services, storage and selected AI processors.
Habit requests provider-authorised permissions for supported sources. The application selects context needed for a brief, response or proposal; privacy should be evaluated across that whole path, not inferred from a label on the interface.
Primary application data is stored in Supabase’s Paris region. A Paris region does not mean every processor or every processing operation stays in Europe. Cross-border processing and data-residency obligations remain questions to assess against the current provider path and legal requirements.
Stored data
Habit combines application-level scoping, database controls and encryption for sensitive stored fields.
Application operations are scoped to the current principal, with row-level security reinforcing those data boundaries in the database.
Sensitive stored fields use AES-256-GCM encryption with a separate encryption key for each principal.
Connected-provider credentials are addressed separately from ordinary application records so access paths remain explicit.
Encryption at rest is not the same as a system where only the user holds a decryption key. Habit’s current architecture is not described as end-to-end encrypted, because authorised application services need to process selected context to provide the service.
Operations
Operational visibility should help diagnose failures without copying private messages into every diagnostic trail.
Habit’s logging approach favours identifiers, statuses and event types rather than the content payloads being processed. This reduces unnecessary exposure while retaining a path to investigate a failed job or an unexpected state.
Selected context may still be sent to configured AI providers when the product needs a model to prepare output. Claims about provider retention or model training must be verified against the applicable provider terms, account settings and contract. This page does not replace that evidence with a universal “never” claim.
Action safety
An assistant can create harm without leaking a record. That is why action authority has its own boundary.
Consequential actions are presented for approval so you can confirm, modify or decline the intended change.
Eligible automation requires a deliberate standing authorisation for that bounded action category; it is off by default.
Calendar updates and deletes remain review-gated rather than inheriting authority from an opt-in to calendar additions.
Your controls
Pausing assistance and disconnecting a provider are distinct from memory management, retention and deletion. Each control needs a defined, verified effect.
Disconnecting a provider stops future authorised access through that connection. It does not by itself establish what retained information is deleted. Retention and deletion behaviour require a verified process and accurate legal disclosure; no immediate or universal deletion claim is made here.
Read the published Privacy PolicyQuestions