Helene — Privacy Policy

Effective date: 2026-05-16 Maintainer: Jiho Yang ([email protected])

This is the privacy policy for Helene, a personal-knowledge application that captures notes and conversation excerpts from AI assistants and stores them — along with any documents your AI client synthesizes from them — in a sandboxed folder of the user's own Google Drive. It is written to be read, not skimmed. The architecture is unusually privacy-respecting because the data lives in your Google Drive, not ours — but "respecting" is not "untouchable," and the honest disclosures below explain where the seams are.

If you only read one paragraph, read this one: Helene's servers do not store the contents of your memories. Your memories live in a sandboxed folder of your Google Drive that only Helene can see. Helene's servers hold one thing — an encrypted login token used to talk to your Drive on your behalf — plus a thin audit log of which API endpoints you called and when. We do not retain message bodies, titles, embeddings, or any derived metadata.

1. What Helene collects

1.1 Identity (from Google)

When you sign in with Google, Helene receives:

• Your Google account ID (the opaque numeric sub)
• The email address associated with that account
• An OAuth refresh token authorized for the drive.appdata scope

We do not request profile photos, contacts, calendars, or any other Google data. The Drive scope we request (drive.appdata) only grants access to a sandboxed application folder Helene creates on first use; it cannot read or write any other file in your Drive, and your appDataFolder is invisible to other apps and to Google's own AI surfaces (Gemini, Workspace AI), which cannot enumerate files in another app's sandbox.

1.2 Audit logs

Every API request your client makes to Helene's Worker is logged with:

• A request identifier (UUID)
• Your Google account ID
• The HTTP method (GET, POST, etc.) — recorded as read, write, or tool_call
• A coarse resource type (e.g., mcp or sync)
• For MCP tool invocations only: the name of the tool that was called (e.g., save_memory, search_memories, list_memories). This is the tool name, not its arguments or output.
• An ISO-8601 timestamp

We do not log: request bodies, response bodies, user-agent strings, the arguments or results of any MCP tool call, or any content of your memories. We record that you called save_memory; we do not record what you saved. We record that you called search_memories; we do not record what you searched for. The audit log exists for incident response and answering "is the Service working for this user" — to spot patterns like failed-auth bursts, unusual deletion spikes, or onboarding cliffs; and to send the operator a daily digest of service-usage activity (counts and per-user activity timestamps) so the operator can monitor whether the service is being used and identify funnel issues. The digest is sent to a single operator inbox and that inbox has a 90-day auto-deletion policy on these messages. No memory content, search queries, or tool inputs/outputs are ever included.

1.3 MCP token records

When you connect Helene to an AI client (Claude, ChatGPT, etc.) via the MCP connector URL, Helene stores a record of that connector token in our database: a one-way cryptographic fingerprint of the token (so it can be verified on inbound requests), an issued-at timestamp, and a one-year expiry. The token plaintext is never stored — only its one-way fingerprint.

1.4 What your AI client sees

When an AI client uses your connector URL, the request flows AI → Helene Worker → your Google Drive. The AI client sees the memory bodies it asked for; Helene's Worker sees them in transit (see § 4); Google sees the underlying Drive operations. We do not retain anything from these calls.

2. What Helene does not collect

The list of things Helene's infrastructure deliberately does not store is longer than what it does:

• The body of any memory you write
• Titles, tags, summaries, or any metadata derived from your memories
• Embedding vectors, search indexes, or any pre-computation of your content
• The synthesized project documents your AI client produces — those are written directly to your Drive without server-side processing
• Long-lived Google access tokens (we mint short-lived ones per request)
• Your user-agent string, geolocation, or device fingerprint
• Behavioral analytics, telemetry, or "events" beyond the audit log described in § 1.2
• Cookies of any kind on the Worker (the web app uses one session cookie for sign-in, scoped to its own origin)

Helene has no analytics provider, no error-tracking service, no third-party SDKs in the Worker, and no advertising relationships. The list of subprocessors is in § 5.

3. What you own

The memories themselves — the body, the titles, the project documents your AI client synthesizes from them — live in your Google Drive's appDataFolder sandbox. This is a design choice, not a coincidence. It means:

• You retain full ownership and physical control
• You can revoke Helene's access at any time at https://myaccount.google.com/permissions — when you do, Helene loses the ability to read or write that folder, but the files remain
• Your Drive's existing privacy and security posture (Google Workspace controls, regional data residency, two-factor authentication, account recovery) applies to your Helene memories without any extra work
• If Helene shuts down tomorrow, your memories survive — they are markdown files in your Drive

The appDataFolder is hidden from the normal Drive UI (Google's design choice for application-private data), but you can list and download every file Helene has stored using Google's APIs or third-party Drive utilities. Helene's web, iOS, and Android apps each include in-app controls to export your memories as a ZIP archive (markdown files plus a JSON manifest), assembled in your browser or device directly from your Drive — Helene's Worker never sees the memory bodies during export — and to delete your account.

4. Transient processing — the honest disclosure

Here is the part that most privacy policies elide. Helene's Worker is the proxy that talks to your Drive on your behalf, and that proxy reads the contents of your memories in memory while it is processing a request. Concretely:

• A request to list memories causes the Worker to read your file index (a manifest of memory IDs and titles) into memory.
• A request to fetch a single memory causes the Worker to fetch that memory's markdown body into memory and forward it to the client.
• A request to assemble a project document goes through three phases:
  • (a) Helene's Worker batches reads of the relevant memory bodies and returns them to your AI client — the same kind of read it does for list/get, just batched.
  • (b) Your AI client (Claude, ChatGPT, etc.) runs the synthesis on its own model. Helene's Worker calls no AI model and generates no text.
  • (c) Your AI client sends the resulting markdown back to Helene, which writes it to your Drive verbatim.

In each case the data exists in Worker memory for the duration of one HTTP request — typically one to three seconds — and is then released to the V8 garbage collector. We do not log it, cache it, or persist it.

But "we do not" is a behavioral guarantee, not an architectural one. A malicious operator could, in principle, modify the Worker code to log memory bodies, write them to a side database, or exfiltrate them to a third party — at any of the read points above, including the batched read that backs project-document assembly. Casual inspection of the deployed Worker's behavior — request and response shapes, what data crosses what boundary — would catch the most obvious exfiltration paths. Defending against a sophisticated supply-chain attack on the deploy pipeline itself is beyond what a single-maintainer project can credibly promise; users with that threat model should treat Helene's hosted Worker as out of scope and run their own. We are saying this plainly because we think the alternative — claiming "we cannot read your data" when we transiently can — is the privacy theater that makes people stop trusting policies in the first place.

If end-to-end encryption is a hard requirement for your use case, Helene is not the right tool. The Worker still sees memory bodies in transit on every read — including the read that feeds your AI client's synthesis — and end-to-end encryption would prevent the AI client from receiving readable content over the connector at all.

A second, more subtle disclosure: traffic-pattern analysis. Even if a malicious operator never read content, the audit logs in § 1.2 reveal when you used Helene, how often, and which endpoints you hit. We retain these for the period stated in § 7 and recommend assuming an operator could observe this metadata. We do not log IP addresses ourselves, but Cloudflare (our hosting provider) logs request metadata at the edge per its own retention policy — see Cloudflare's privacy policy linked in § 5.

5. Subprocessors

Helene has exactly three subprocessors: Cloudflare (Workers, D1, KV); Google (Drive appDataFolder for user content); and Resend (transactional email delivery for the daily operator digest only — no user-facing email content is sent through Resend). If this list ever changes, this policy will be updated and the effective date at the top will be advanced.

There are no analytics vendors, error-tracking vendors, advertising networks, CDNs other than Cloudflare's, or third-party SDKs.

6. Encryption

• At rest in Helene infrastructure: Google refresh tokens are encrypted using AES-256-GCM with a secret held only in Helene's server-side secret store, then stored in Cloudflare KV. An attacker who exfiltrates the encrypted blobs without also exfiltrating the secret cannot decrypt the tokens.
• In transit: All traffic between client apps, the Worker, and Google is TLS 1.2+. Helene does not accept plaintext HTTP.
• At rest in your Drive: Subject to Google's at-rest encryption (AES-256, per Google's published encryption whitepaper).
• In Worker memory: Plaintext during request processing, as described in § 4.

All other Helene secrets live in a server-side secret store and never appear in code, logs, or persistent storage.

7. Retention

When you delete your account, Helene executes a best-effort cascade: all files in your Drive sandbox, your encrypted refresh token, your sessions, your MCP connector tokens, your audit log entries, and your account record — and best-effort notifies Google to revoke Helene's Drive access. If revocation fails, you can manually revoke at https://myaccount.google.com/permissions. Helene does not guarantee a strict ordering between these steps. If the Drive cleanup fails (network error, scope already revoked, etc.) the in-Helene state is still deleted; you can manually clean up the leftover Drive files at any time.

8. Your rights

Helene supports the rights granted by GDPR, CCPA, and the Korean Personal Information Protection Act:

• Access (GDPR Art. 15): Your memories are already accessible — they are markdown files in your Drive. The in-app export under Settings assembles a single ZIP archive of your memories in your browser or device, fetched directly from your Drive.
• Portability (GDPR Art. 20): The in-app export produces a structured, machine-readable archive (markdown files plus a JSON manifest). You may move it to any compatible tool, or copy the underlying files out of Drive directly.
• Erasure (GDPR Art. 17): The in-app "Delete account" flow performs the cascade described in § 7. You can also delete individual memories from the app or by deleting the underlying Drive file.
• Rectification (GDPR Art. 16): Edit memories in-app, or edit the markdown files directly in Drive. Helene reads them on the next request.
• Objection / restriction (GDPR Arts. 18, 21): Email [email protected].
• Withdraw consent: Revoke Helene's Drive access at https://myaccount.google.com/permissions. Helene's audit log of past requests will still age out per § 7.

To exercise a right that is not surfaced in-app, email [email protected]. We will respond within 30 days.

9. Children

Helene is not directed at users under 13 (or under 16 in jurisdictions where that is the relevant threshold). We do not knowingly process data from minors. If you become aware of an account belonging to a minor, please email [email protected] and we will delete it.

10. International transfers

Helene's Worker runs on Cloudflare's global edge network. Your requests are processed at the closest available Cloudflare point of presence. Encrypted refresh tokens in KV and audit records in D1 are replicated across Cloudflare's infrastructure. Drive content is stored according to Google's regional policies; Workspace customers can configure regional residency at the Google level.

EU users: Cloudflare and Google both publish Standard Contractual Clauses for transfers outside the EEA. Helene relies on those.

Resend processes the daily operator digest from the United States. Where EU users' aggregated usage data appears in those digests, transfer is governed by Resend's published Standard Contractual Clauses (the same SCC mechanism Helene relies on for Cloudflare's US-region processing).

11. Security

External security researchers are welcome — please report findings to [email protected]. Helene is a small, single-maintainer project; we cannot offer a bug bounty, but we will respond to good-faith reports within seven days and credit researchers in the policy effective-date footer if desired.

If a breach occurs that involves personal data, we will notify affected users within 72 hours per GDPR Art. 33.

12. Changes to this policy

We may update this policy when the architecture changes, when subprocessors are added, or when retention windows are revised. Substantive changes that affect how your data is processed will be communicated to your account email. The effective date at the top of this document is the canonical version marker.

13. Contact

• Email: [email protected]

14. Operational note

Helene is operated by a single maintainer. Where compliance commitments depend on operator behavior rather than automation (notably breach response and parts of the deletion cascade), the maintainer named in § 13 is the one who keeps them. As Helene grows we will harden these into automated jobs with audit trails.