Privacy Policy

1. Who we are and what this policy covers

Bottari is a collaboration product for software teams. It combines a shared workspace (channels, documents, databases, meetings) with AI work sessions that run on each member's own computer.

This policy is published by Open Rhapsody, Inc., 8F, 16 Teheran-ro 8-gil, Gangnam-gu, Seoul 06233, Republic of Korea ("Bottari", "we", "us"). It explains what personal information we handle when you use:

• the bottari.ai website, including the waitlist form,
• the Bottari desktop app (macOS),
• the Bottari mobile app (iOS/Android),
• the Bottari web surfaces, including publicly published pages, and
• our backend services at api.bottari.ai and app.bottari.ai.

It does not cover third-party services you or your administrator choose to connect (Slack, Notion, Gmail, GitHub, Google Analytics, Google Ads, your own databases). Those services remain governed by their own privacy policies.

2. Our two roles: controller and processor

Bottari is a workplace product, so the same policy covers two different relationships.

If you use Bottari for a personal workspace with no employer behind it, we are the controller for everything.

3. Information we collect

3.1 Account and profile

We do not operate passwords. You sign in with Google or GitHub (OAuth 2.0 / OpenID Connect), or with Sign in with Apple in the iOS app. At sign-in we receive and store:

• provider name and your provider user ID and username (Google, GitHub, or Apple),
• your email address (may be absent if your GitHub email is private),
• your display name and profile picture URL,
• the time of your last sign-in.

Sign in with Apple. Apple shares your name only the first time you sign in, and an email address. If you choose Hide My Email, the address is a private relay address ending in @privaterelay.appleid.com that forwards to your real inbox; we never see the address behind it.

We do not store the access tokens issued by Google, GitHub, or Apple for identity — the profile is read once and the token is discarded. Our own session tokens are kept as hashes only, so the stored value cannot be used to sign in.

You may optionally add to your profile: a job title, a time zone, a custom status (emoji and text), and an uploaded avatar image.

Waitlist. If you ask for access on bottari.ai before you have an account, we store the email address you submit so that we can contact you about access, and delete it on request.

3.2 Workspace content and usage records

Because the workspace is the product, most of what we hold is what your team creates there and the record of how it is used:

• Content you create or upload — messages, documents, databases, comments, and files, including their earlier versions;
• Usage records — how you use the workspace, such as what you have opened or viewed, read state, favourites, drafts, and your preferences;
• Membership information — the teams, spaces, and workspaces you belong to, your roles, and invitations (including the invited person's email address).

Some usage records are part of working together: teammates who can access the same content may see that you have viewed it. You can hide your views from teammates in settings.

3.3 AI work sessions and activity on your device

Bottari's AI agent runs on your own computer, not on our servers. Your source code stays on your device and in your own git remotes — we do not upload your repository, and the code index the agent builds is stored only in a local cache on your machine.

What does reach our servers is the session record, which is shared with everyone who can access that session:

• the full session log — your instructions, the model's replies, and each turn's tool activity;
• which tools the agent ran, the commands and file paths involved, and previews of the results;
• files the agent read in order to answer you. The agent can read files under your home directory, including outside the project folder, and what it reads can end up in the shared session log;
• work session metadata: title, assignee, parent session, the repositories bound to the session, and which device holds the run seat;
• AI usage records for each model call — the model, token counts, and cost — used for usage limits and billing;
• a device record for each machine you sign in from: an opaque device ID, your computer's hostname (e.g. "Angie-MacBook-Pro"), and when it was last seen.

Safeguards that exist today: the agent is denied read access to credential locations (~/.ssh, ~/.aws, ~/.claude, and Bottari's own token files); values matching secret and personal-data patterns are masked before a tool result is written into the shared log; and reads outside the working folder are flagged in the team audit log. These reduce, but do not eliminate, the chance that something private on your machine appears in a team-visible record. Treat a Bottari session as a shared workspace, not a private terminal.

3.4 Meetings, audio, and screen sharing

When your team runs a meeting or scrum in Bottari:

• Audio and video are carried in real time by a LiveKit server that we operate on our own infrastructure (rtc.bottari.ai) — not by a third-party meeting cloud.
• Screen sharing on desktop is shared only after you pick a window or screen in the system picker.
• Meetings are recorded and transcribed by default. Recording starts automatically when the person who created the scrum joins, and a consent banner is shown the first time you join a recorded meeting. Audio chunks are sent to our transcription provider (Section 5); the resulting transcript segments are stored with the speaker's name, a timestamp, and the text; and the raw audio is held only until it is transcribed (at most one day) and then deleted — no recording is kept.
• AI meeting notes are generated by summarising the transcript and are saved as a document in your workspace.

Transcripts and notes are kept as ordinary documents with no automatic expiry. A transcript can be deleted separately from the meeting record, and deleting the page or scrum deletes its transcript with it.

3.5 Data from services your workspace connects

A workspace administrator can connect external sources. When they do, we fetch data from that source, store it, and index it so the AI can search it:

Connecting Gmail in particular means the contents of the selected mailboxes, including messages from people who are not Bottari users, become searchable inside the workspace. The administrator who connects a source is responsible for having the authority to do so and for telling affected people. Credentials for these connections are stored encrypted (Section 9) and never sent to member devices, except for short-lived, read-only tokens where a query must run on the device.

3.6 Google user data

This section describes how Bottari handles data we receive through Google APIs. Bottari's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

What we access.

The Analytics and Ads connectors are optional. A workspace administrator turns them on by connecting their own Google account; nothing is accessed until they do.

How we use it. We use Google user data only to provide the features you see in Bottari: signing you in, and answering questions your team asks in Bottari about your Analytics and Ads performance (for example, "What was campaign X's cost per acquisition over the last 14 days?"). Bottari only reads Analytics and Ads data. The Google Ads API offers no read-only permission, so the adwords permission technically allows changes, but Bottari never creates, edits, or deletes anything in your Google Ads accounts.

Limited Use. In line with the Limited Use requirements:

• We use Google user data only to provide or improve the user-facing features described above, and not for any other purpose.
• We do not transfer Google user data to others except as necessary to provide or improve those features, to comply with applicable law, or as part of a merger, acquisition, or sale of assets with notice to you.
• We do not use or transfer Google user data for serving advertisements, including retargeting, personalized, or interest-based advertising, and we do not sell it.
• We do not allow humans to read Google user data unless you give us affirmative consent for specific data, it is necessary for security purposes such as investigating abuse, it is necessary to comply with applicable law, or the data is aggregated and anonymized and used for internal operations.
• We do not use Google user data to develop, improve, or train generalized or non-personalized AI or machine-learning models.

Where it goes and who we share it with. Analytics and Ads results are fetched when someone in your workspace asks for them. We do not keep a copy of the underlying report rows. The numbers returned for a question are shown in that session, so they become part of your workspace content and are visible to the people who can see that session. To generate an answer, the question and those results are sent to the AI model provider that runs the session (see Section 5). Providers process them only to produce the answer and may not use them to train their models. We do not transfer Google user data to anyone else, except as needed to comply with law, or as part of a merger or acquisition with notice to you (Section 6).

How we protect it. Google access is granted through OAuth; we never see your Google password. The long-lived refresh token for a connector is stored only on our servers, encrypted with envelope encryption using AWS KMS (Section 9), and is never sent to member devices. When a query runs on a member's device, that device receives a short-lived, read-only access token that expires after about an hour. Google Ads requests are made by our servers, and devices receive only the aggregated results. All traffic uses TLS. Access to connectors and their results is limited to members of the workspace that connected them.

Retention and deletion. Sign-in profile data is kept for as long as your account exists and is deleted when you delete your account. Connector tokens are kept while the connection exists; when an administrator disconnects the source, we delete the stored token and connection records. Results that appeared in a session remain until that session is deleted. You can also remove Bottari's access at any time from your Google Account at myaccount.google.com/permissions.

3.7 Notifications and mobile device permissions

If you allow notifications on mobile, we store a push notification token for that device together with your notification preferences. Push messages are relayed by Expo to Apple (APNs) on iOS and Google (FCM) on Android. The text of a notification — who sent it, and part of the message, page, or session it refers to — travels along that path. You can turn notifications off in your device settings, or narrow them in Bottari's notification preferences.

The mobile app asks for these device permissions, each only when the related feature is used:

3.8 Analytics

The bottari.ai website uses Google Analytics 4 to understand how the site is used: pages viewed, the referring page, device and browser information, and an approximate location derived from your IP address. It also loads the X (Twitter) conversion tag, which tells X Corp. when a visit to bottari.ai, a click on Download, or a waitlist sign-up follows one of our ads on X, so that we can measure those ads. Both set cookies or similar identifiers in your browser.

Your cookie choice. If you visit from the European Economic Area, the United Kingdom, or Switzerland, the website first asks you with a small cookie card. Neither Google Analytics nor the X tag is loaded until you choose Accept; if you choose Decline, both stay off. We tell where you are visiting from by the country our content delivery network (Amazon CloudFront) assigns to your connection; if it cannot tell, we ask you as if you were in those countries. Your choice is kept in your browser for 1 year, after which we ask again. You can change it at any time with Cookie settings. When you answer the card, we record the answer without anything that identifies you — accept or decline, the time to the minute, the version of this policy, and the country — to show that we ask before loading these tools. No IP address, cookie identifier, or browser details are stored with it; your IP address is used only for a moment to limit abuse of that request.

The desktop and mobile apps contain no analytics SDK. If we add one, we will update this policy before the release that includes it. The desktop app sends crash and error reports to Sentry, and the mobile app sends them to Firebase Crashlytics (Section 3.9); we use these reports only to find and fix faults, not to analyse how you use the apps.

Product milestone events. Our servers send Google Analytics 4 a small set of events when a step of getting started happens — for example, that an account was created, a team or space was joined, a repository was connected, or a task was created, approved, started, or finished — so we can see where new teams get stuck. Each event carries only a pseudonymous ID derived from your internal account ID, the name and time of the step, and a few fixed values such as which kind of step it was or a count. It never carries your email address, your name, or the names or contents of your teams, repositories, or tasks. These events are sent from our servers, not from your device, so no cookie or device identifier is involved. Accounts of Bottari staff are excluded. The events are kept for the same period as website analytics data (Section 8).

We deliberately collect no advertising identifier — the Android AD_ID permission is removed and the iOS build carries no IDFA — so the apps do no "tracking" under Apple's rules and no App Tracking Transparency prompt appears. Website analytics data and product milestone events are never used for advertising or retargeting; the X tag is the only advertising tool on the website, and it is used to measure our ads on X.

3.9 Technical and security logs

• Audit log. Security-relevant events (sign-in, permission changes, sharing, agent tool use, deletions) are recorded with the actor, the target, the device, a timestamp, and the IP address and browser/app user agent of the request.
• Service logs. Ordinary operational logs and error diagnostics.
• Email delivery. Invitation emails are sent through Amazon SES; delivery events are handled by that service.
• Desktop crash and error reports. When the desktop app hits an unhandled error or one of its processes crashes, it sends a report to Sentry: the error type and message, the stack trace (locations in the app's own code), the app version, the operating system and its version, CPU architecture and memory, the locale and time zone setting, and a short list of the app events just before the error (such as a window opening or a helper process exiting). Before a report leaves your device, the app filters it automatically: it deletes Korean, Japanese and Chinese text, long quoted text, email addresses, token-like values, file paths on your device, and the path and query of web addresses outside the app. These filters are automatic and may not catch every short fragment of text that appears in an error message. Reports carry no account identity, no screenshots, and no memory dumps, and we configure Sentry not to store your IP address. Each time the app starts and quits it also reports whether that run ended in a crash, with no identifier of you, so that we can see how stable each version is. Reports that cannot be sent right away wait on your device for up to 30 days.
• Mobile crash and error reports. When the mobile app crashes or hits an unhandled error, it sends a report to Firebase Crashlytics, a Google service: the error type and message, the stack trace, the app version, the device manufacturer, model and CPU architecture, the operating system version, the memory and storage state, and random identifiers that Crashlytics creates for each installation of the app and each app session. These identifiers are not an advertising identifier; they let us count how many installations a fault affects and what share of sessions end in a crash. Reports carry no account identity, name, email address, or message content: error messages are text written into the app's code, and when an error is not a standard error object the app reports only its kind. A report about a crash is stored on your device and sent the next time you open the app.

3.10 What we do not collect

To be explicit, because it is unusual:

• No cookies in the apps. The desktop and mobile apps authenticate with bearer tokens held in the operating system's secure storage, not cookies. The bottari.ai website sets Google Analytics cookies and loads the X conversion tag (Section 3.8) — for visitors from the European Economic Area, the United Kingdom, and Switzerland, only after they accept; the apps set no advertising cookies.
• No advertising identifier and no ad tech. We do not collect the Android advertising ID or the iOS IDFA, we show no ads in the product, and we build no advertising profiles.
• No session replay or product analytics SDK. There is no session recording, Amplitude, or Mixpanel in the product. The only product analytics are the pseudonymous milestone events our servers send to Google Analytics (Section 3.8). The desktop app uses Sentry, and the mobile app uses Firebase Crashlytics, only for the crash and error reports described in Section 3.9.
• No payment card data. We do not take card payments in the product, and we never see or store card numbers.
• No precise location data and no biometric data. Website analytics infers only a coarse, city-level location from your IP address (Section 3.7).

4. How we use information, and our legal bases

We do not use automated decision-making that produces legal or similarly significant effects about you.

5. AI providers and what happens to your content

Model calls take one of two routes. When you use a model that Bottari provides, our server relays the call so that individual members do not have to hold model API keys. When you use your own Claude or Codex subscription, the official CLI runs on your own machine and contacts Anthropic or OpenAI directly under your own account — that traffic does not pass through our servers, although the resulting session log is still stored in your workspace.

Our gateway passes model traffic through and does not keep a separate copy of the request body; however the session log in your workspace does retain the session log, which is the point of a shared session.

Training. We do not use your content to train AI models, and we do not allow our model providers to train on it. Where a provider's default terms would permit training on prompts, we configure our account so that your requests are not routed to that provider.

6. Who we share information with

We do not sell personal information, and we do not share it for cross-context behavioural advertising, as those terms are used under US state privacy laws.

Inside your workspace. Bottari is collaborative by design. Workspace content is visible to the people who have access to it — team members, and guests invited to specific pages. Activity on it, such as who has viewed it, may be visible to team members who have access. Your administrator can access workspace content and the team audit log.

Publicly, when you publish. A page that someone publishes to the public web becomes readable by anyone with the link, without signing in. Published pages deliberately omit user IDs and email addresses, showing display names and opaque avatar references instead.

Service providers (sub-processors).

Advertising measurement. When the X conversion tag runs on the website (Section 3.8), your browser sends visit, Download-click, and waitlist sign-up events directly to X Corp. (United States), which handles them under its own privacy policy. For visitors from the European Economic Area, the United Kingdom, and Switzerland this happens only after they choose Accept on the cookie card.

Others. We may disclose information to comply with law or valid legal process, to protect our rights or the safety of users, and to an acquirer in a merger, acquisition, or asset sale — in which case we will notify you before your information becomes subject to a different policy.

7. Where your data is stored and international transfers

Our application servers, primary database, file and image storage (including meeting audio kept temporarily for transcription), the content delivery network, key management, and outbound email run on AWS in the United States (us-east-1). Model providers, push relays, analytics, and crash reporting also process data in the United States; Google may also process mobile crash reports in other countries where it operates data centres.

If you are in the United Kingdom or the European Economic Area, transfers to the Republic of Korea are covered by the adequacy decisions those jurisdictions have granted Korea — the EU decision of 17 December 2021 and the UK "data bridge" in force since 19 December 2022 — so no additional transfer mechanism is needed for that leg. For transfers to the United States we rely on appropriate safeguards: Standard Contractual Clauses, with the UK International Data Transfer Addendum where the UK GDPR applies, or the provider's certification under the EU-US Data Privacy Framework. You may request a copy of the safeguards using the contact details in Section 13.

8. How long we keep information

9. How we protect information

• All traffic between apps and our servers uses TLS.
• Session refresh tokens are stored as SHA-256 hashes; tokens on your device are kept in the operating system's secure storage.
• Credentials for connected services are encrypted with envelope encryption using AWS KMS, with the master key held in a hardware security module and never exported. They are stored only on the server and are not sent to member devices.
• Long-lived provider secrets stay on the server; where a device must query a source directly it receives a short-lived, read-only token instead (about one hour).
• The local AI agent is blocked from reading known credential paths, secret-looking values are redacted before entering the shared session log, and reads outside the working folder are flagged in the audit log.
• Access to workspace content is enforced per space, database, page, and session.

No system is perfectly secure, and we cannot guarantee absolute security. If a breach affects your personal information we will notify you and the relevant supervisory authority as required by law.

10. Your privacy rights

If you are in the UK or EEA, you have the right to access, correct, delete, restrict, or object to our processing of your personal information, to data portability, and to withdraw consent where we rely on it. You may lodge a complaint with your local supervisory authority — in the UK, the Information Commissioner's Office (ico.org.uk).

If you are in California or another US state with a comprehensive privacy law, you have the right to know what we collect and why, to request deletion, to correct inaccurate information, to obtain a portable copy, and to opt out of the sale or sharing of your personal information — we do neither. You may use an authorised agent, and we will not discriminate against you for exercising any right. We honour Global Privacy Control signals on our web surfaces.

The categories of personal information we have collected in the last twelve months:

We do not collect sensitive personal information in order to infer characteristics about you, and we do not sell or share personal information.

How to exercise a right. Email hello@bottari.ai from the address on your account. We respond within 30 days (UK/EEA) or 45 days (US states), and will tell you if we need an extension. If your request concerns content in an employer-owned workspace, we will forward it to that organisation, which decides the outcome as the controller. If we refuse a request you may appeal by replying to our decision; we will answer an appeal within 45 days.

Inside the product you can already: edit your profile, hide your view history from teammates, delete your own messages, documents, and files, delete a meeting transcript, and disconnect a connected source.

Deleting your account. You can delete your account yourself in the Bottari app — on desktop under Settings → Account → Delete account, and on mobile by tapping your photo, then Settings → Account → Delete account. You can also email hello@bottari.ai from the address on your account, or follow the steps at bottari.ai/account-deletion. If you signed in with Apple's Hide My Email, please use the in-app option. Deletion takes effect immediately and cannot be undone: there is no grace period, and signing in again later with the same email address creates a new, empty account.

• Deleted immediately: your profile (name, email address, photo, job title, time zone, status, last sign-in); your Google, GitHub and Apple sign-in links, sessions, device records and push tokens; your personal settings and usage records (such as view history, read state, favourites and drafts). If you signed in with Apple, we also revoke Bottari's access in your Apple account; if that cannot be done automatically, the app tells you how to remove it in your Apple settings.
• Disconnected: data sources you personally connected (for example Google Analytics, Google Ads or Notion) are revoked at the provider and their imported records deleted; pages you published to the web are unpublished; your private databases are moved to Trash.
• Kept by your team, without your name: messages, documents, comments and AI session records you left in a shared workspace belong to that workspace and stay there, shown as from a "Deleted account". You can delete them yourself before deleting your account, or ask your administrator to.
• Kept for security: the team audit log keeps its records of what happened, with your name removed, for security purposes, and deletes them after 12 months like every audit entry. Account-level audit entries have their IP address, user agent and device removed immediately.
• Kept for usage limits and billing: AI usage records (model, token counts, cost) stay with the team, without your name.
• Already sent to Google Analytics: product milestone events sent before you deleted your account carry only a pseudonymous ID, are no longer sent after deletion, and are deleted by Google Analytics at the end of the retention period in Section 8.
• Teams you own: if you were the only member, the team is deleted and its content is permanently erased within 30 days. If other members remain and you were the only owner, ownership passes to the member who joined earliest — you see who before confirming, and you can make someone else owner beforehand.
• Backups: deleted information disappears from our backups within 30 days.

Leaving a team is different from deleting your account: your membership ends, but data sources and webhooks you connected for that team remain with the team.

11. Children

Bottari is a workplace tool and is not directed at children. We do not knowingly collect personal information from anyone under 16. If you believe a child has given us information, contact us and we will delete it.

12. Changes to this policy

We will post any change on this page and update the "Last updated" date. If a change materially affects how we use your personal information, we will give notice in the app or by email before it takes effect.

13. Contact