Privacy promise — version v4
What Grenier does with your data
This is the long version of what you accept when you sign up. Plain language, no dark patterns.
What Grenier reads
If you connect Gmail, Grenier reads the bodies of your messages (the "gmail.readonly" scope from Google). It needs the full text — not just the subject and sender — so it can understand what each conversation was about and how you typically write to that person.
If you upload a LinkedIn data export (CSV or ZIP), Grenier reads the full contents of every file you provide.
If you connect Google Calendar, Grenier reads event titles, descriptions, attendees, and times.
How Grenier uses it
Every message body and CSV row is processed by a language model to produce a short summary capturing the topic, the relationship cues, and your tone. That summary — plus the basic metadata (sender, recipient, date) — is what gets saved. The original text is discarded after the summary is written.
By default that summarization runs on Groq, an external inference provider based in the United States. We send Groq the message text only to generate the summary. Groq operates under zero data retentionfor our account: your content is not stored after the response is returned, and Groq is contractually barred from using it to train or fine-tune any model. If Groq is unavailable, we fall back to a language model running locally on the Grenier server (Ollama). We do not call OpenAI, Anthropic, or Google's Gemini API with your content.
We keep an encrypted log of the prompts and responses sent to the model for debugging and quality work. By default a Grenier admin cannot read your prompt or response text in that log — only operational metadata (timestamp, type, model, latency). You can opt in to let our team read your prompts to improve prompt quality under Settings → Privacy (“Help improve Grenier's AI”); it is off unless you turn it on. This is an access-control rule at our admin tools, not a cryptographic guarantee.
Encryption tiers and admin-blindness
All sensitive content is encrypted at rest under a per-user data encryption key (DEK). Each DEK is wrapped by a master key held in HashiCorp Vault Transit — not in our database and not in our environment variables. This defends against offline threats: a stolen database dump without access to Vault cannot be decrypted.
The Grenier app holds a Vault token and can unwrap a user's DEK on demand to read message summaries, subjects, snippets, and history. That access is gated by Vault's audit log — every DEK unwrap is recorded. A 5-minute in-process cache means one Vault call covers roughly 5 minutes of field-level decrypts, so the audit log records unwrap events, not per-field accesses.
Your private notes are different. They are encrypted under a key derived from your password — a key the operator cannot open, even with full database access or Vault access. This is the only field where operator-blindness is a cryptographic guarantee rather than an access-control policy. If you lose your password and recovery code, your notes are unrecoverable.
Field-level summary:
| Field | Encryption | Operator-readable? |
|---|---|---|
| Message summaries, subjects, snippets, history | Per-user DEK — Vault-wrapped | Yes — under Vault audit |
| OAuth refresh tokens | Per-user DEK — Vault-wrapped | Yes — under Vault audit |
| Private notes | Password-derived key — user-held | No — truly admin-blind |
| Contact name, company, title, email | Plaintext | Yes |
This protection assumes Vault is operated by a different principal than the Grenier app. A single operator controlling both layers could still read DEK-encrypted content. The notes user-key tier is not subject to this caveat — it requires your password, period.
The operational details — threat model, key rotation, Vault audit-log reading, and the graceful-degradation runbook for when Vault is unreachable — live in our public ops doc: docs/security/admin-blind-encryption.md.
What gets stored
- Contact records: name, email, company, title, phone, LinkedIn URL.
- Per-interaction summaries (short, AI-generated, redacted of obvious PII).
- An encrypted rolling history per contact, used to draft better tends.
- Free-form notes you write — encrypted at rest with AES-256-GCM.
- OAuth refresh tokens — encrypted at rest with AES-256-GCM.
We do not store the raw text of your emails or LinkedIn export after summarization. We do not store message attachments. We do not store calendar event bodies past the summary stage.
Who sees it
You see it. Grenier operators see aggregate metrics and error logs but do not have routine access to your contact summaries. Message summaries are encrypted at rest and operator access requires an audited Vault call. Private notes are encrypted with a user-held key the operator cannot open.
We do not sell, rent, or share your data with advertisers, data brokers, or model training pipelines.
Your controls
- Export: Download everything we have on you as a ZIP from Settings.
- Delete: Request deletion from Settings; we hard-delete after a 30-day grace period.
- Disconnect: Revoke Gmail or Calendar access at any time from Settings or your Google account dashboard.
- Per-contact opt-out: Mark any contact "do not surface" to exclude them from tends.
When this changes
If we ever change what Grenier reads, where it's processed, or what we store, we bump the privacy promise version and ask you to re-accept before any new behavior kicks in. We do not quietly expand scope.