Gimble Privacy Policy

2.1 Permissions We Request

• Email Metadata (gmail.metadata): Requested when you first connect your Gmail. Allows Gimble to read message headers (sender, date, subject line) to identify which companies hold an account for you. No message body is accessible under this permission.
• Gmail Settings (gmail.settings.basic): Requested the first time you mute a company. Allows Gimble to create a Gmail filter that routes that company’s future mail out of your inbox.
• Gmail Labels (gmail.labels): Requested alongside the settings permission above. Allows Gimble to create the label the filter files mail under. Gmail does not permit label creation under the settings permission alone.
• Gmail Read-Only (gmail.readonly): Requested the first time you turn on the deeper scan, unless you already hold the modify permission below. Allows Gimble to read message preheaders, bodies, and PDF attachments for the sampled messages described in Section 3. This permission cannot change anything in your mailbox.
• Gmail Modify (gmail.modify): Requested the first time you opt into a backlog sweep or an inbox cleanup. Allows Gimble to move already-received mail out of your inbox and back again if you undo it. A user who already holds this permission is not asked for read-only separately, because modify covers the deeper scan’s reading. Nothing narrower can do this: a Gmail filter only acts on mail as it arrives and cannot touch a message already sitting in your inbox. This permission is never used to send, compose, or delete mail.

2.2 Permissions We Never Request

Gimble never requests gmail.compose, gmail.send, or full mail access. We are being precise here rather than reassuring: gmail.modify, which Gimble requests only for archiving, does technically permit sending and drafting mail. Google’s own consent screen says “Read, compose, and send emails from your Gmail account.” Gimble never uses that capability. No part of the Service sends, drafts, or composes a message, and where it helps you write to an insurance broker it opens a compose window that you send yourself. Gimble also never deletes mail: the only change it makes to your mailbox is moving a message out of the inbox under a Gimble label, which you can undo.

2.3 How Muting and Cleanup Work

Muting and cleanup archive mail: messages are moved out of your inbox under a label and remain in your mailbox. Nothing is ever deleted or trashed.

2.4 Google Contacts Permissions

Gimble may request access to your Google Contacts when you choose to pick people from your contacts list. These permissions are requested only when you press the button to do so, never at sign-in, and only if you signed in with Google.

• Other Contacts (contacts.other.readonly): Show the names and email addresses of people you have corresponded with, so you can choose whom to ask for a mailing address, and show those people’s contact photos on their avatars.
• Contacts (contacts.readonly): The same for contacts you have saved, and on your Contacts pages, show a saved contact’s name as you wrote it on the card.

What is read and not stored: names and email addresses, as a list to choose from; each contact’s photo URL; and, for contacts you saved, the name on the card. Your browser loads the photo from Google and keeps neither the URLs nor the names. What is stored: only the people you select, one at a time, as a row on your own address list (a name and an email address). Each is sent one invitation email asking for their address. A contact’s postal address or phone number is never read. Gimble never invites or emails anyone you did not choose; there is no way to ask the whole address book.

3.1 Information We Read

• Always: message headers (sender, date, subject line).
• For sampled messages (when you opt into the deeper scan): the subject line, preheader, and body, processed transiently in memory.
• For insurance-related mail: the text content of PDF attachments from companies already identified as your insurer or broker.

3.2 Information We Store

Gimble stores only derived data fields, never raw email content. Email bodies, preheaders, and attachment text are never written to any database.

Subject lines are written to a temporary working table during a scan for classification purposes. They are never displayed to you and are automatically deleted when the scan completes.

The derived fields Gimble stores are:

• Company identity and classification: the company name, its category and subcategory, confidence scores, classification verdicts, dormancy status, and public breach matches.
• Loyalty program information: member numbers, tier status, expiry dates, and point or mile balances.
• Insurance policy information: carrier, policy line, policy number, premium amounts, and a dated premium history. Where your insurer or broker sends a policy document as a PDF attachment, Gimble also stores what that document states about the policy: the coverage limits, deductibles, and premiums on its schedule, the term it runs for, the NAIC code, the address on the policy, and the year, make, and model of a covered vehicle. Each carries the date of the document it was read from. Gimble never stores the vehicle identification number, the dates of birth, the past claims, or the mortgage or lienholder account number that the same document prints.
• Subscription information: what a service charges, how often, when it renews, a dated price history, and a payment channel label (e.g., “PayPal” or “card”). Payment channel labels are truncated before their first digit so that card numbers, including the last four digits, can never be stored.
• Order history (approximately two years): per order, the merchant, date, total charged, whether it was cancelled or returned, and a link to the sender’s own page for it. Gimble never stores what was purchased: no item descriptions, SKUs, product categories, or similar details.
• Travel bookings (approximately one year): per booking, the type of travel, date range, city, and cost. Gimble never stores booking references, record locators, e-ticket numbers, seats, fare classes, or the names of other travelers.
• Breach data: public breach metadata from Have I Been Pwned, matched by domain. No password or credential of yours is involved.
• Company facts shared across users: for sending domains that Gimble has classified consistently across at least three different users’ scans, Gimble stores which company a domain belongs to, that company’s name, the inventory category it files under, and whether it bills recurringly. These records have no user column and do not say who receives a company’s mail. They are never created for a consumer mail domain (Gmail, Yahoo, and the like), an email-delivery service’s domain, or a person. They are derived from scans and are not deleted when one person leaves, because nothing in them describes an individual.

3.3 Information We Never Extract or Store

The following categories of information are never extracted from your email, and no field exists in Gimble’s data model to hold them:

• Card numbers, including the last four digits
• Loan and bank account numbers
• Credit scores and statement balances
• Booking references and record locators
• Names of other people, including other drivers on a policy (the professional network, described in Section 5, stores the names and addresses of your correspondents under its own separate consent)
• Seats and fare classes
• Item-level contents of any order
• Vehicle identification numbers
• Dates of birth
• Past insurance claims
• Mortgage or lienholder account numbers

3.4 Information We Transmit to Our AI Sub-Processor

For sampled messages, the subject line, preheader, body, and attachment text are sent to Anthropic’s Claude API for classification and extraction. This content is deleted by Anthropic within thirty days and is never used to train Anthropic’s models, under Anthropic’s standard commercial API terms. Gimble itself persists none of it.

Your Google user data is not used to develop, improve, or train generalized or non-personalized artificial intelligence or machine learning models. Our AI sub-processor’s commercial terms prohibit Anthropic from using API inputs to train its models.

5.1 What It Does

The professional network builds a view of the people you correspond with, drawn from message headers (sender, recipients, dates, thread identifiers). It does not read message bodies, subjects, or snippets: no such column exists on any of its tables.

5.2 What It Stores

When you turn the professional network on, Gimble stores:

• Your correspondents: the display names and email addresses that message headers spelled, one row per email thread recording who was on it, the first and last date, message counts by direction, and whether it was one-to-one or a group thread.
• Relationship summaries: per-person counts and dates derived from the thread records (how many threads, in which direction, over which years) and a band describing the relationship, all marked as inferred. Threads older than ten years are summarized and then deleted.
• Merge candidates: pairs of your contacts who share a name, and whether you said they are the same person.
• Your own addresses: the addresses you have connected or signed in with, so the network can recognize you.
• Your suppression and privacy choices: keyed digests of addresses of people you removed (never the addresses themselves), and domains you marked as private (stored as the domain name you typed).

5.3 What It Sends to the AI Sub-Processor

While the professional network is being built, a contact’s email address, display name, and domain may be sent to Anthropic to determine whether the contact is a person or whether two contacts who share a name are the same person. This is covered by the same thirty-day deletion and no-training terms described in Section 3.4, and only for users who accepted the consent screen version that says so.

When you search your network, Gimble sends the question you type to Anthropic, which reads it into a query and sees nothing from your network. The answer is computed from your own stored data.

When you select “Explain how I know them” on a contact’s page, Gimble sends that contact’s name, the domains they wrote from (not their addresses), and the summary counts the page shows to Anthropic. The sentence that comes back is shown to you and is not stored.

5.4 Network Conversations

You can ask questions about your network in a conversation. Gimble stores each conversation’s title (your first question, shortened) and each message: your question as you typed it, and each answer as text in which every person is a placeholder, with the identifiers of the relevant records. An answer never holds a name, an address, or anything about anyone: the people it names are read from your own network data each time the conversation is opened, so someone you removed since drops out of every old answer.

Your questions can name people and are kept as you typed them until you delete them. Each question is sent to Anthropic as a search is. Conversations can be deleted individually, all at once from Settings, or by turning off the professional network.

5.5 Enrichment

Gimble may look up a contact’s current company, title, location, name, and profile photo from public professional profiles through a third-party data provider (pipe0, operated by PWLL UG, Berlin). Gimble sends only that contact’s email address and nothing else. pipe0 passes it to its own data providers (MixRank, Aviato). pipe0 keeps each lookup, the address sent, and the answer for 21 days, readable only by Gimble, then deletes it.

Enrichment runs in two ways: when you open a contact’s page, and in the background for the people you have written to most, up to 300 of them. Profile photos are fetched by Gimble’s server from the data provider’s CDN and proxied to your browser; your browser never contacts the CDN directly. The image is not stored by Gimble; your browser keeps it for a day.

The profile information returned may be stored and shown to any Gimble user who knows the same person, which is why a lookup is rarely repeated. Nothing inferred from one user’s mail is shown to another.

5.6 Removing a Contact

Removing a person deletes their rows and adds keyed digests of their addresses to a suppression list, which is how later mail from them stays out. No name or address is kept after removal.

5.7 Turning the Professional Network Off

You can turn off the professional network at any time. Turning it off deletes every per-user network row: your correspondents, their addresses, all thread records, relationship summaries, merge candidates, model verdicts, your own addresses, your enrollment, your suppression list, and all network conversations.

Two global tables store a keyed digest per address and, where enrichment has run, public employer facts from the data provider (company, title, location, profile link, profile name, and photo address). These tables also record which of your own addresses belong to your account while the network is on; turning the network off or deleting your account clears that link. The identity rows themselves survive, because they are facts about correspondents that other users who know the same people also read. A queued enrichment lookup you triggered is deleted with your data.

Your contacts are visible on the web, in the phone app, and in the Mac app. The phone and Mac apps read them through Gimble’s API with their own sign-in and keep them on neither device.

6.1 Where Protected Data Lives

The macOS app stores one authenticated, encrypted vault file under your Application Support directory. The master password and decrypted contents stay in local process memory while unlocked. Gimble’s cloud service, the web app, the background worker, and all sub-processors listed in Section 10 do not receive your passwords or passkeys. There is no server-side API that accepts a third-party password.

6.2 The Chrome Extension

The Chrome extension receives only the single username and password you explicitly select for the active site’s exact origin.

The Chrome extension can also answer a website’s passkey requests with passkeys saved in your Mac’s vault, while the Mac app indicates it supports them. While switched on, the extension is present in the top frame of every website it has access to, before the site’s own code runs, and sees each passkey request the site makes: the site’s address, the account name and identifier the site chose, a one-time challenge, and which passkeys the site will accept. It keeps none of it. A request reaches the Mac only after you click something on the page or pick a passkey from Gimble’s suggestion under the sign-in field.

Before creating or using a passkey, the Mac app brings its window forward showing the page’s address and the account name, and you choose to proceed, use another device instead, or cancel. Proceeding requires Touch ID or your Mac’s password. No private key leaves the Mac’s vault. Nothing is sent to Gimble’s service or to any AI.

6.3 The Phone App

On iOS, an AutoFill extension offers the sign-ins and passkeys saved in that phone’s own vault in Safari and other apps, and can create a passkey or save a password you submit. So that iOS can suggest a sign-in before Gimble is opened, the phone provides Apple’s on-device credential index with each saved sign-in’s website address and username (and, for passkeys, its credential and account identifiers). No password and no key is in the index. It is on the phone, managed by iOS, and emptied when the vault is removed.

The vault’s files and its Face ID-protected key are shared with the extension on the same phone only. The phone’s signing identity is not shared. Opening the vault there requires Face ID or the phone’s passcode; one approval covers one request.

A passkey created or a password saved through the extension is stored in the phone’s vault and syncs to your other devices through Gimble’s existing end-to-end encrypted sync after the Gimble app next unlocks. Gimble’s service sees it only as ciphertext. Nothing is sent to any AI.

6.4 Recovery Key

Your recovery key can be saved to iOS Passwords, where it is held and synced by iOS under your Apple account settings, outside Gimble’s control, and can be filled back into Gimble on a new install. Printing sends it to the printer you pick. Gimble’s service receives neither.

6.5 Posture Receipts

For each account in your inventory, Gimble stores one record indicating what your Mac last found for it: a coverage level (not covered, password, or passkey) and when it was checked. Nothing else: no username, password, saved-item identifier, device name, or anything that describes the saved login itself. The record is rewritten when the level changes and once daily while the Mac runs. If no device has checked a record for 90 days, it is no longer shown and is deleted. The web and the phone app read it as part of your inventory and show the level.

7.1 What the Automation Stores on Gimble’s Server

An automation request records the account, the action, where it runs, whether it was asked from the web or the phone, whether a Mac was available, and how it went (waiting, running, done, cancelled, expired, and so on), with the times it was made and last changed. Nothing the run saw or did: no site address, page content, username, password, code, or any of the agent’s words. A request no Mac takes within five minutes expires. Requests are kept for 90 days and then deleted.

An automation executor records that a Mac session can run these actions, the version of the protocol it speaks, which actions it runs, and when it last said it was running. It holds no computer name, model, hardware or network identifier, or browser profile. The web and the phone see only “available,” “not available,” or “unknown” for each action. Executor records are deleted 30 days after they were last running and when you delete your account.

7.2 What the AI Sub-Processor Sees

At each step, the agent sends the page’s accessibility outline (headings, labels, visible text, and control names) with every field’s contents removed, so no password, code, or typed value is included. The password and code are typed by Gimble on the Mac, never by the model.

7.3 Verification-Code Emails

When a sign-in the Mac is running requires a one-time code sent by email, the Mac can read the code from your Gmail mailbox using a separate, desktop-held read-only grant (stored in the Mac’s Keychain). While a code step waits, the Mac reads the sender, recipient, and authentication headers of new inbox messages. It reads a message’s content only when Google authenticated its sender as the website’s own domain or a sender you confirmed for that website. Of other new messages it keeps, in memory until the step ends, only the authenticated sender’s domain, so that when exactly one arrived it can ask you whether that domain sends the website’s codes.

Confirmed sender pairings and learned message shapes (stored as hashes, not text) are kept on the Mac only, never sent to Gimble’s service or to any AI. Codes, messages, subjects, and addresses are not stored, logged, or synced. You can see each website and its confirmed senders in the Mac’s Gmail settings and forget any of them.

7.4 What Runs Store on Gimble’s Server

• Insurance website facts: For each inventory account the Mac visited, the facts the site displayed (a section, a label, and the value exactly as shown), with the site’s address and the time read. A new reading replaces the previous one. You can remove it from the account at any time. Kept at most 365 days. Beneficiary names, Social Security numbers, and bank account numbers are not read into it.
• Account status facts: For each inventory account, the facts the site displayed about your program status (the program’s name, tier, balance of points, miles, nights, or certificates as a count, progress to the next tier, when status or points expire, and the date the site gives the balance). Never read into storage from a status reading: any amount of money, the membership or program number or any other account number, names, addresses, or payment details. Gimble signs in once each time you press it and never again in that run.
• Plan facts: After any visit the agent makes to a site, it reads which plan you are on (its name, level, price, renewal date, and status) and the other plans the site offers with their prices. It never signs in again, never chooses or changes a plan, and never keeps a card number, bank detail, name, or address.
• Each kind (status or plan) is replaced by the next reading of that kind. You can remove either from the account at any time. Kept at most 365 days. The database itself refuses any fact containing an identifier or a payment or identity detail (eight or more consecutive digits, a Social Security number’s pattern, or a label naming an account, card, member or program number, a payment method, bank or tax details, a beneficiary, a date of birth, or a driver’s license), and any status value that names money.

On the Mac only: the Chrome profile (the site’s own cookies, as any browser keeps), the steps a run took (recorded by control label with no values), and the last reading.

7.5 Securing an Account

When Gimble gives an account a new password through the site’s forgot-password flow, it reads the site’s reset email in memory under the mailbox’s read grant only. It takes the reset link only from mail that Google authenticated as the site’s own. When the email’s reset button goes through the site’s email-tracking service, Gimble requests up to three of those tracking addresses, each once, to find the reset link. The link is opened once in the Chrome profile kept for that site. Nothing from the email is stored, logged, or sent to the AI. The new password is generated on the Mac and saved in your encrypted vault before it is typed.

8.1 How It Works

You add people to your list by name and email address (typed or chosen from your Google Contacts under Section 2.4). For each person, you can ask Gimble to email them a link. The person who opens the link signs in and types their own mailing address. Once they do, you each see the other’s address.

A person can also answer without signing in. Their address is then handed to you the way a text message would be: it is kept on your list as your own copy, visible to you alone, and it does not update when they move. An answer is kept at once only when it arrives through the link you sent that person; any other answer, including one through a link sent to a group, waits for you to keep it, and none replaces a copy you already hold. If that person later signs in, the copy is deleted and their own address takes its place, including their right to stop sharing it.

When the person accepting is not provably the one you invited (a forwarded link, or a sign-in under a different email address), you still receive their address at once and they see yours once in the reply, but continuing two-way access waits until you confirm them.

8.2 What Addresses Stores

• Mailing addresses: one per person, entered by that person and no one else: the envelope name they chose, street, unit, city, state, ZIP, and country, the text as they typed or pasted it, USPS’s standardized form when USPS answered, whether USPS called it deliverable, and when they confirmed it. Stored as the person’s own address only after they sign in and accept the invitation. Who can see an address is controlled by individual grants: the person themselves, the sender whose invitation they accepted, and each person they have a live exchange with.
• Address history: when an address moved, and only the city and state it moved from. No earlier street address is kept.
• Your list: for each person, the name you call them, the email address and phone number you gave, your tags and note, when you last asked them, and a link to their account once they have accepted. Your list holds a postal address in one case only: a copy given to you by someone who answered without signing in (street, second line, unit, city, state, ZIP, country, the text as they typed it, USPS’s verdict, and when it arrived, and, through a group link, the name they gave). Otherwise you see an address only through a live grant, read at the time.
• A recipient’s list: accepting an invitation puts the person who asked on the recipient’s own list, as that person’s name and a link to the exchange. No email address or phone number is copied.
• Invitations: each request and its link. A recipient row keeps a server-keyed digest of the email or phone the invitation was aimed at (never the address itself), a hash of the link’s token (never the token), whether it has been accepted, and which sign-in to offer first.
• Your display name: the name from your sign-in, so an invitation can say who is asking. A stranger opening the link is shown the first name only.

8.3 Outside Services While an Address Is Entered

The text typed into the street field goes to Google Places for address suggestions. The finished address goes to USPS to check it is deliverable. Text pasted as a whole address goes to Anthropic to split it into fields. Each carries only what the person typed or pasted; no account, email address, or other identifier is added. Separately, when you ask Gimble to tidy the names on your list for envelopes, only those names go to Anthropic (never an email, phone, or address), and nothing changes until you accept each proposal.

8.4 Invitations

You either send a person’s link yourself, from your own email or phone, or have Gimble email it. Gimble’s invitation email goes to the recipient’s address through Resend and carries your name and the link. No address of anyone’s is in the email, and no tracking is included.

8.5 Export

You can download your list, with the addresses shared with you, as a CSV formatted for a card printer. The file is built in your browser and saved to your device. Gimble keeps no copy.

8.6 Deletion

Deleting your account deletes your address, your list, your invitations, and your grants, so the addresses you shared stop being visible to others immediately. A sender’s list row about someone who later deletes their account keeps what the sender gave and loses the link. There is no control yet for deleting only your address, revoking one exchange, or withdrawing a submitted invitation; account deletion is the route until those ship.

A copy of an address given without signing in is deleted when the sender removes that person from their list, when the sender deletes their account, or when the person who gave it signs in. A person who never signs in has no account to delete it from and can ask us to delete it at privacy@gimble.app.

12.1 Disconnect One Mailbox

You can disconnect any individual mailbox from within the Service. Disconnecting a mailbox:

• Revokes that mailbox’s access grant at Google and deletes its access tokens from our encrypted secret store, unless another Gimble account is connected to the same mailbox, in which case only your token secrets are deleted and the grant is left for the other account
• Deletes that mailbox’s share of every company (a company only that mailbox contributed is deleted; the rest are recomputed from your other mailboxes), its scans, watermark, and, in the professional network, its threads and any person only that mailbox named
• When the disconnected mailbox is your sign-in mailbox, the deep-read data associated with it (insurance policies, loyalty memberships, and the underlying observations) is also deleted
• Website facts, posture receipts, and automation requests associated with the affected inventory accounts are deleted with them

Your other mailboxes and everything read from them are untouched. Disconnecting your last mailbox is equivalent to the full Gmail disconnect below.

12.2 Disconnect Gmail

You can disconnect all Gmail mailboxes at any time from within the Service. Disconnecting:

• Revokes Gimble’s access to each connected mailbox’s grant at Google
• Deletes your Gmail access tokens from our encrypted secret store
• Deletes all data derived from your mailboxes, including account inventory, insurance policies, loyalty memberships, subscriptions, orders, travel bookings, scan records, email digests, website facts, posture receipts, automation requests, and, in the professional network, all thread records, correspondents, relationship summaries, and model verdicts

Your professional network enrollment, removal tombstones, private domains, and network conversations survive a disconnect: they are your own choices and words, not something read from mail, and a reconnected mailbox must not bring back someone you removed. They are deleted with your account.

Your Gimble user account remains active after disconnecting. Disconnecting stops scanning; it does not delete your Gimble account.

12.3 Turn Off the Professional Network

You can turn off the professional network at any time from within the Service. This deletes all per-user network data as described in Section 5.7.

12.4 Delete Network Conversations

You can delete conversations individually, or all at once from Settings. Nothing deletes them on a timer. Turning off the professional network also deletes all conversations.

12.5 Delete Your Account

You can delete your Gimble account at any time from within the Service. Deleting your account performs the same data removal as disconnecting your Gmail and additionally deletes your user record, your professional network enrollment and choices, your network conversations, and your Addresses data (your address, your list, your invitations, and your grants, so the addresses you shared stop being visible to others immediately). Account deletion is completed immediately.

Both disconnect and delete revoke your Google grant before deleting tokens and remove encrypted secrets before the database rows that reference them, so no live credential can be stranded.

12.6 Data on Your Devices

The disconnect and account-deletion actions above remove data from Gimble’s servers. They cannot reach files stored locally on your Mac (your encrypted vault, Chrome profiles kept for site automations, verification-code sender pairings, and the last reading from each site). On the Mac, disconnecting Gmail from the Mac’s own settings deletes the local verification-code files and asks Google to revoke the Mac’s grant. Your encrypted vault is managed locally: individual logins can be deleted from within the app.