Privacy Notice

[Company legal name] operates Ivy. For the data your office connects and the questions its people ask, your office is the controller and we are its processor: we handle that data on the office’s instructions, under the terms. For account and billing details we are the controller. Contact: [Contact email].

• Account data — name, work email, organization, role. Held by our identity provider and mirrored in our database so Ivy knows who is asking.
• Conversations — what you ask Ivy and what it answers, on the web, in Slack, and by email, including attachments you share with it.
• Connected data — the content Ivy reads from the tools your office connects (mail, documents, spreadsheets, calendars, chat, CRM). Read on demand to answer a question or run a routine; only what a request needs is fetched.
• Inbound mail — messages sent to Ivy’s mailbox for your office are stored so they can be triaged and answered, then trimmed on the retention schedule below.
• Actions and audit — every tool Ivy calls is recorded: which tool, when, by whose authority, whether it succeeded, and the inputs and outputs. This is the record your office can review.
• Memory — facts Ivy is told to remember about your office, held separately per office.
• Usage and cost — tokens, model, duration and cost per request, attributed to your office for billing.
• Diagnostics — error reports with identifiers and counts. Message content and email addresses are not sent to our error tracker.

To provide the service you asked for (contract); to keep it secure, bill for it and improve it (legitimate interests); and where the law requires (legal obligation). We do not sell data and we do not use your content to train models — ours or anyone else’s.

Ivy is built on a small number of infrastructure and model providers. Each one, what it does, and what it sees is listed on the sub-processors page. Content goes to a provider only when a request needs it — a question is sent to the model provider to be answered; a web search query goes to the search provider; mail goes to the mail provider you connected.

Data is isolated per office at the database level: every query runs inside your office’s scope, enforced by the database itself, not only by the application.

Our providers operate in [Jurisdiction / regions to be confirmed]. Where data leaves the region it was collected in, we rely on the provider’s standard contractual clauses or an equivalent mechanism. [Region list and transfer mechanism to be confirmed by legal.]

Your office sets a retention window (default 90 days, between 7 days and 10 years). On that schedule Ivy removes: the bodies of inbound mail, the inputs and outputs of recorded tool calls (the fact that a call happened is kept), coding-job logs, and conversations not touched within the window.

Kept for the life of the account: the usage ledger (it is your bill), the record of what Ivy sent and to whom, and the history of scheduled routines — because these are the evidence you would need if a recipient or a regulator asked. Deleting them is a decision your office can request explicitly.

When an office leaves, its data is deleted 30 days after termination unless the law requires longer.

Encryption in transit and at rest; credentials for connected tools held in a secrets vault, never in application tables; database-enforced isolation between offices; a single audited path for every action Ivy takes and a single audited path for every message it sends; least-privilege runtime roles. No system is perfectly secure, and we will tell affected offices without undue delay if a breach affects their data.

People whose data your office connects should exercise their rights through the office; we will help it respond. For your own account data you can ask us to access, correct, export or delete it at [Contact email]. You may also complain to the supervisory authority in [Jurisdiction].

Sign-in uses strictly necessary session cookies set by our identity provider. We do not run advertising or cross-site tracking. We use first-party product analytics (PostHog, listed on the sub-processors page) to see which features are used; it does not receive message content or documents.

We will post changes here and notify workspace administrators of material ones. The date at the top is the date of the current version.