Ottto Privacy Policy

Last updated: 2026-06-10

This policy explains what personal data Ottto collects, why, where it goes, how long we keep it, and the rights and controls you have. It covers every Ottto surface: the website and dashboard at ottto.net, the API at api.ottto.net, the Ottto local platform (daemon and CLI), the macOS companion app, Ottto for ChatGPT, and advisor recommendations. It is part of the same plain-language commitment as our Terms of Service: we tell you exactly what the software does, and we do not claim less than it does.

The short version: Ottto's job is to show you your own AI-tool usage. The product is built so that raw prompts, model outputs, file contents, and credentials never leave your machine. What we do collect is described below, completely.

1. Who is responsible for your data

Ottto is currently built and operated by Ron Shub, an individual based in Israel, operating under the name "Ottto" ("Ottto", "we", "us"). For data protection purposes (including the EU GDPR, where it applies), Ron Shub is the data controller for the personal data described in this policy.

You can reach us for anything privacy-related at hello@ottto.net.

We have not appointed a Data Protection Officer or an EU/UK representative; based on our current scale and processing, we do not believe we are required to. We will revisit this as the service grows.

2. What this policy covers

This policy covers personal data processed by the Ottto service. Two related documents apply in specific places:

• The Terms of Service, whose Section 5 is the binding description of what the local platform may read on your machine and upload.
• The Ottto for ChatGPT privacy supplement, which adds detail for the optional ChatGPT app. Where that supplement is more specific about the ChatGPT app, it controls for that app; this policy governs everything else.

The published open-source code of the local platform (github.com/ottto-ai/ottto) is not a data processing activity; running it is. This policy describes what happens when the local platform talks to the Ottto service.

3. What we collect, surface by surface

3.1 Account and sign-in

When you create an account we store: your email address, a password hash (we store passwords only as salted bcrypt hashes, never in plain text), an optional display name, your account settings, and email-verification status.

If you sign in with Google, we receive and store the identity Google asserts: a Google account identifier, your email address and its verification status, your display name, and (for Google Workspace accounts) the hosted domain. We request only the openid email profile scopes - we get no access to your Gmail, Drive, or anything else.

For account security we also keep: failed-login timestamps and lockout state, multi-factor authentication factors you enroll (authenticator-app secrets or passkey credentials), hashed session refresh tokens, and hashed API keys you create. Secrets in this list are stored hashed or encrypted; we cannot read your password or your API key back.

3.2 Workspaces and teams

If you create or join a team workspace we store the workspace name, your membership and role, and invitations (the invitee's email address, the assigned role, and who sent the invite). As the Terms explain, workspace administrators can see telemetry and reports synced into their workspace - choose the workspace you connect your devices to accordingly.

3.3 Local-platform telemetry (the core of the product)

This is the data the product exists to process, and it is deliberately minimized and derived. After you install the local platform and approve setup, it uploads to your account:

• usage totals: token counts (input, output, cache, reasoning), request counts, and per-model usage;
• model and tool identifiers, session identifiers, and timestamps;
• cost-relevant metadata and cost estimates;
• latency statistics (for example average and slowest response times);
• a hashed hardware identifier and a generated installation id, your device's display name, platform, and client version;
• a hashed workspace identifier (so we can group sessions by project without knowing the project's name or path);
• display-safe account or plan evidence (for example, which subscription plan a tool reports), used to attribute usage to the right plan;
• optionally - and you can turn each off in settings - session titles and workspace display labels.

What it must never upload is listed in Section 4. The authoritative, binding version of this inventory is Terms of Service Section 5.

3.4 Live telemetry (optional, per tool)

If you enable live telemetry for a tool, that tool sends its standard OpenTelemetry stream to a relay on your own machine, which forwards it to your account. From that stream we parse and keep usage metrics: token usage, cost figures, lines-of-code counts, active time, code-edit accept/reject counts, request latency, session and model identifiers, and similar operational attributes.

Ottto's setup configures your tools' telemetry with content logging off. We never instruct a tool to include prompt or response text in its telemetry, and our own parsers extract usage metrics, not conversation content. Live telemetry is enabled per tool, only with your approval, and can be disabled per tool at any time.

3.5 The dashboard AI assistant

The dashboard includes an optional AI chat assistant. When you use it:

• your chat messages are sent to an Anthropic Claude model running on Amazon Bedrock in our AWS environment. Under AWS's published commitments, Bedrock does not store your prompts or responses, does not share them with the model provider, and does not use them to train models;
• to operate and debug the assistant, we trace assistant conversations - including message content - to Langfuse, an LLM-observability service hosted in the EU (AWS Ireland), together with your user id, email, and name. Traces are used only for debugging and quality, are access-controlled, and are not used for advertising or model training. If you prefer not to have assistant conversations traced, do not use the assistant, or contact us to object (Section 11).

The assistant can call read-only tools that query your existing Ottto data (for example, cost charts). It introduces no new collection from your machine.

3.6 Advisor recommendations

Advisor analyses run over the telemetry already in your account, assisted by Claude models on Amazon Bedrock, with generated analysis code executed in an isolated AWS sandbox (Bedrock AgentCore, US region). Advisor runs process your usage aggregates and produce recommendations stored in your account. The same Bedrock no-storage, no-training commitments apply. Advisor runs may also be traced to Langfuse (Section 3.5) for debugging and quality - including run content and metadata - under the same safeguards and the same right to object.

3.7 Product analytics and session replay

We measure how the product is used in two ways:

• First-party analytics. The web app sends events from a fixed vocabulary (for example page_viewed, signup_completed, dashboard_opened, advisor and setup events) with: a random anonymous id (stored in your browser's localStorage), a per-tab session id, the route and path, your user and workspace ids when signed in, and event properties. Both the browser and the server actively reject properties that look like secrets, prompts, message content, or credentials before anything is stored. These events go to our own AWS storage.
• PostHog. We use PostHog, a product-analytics service, to understand pageviews, clicks, and feature usage, and to watch session replays of how the interface is used. When you are signed in, PostHog events are associated with your user id, email, and name. Replay is configured defensively: all keyboard input and form fields are masked, element attributes are masked, and replay is fully disabled on sensitive pages (sign-in, registration, settings, API keys, billing, setup, subscriptions, email verification, and invite acceptance) and during support sessions. PostHog stores this data on its US cloud (AWS, Northern Virginia) under a data processing agreement. You can object to this processing at any time (Section 11).

We do no advertising or marketing tracking: no ad networks, no Google Analytics, no Meta pixel, no cross-site tracking, and we do not sell or share personal data for advertising. Fonts are self-hosted; viewing our pages does not call out to font or CDN trackers.

3.8 Diagnostics bundles

Diagnostics collection is local-only by default. If support asks you to upload a bundle, the upload happens only with your explicit approval at upload time and your acceptance of the retention disclosure shown to you. Bundles pass through redaction designed to remove local paths, secrets, account and machine identifiers, raw prompts, and command output before upload. Uploaded diagnostics are retained for 30 days.

3.9 Email

We send transactional email only: email verification, workspace invitations, security and account-lifecycle notices (for example, account-deletion confirmations). Delivery goes through Resend, our email provider, which processes the recipient address, name, and message content for delivery. We send no marketing email today; if we ever introduce it, it will be opt-in.

3.10 Logs, security, and support access

Like every web service, our infrastructure keeps short-lived operational logs (IP addresses, request paths, user agents, service logs) for security and reliability. Load-balancer access logs and application logs are kept for 30 days.

If you ask for support, staff access to your account happens through a dedicated, short-lived, audited support-session mechanism - each support session and each security-relevant action is recorded in a durable audit trail. Product analytics and session replay are disabled while a support session views your account.

4. What we are built never to collect

The local platform is designed never to upload: raw prompts, raw model responses, tool or command output, file contents, absolute local file paths, browser cookies, OAuth tokens, API keys, passwords or other secret material, or raw provider account identifiers. Optional collectors that read locally stored credentials for a tool use them only on your device to fetch your own quota or plan information; those credentials are never transmitted to Ottto.

The same floor applies downstream: our analytics layers actively reject values that look like secrets or message content, the ChatGPT app's projection layer blocks identifier and content fields, and diagnostics redaction strips paths, prompts, and identifiers. If you believe any of this has failed, report it to hello@ottto.net and we will treat it as a security incident.

5. Why we process your data, and our legal bases

Where the GDPR or similar laws apply, we rely on the following legal bases:

Where Israeli privacy law (the Protection of Privacy Law) applies, the notice obligations of section 11 are satisfied by this policy together with the in-product setup and consent screens: we tell you whether you are legally required to provide data (you are not - using Ottto is voluntary), the purposes of each collection, who data is transferred to and why, how long we keep it, and the rights you have.

6. Cookies and similar technologies

We use a small, fixed set, all first-party:

No advertising cookies, no third-party tracking cookies, no cross-site identifiers. Browser controls (clearing site data, blocking storage) work normally; blocking the analytics keys does not break the product.

7. Who we share data with

We never sell personal data, and we never share it for advertising. Data leaves our systems only to the processors below, under data processing agreements, and only as needed to run the service:

Other disclosures we may make: to workspace administrators as described in Section 3.2; to a successor entity if the service is transferred to a company (the Terms, Section 19, govern this - your data moves with the same commitments); and where required by law, in which case we will notify you unless legally prevented.

We will keep this subprocessor list current in this policy and announce material additions per Section 13.

8. International transfers

Ottto's production systems run primarily in Israel (AWS il-central-1). For visitors and users in the EEA and UK this is the main "transfer": the European Commission has recognized Israel as providing adequate protection since 2011, and reaffirmed that adequacy decision in its January 2024 review; the UK carries an equivalent finding. Transfers from the EEA/UK to Ottto in Israel therefore need no additional mechanism.

Some processing happens outside Israel, as listed in Section 7: PostHog and Resend in the United States, Langfuse in Ireland, and specific AWS components in US regions. For US-bound transfers we rely on vendors' EU-US Data Privacy Framework certifications and/or Standard Contractual Clauses incorporated in their data processing agreements, and on the corresponding mechanisms recognized under Israel's data-transfer regulations.

9. How long we keep data

Where this table says "life of the account", the honest meaning is: we keep it until you delete it (you can delete telemetry sources and devices individually, or the whole account), because the product's purpose is your long-term usage history.

10. Security

Honestly stated, at the level that matters:

• All traffic is encrypted in transit (TLS); stored data is encrypted at rest in AWS.
• Passwords are salted bcrypt hashes; API keys, device secrets, and refresh tokens are stored hashed; MFA (authenticator app or passkey) is available on every account, and destructive actions (like account deletion) require fresh re-authentication.
• Production access is restricted, and staff viewing of customer accounts happens only through audited, short-lived support sessions.
• The local platform's binaries are signed and notarized; releases are built with provenance verification in our deployment pipeline.
• Defense-in-depth scrubbing rejects secret-like or content-like values at the analytics and ChatGPT-app boundaries.
• No system is perfectly secure. If we learn of a breach affecting your personal data, we will notify you and the relevant authorities as applicable law requires.

Security reports: hello@ottto.net (see the Terms, Section 9, for coordinated disclosure).

11. Your rights and controls

Built-in controls, available now:

• Delete your account, yourself. Settings → Danger zone → Delete account. You confirm with your email address; deletion enters a 30-day grace window during which you can cancel by signing back in, or you can choose to skip the grace period and purge immediately. Purge removes your account and associated data from our active systems and revokes your devices, and we send a confirmation when it completes.
• Delete a workspace you administer (same Danger-zone pattern).
• Disable telemetry per source, disconnect devices, and turn session titles and workspace labels off in Data & privacy settings.
• Withdraw the local platform's authorization entirely by disabling sources, logging out, or uninstalling (Terms, Section 5.7).
• Disconnect Ottto for ChatGPT at any time; revocation is immediate.

Rights you can exercise by contacting us at hello@ottto.net: access to the personal data we hold about you, a copy in a portable format, correction, deletion (if you prefer not to use the self-serve path), restriction, and objection - including objection to the analytics, session-replay, and AI-trace processing based on legitimate interests (Sections 3.5-3.7). A self-serve data export is being built; until it ships, export requests are handled by email. We will verify the request comes from the account holder, respond within one month (GDPR timeline) or any shorter period local law requires, and we do not charge for reasonable requests.

If you are in the EEA or UK, you also have the right to lodge a complaint with your local supervisory authority. In Israel, the supervisory authority is the Privacy Protection Authority. We would appreciate the chance to resolve any concern first.

We do not make automated decisions about you that produce legal or similarly significant effects. Advisor recommendations are informational suggestions you choose to act on (Terms, Section 8).

12. Children

Ottto is not directed at children. You must be at least 16 years old to use the service (or older where your local law requires a higher age - see the Terms, Section 3). We do not knowingly collect personal data from anyone under 16; if you believe we have, contact hello@ottto.net and we will delete it.

13. Changes to this policy

When our data practices change - a new subprocessor, a new data category, a changed retention period - we will update this policy before the change takes effect. For material changes we will give at least 14 days' advance notice (email to your account address, in-product notice, or a prominent note here), matching the Terms. The "Last updated" date always reflects the current version. Continued use after a change takes effect means the updated policy applies; if you do not agree, you can delete your account (Section 11).

14. Contact

Privacy questions, rights requests, objections, complaints: hello@ottto.net. Postal contact is available on request for legal process.