What Grenier does with your data

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 running locally on the Grenier server (we use Ollama). The model produces 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.

We do not call OpenAI, Anthropic, Google's Gemini API, or any other external model provider with your raw content. Local inference is non-negotiable for us.

Cryptographic admin-blindness

Your most sensitive content — Gmail and LinkedIn message subjects, snippets, summaries, drafts, briefs, and sent-mail previews — is encrypted at rest with a per-user key that we cryptographically cannot read on demand. The master key that protects each per-user key is held in an external Key Management Service (HashiCorp Vault), not in our database and not in our environment variables.

What this means in practice:

• A Grenier admin with full database access cannot read your message bodies.
• A leaked database backup is useless without the KMS-held master key.
• Every decrypt operation goes through Vault and is recorded in its audit log.

What is not yet encrypted (so we don't overclaim):

• Contact display fields (name, company, title) remain in plaintext — encrypting them today would break dedup, search, and the normalized indexes that make Grenier fast. A follow-up phase will address this with token-encryption and searchable hashes.
• Email addresses on contacts remain in plaintext so the add-as-contact review UI can show you who is being matched.
• This protection assumes Vault is operated by a different principal than the Grenier app. A single operator who controls both layers could still bypass it.

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 or notes (encryption keys are server-side; we are working on a customer-managed-key path).

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.