Privacy Policy

1. Information we collect

Account and billing information. When you create an account, authentication is handled by our identity provider (Supabase Auth), which manages your email and password. We never see or store your password. If your organization signs in with single sign on, Supabase Auth authenticates through WorkOS, and, where your organization also enables directory sync, WorkOS sends us SCIM events carrying employee email, name, group membership, and directory state, which we use to suspend, reinstate, and revoke access for tenant members automatically. Group membership events reach us, but we do not currently act on them. A directory event never creates a membership: a member record is created when that person first signs in and their verified email domain matches your tenant. Deprovisioning suspends the membership and deletes the hosted authentication identity rather than deleting the membership record. We store your email, your organization/tenant membership, and, if you subscribe, billing identifiers from our payment processor (Stripe). We do not store full payment card numbers; Stripe processes payments.

Session and evidence data (Customer Data). Through our SDK and the sources you connect, the Service captures session evidence such as interactions, network requests and redacted payloads, console output and errors, environment and feature flag state, and, where you enable them, backend spans and row level database changes. This data can contain personal information about your end users. By default, the browser SDK masks text nodes, keystrokes, and form values in page snapshots before capture. Input events use the same deny biased redaction policy as request payloads, so ordinary numbers and short codes may be recorded. You can explicitly unmask one element or block an element and its contents. The client side redaction layer also masks values for sensitive fields before capture, including password, email, and telephone inputs, elements you mark as sensitive, and field names matching your redaction rules, and it masks common secrets and personal data on a best effort basis. Recording of input values can be switched off entirely through your capture configuration.

Data from connected tools. When a tenant authorizes a connection from our connector catalog, which covers issue trackers, code hosts, error tracking, logging and observability platforms, and incident tools, the Service may process the information that connection returns and stores only the derived bundle after redaction. You authorize each connection with credentials you control and can revoke it at any time.

Product metrics. We collect usage metrics in two places. Our servers record aggregate activity, for example plan activity, project and service creation, and volume events, keyed to project and tenant identifiers rather than to individual people. The dashboard also loads a client side analytics tool (PostHog), which records page views, clicks, and specific product actions such as creating a project, opening a captured issue, requesting a fix, and starting an upgrade. Those dashboard events are associated with the email address you sign in with, and carry identifiers and names drawn from your workspace, such as project, service, issue, and session identifiers and your current plan.

Dashboard session recording. We record your use of the dashboard itself, so that we can see where the product is confusing or broken. The recording reconstructs the pages you visited and what you did on them, together with your browser console output. Values you type into form fields are masked before the recording leaves your browser. Text already displayed on the page is recorded as displayed, and that includes captured session evidence shown in the dashboard, which can contain personal information relating to your own end users. This recording covers our dashboard only. It is not part of the Service you embed, it never runs in your application, and it does not change what your own SDK captures.

Marketing site analytics. Our public marketing site uses a client side analytics tool (PostHog) to count visits, see which pages and referrers bring people to us, and record whether a contact form was submitted. It captures page views and clicks on the site itself. It does not record sessions or screen contents, and we do not send your email address, name, or message text to it. We do not use advertising or cross site tracking cookies on the dashboard or the marketing site.

Communications. If you contact us or submit our contact form, we receive the information you provide, such as your email, name, and company.

2. Cookies and local storage

The dashboard stores your authentication token in your browser to keep you signed in. Our analytics tool also stores a first party identifier in the dashboard, so that repeat visits from the same browser are recognized as the same person rather than counted as new ones. We do not set third party advertising or cross site tracking cookies on the dashboard.

Our public marketing site sets a first party analytics cookie so that repeat visits from the same browser are counted once rather than as separate people. It holds a random identifier and no personal information. We do not set third party advertising or cross site tracking cookies anywhere.

3. How we use information

• to provide, operate, secure, and maintain the Service;
• to assemble fix ready context and, unless you turn it off, AI assisted diagnosis;
• to process subscriptions, billing, and account administration;
• to respond to support requests and communicate about the Service;
• to identify, prevent, and address security, fraud, and abuse; and
• to comply with legal obligations and enforce our Terms.

4. Legal bases (EEA/UK)

Where the GDPR or UK GDPR applies to information for which we are the controller, we rely on: performance of a contract (to provide the Service you request); our legitimate interests (to secure and improve the Service), balanced against your rights; your consent (where required, such as certain optional features); and compliance with legal obligations. For Customer Data we process on your behalf, you are responsible for establishing the lawful basis with respect to your end users.

5. Optional AI processing

AI assisted diagnosis is on by default, and you can turn it off at any time. While it is on, we send derived structural metadata, such as the detector, the severity, which areas of your stack the evidence touched, and for a representative failed request its HTTP method, sanitized route, and status code, through our AI gateway (OpenRouter) to a model provider. We may also include short payload snippets from failed network requests. These snippets are bounded to a small size and passed through a secret stripping step that works on a best effort, heuristic basis to remove credentials, cookies, authorization headers, and token like values before the snippets leave our systems. Raw evidence such as clipboard contents, keystrokes, transcripts, stored values, full cookies, input values, console text, and unknown payloads is not sent.

Similarity search on issue evidence uses a hosted embedding model reached through our AI gateway (OpenRouter) on this Service. A self hosted deployment, and any deployment with no gateway credential configured, uses an on device method instead and sends nothing. Only the already redacted bundle text is sent for issue similarity; raw repository source text is sent only under the separate opt in described below. Embedding requests carry provider preferences that require zero data retention and deny data collection.

A fourth category applies only if a project administrator turns on Let AI read code for that project, which is off by default and is a separate, per project opt in from the AI assisted diagnosis setting above. When it is on, we send the raw text of that project's indexed repository source chunks, together with their repository, file path, and line provenance, to the embedding model that indexes them, the opinion model that diagnoses an issue, and, when Generate code fixes is also on, the models that draft a fix. That source text is sent verbatim, with no redaction or secret stripping pass, because stripping values out of source code would strip the exact values needed to diagnose the failure; this is a deliberate design choice, not an oversight, and it means a hardcoded secret in your repository reaches the model provider. By default every one of these code carrying requests is sent with provider preferences that require zero data retention and deny data collection, so our gateway routes it only to a provider serving it under those terms and rejects the request when none is available. That routing is enforced by the gateway rather than verified by us on each response. An organization administrator can remove that restriction for the whole workspace, through a request that must repeat an exact acknowledgement sentence and that we record in the audit log with the administrator who made it. While it is removed, requests carrying your repository source text, and the other model requests described in this section, may reach providers that retain prompt content or use it to train their models. It stays in place until an administrator removes it, it applies to the whole workspace rather than to one project, and any administrator can put it back at any time. Embedding requests are not affected and stay restricted either way.

Two narrower model requests carry the same retention preferences, and the same workspace setting governs them. When we analyze a repeat issue, we may include a short summary of the findings a model previously wrote for a similar issue, bounded to a few hundred characters each; that summary is model authored prose and can restate what it observed in your evidence or, where code reading was on for that earlier issue, in your source. We also send bug signature and error family strings when we group related issues across a tenant. Neither request includes repository source text, payload snippets, or raw evidence.

6. How we share information

We do not sell personal information, and we do not share it for cross context behavioral advertising. We share information only with service providers (subprocessors) that help us run the Service, under contracts that limit their use of the data, and as required by law or to protect rights and safety. Where we have not yet executed a written data processing agreement with a subprocessor, we say so in its entry below and rely on that provider's published terms until an agreement is executed. Our principal subprocessors are:

• Supabase: authentication and database hosting;
• WorkOS: single sign on for organizations that enable it, and, where a tenant also enables directory sync, SCIM based provisioning. It authenticates administrators and members who sign in through your identity provider, and, for directory synced tenants, it sends us SCIM events carrying employee email, name, group membership, and directory state, which we use to suspend, reinstate, and revoke access for tenant members automatically. Group membership events reach us but we do not currently act on them, and a directory event never creates a membership. The WorkOS account and its API credentials are ours, not your organization's, so under the same account ownership test we apply to Composio below, WorkOS is our subprocessor rather than a connection you run on your own account. Processing is in the United States. We have not executed a data processing agreement with WorkOS. You may object to this subprocessor on the grounds set out in section 4 of our Data Processing Agreement;
• Railway: application hosting;
• Cloudflare R2: durable object store copies of session evidence artifacts and, where a project administrator has turned on repository code reading for a project, the raw repository source chunk text and file paths that the code index is built from. These objects are envelope encrypted per tenant;
• Cloudflare Turnstile: bot protection on our public submission forms, which receives the visitor's IP address and the challenge token from that form. Our configuration requires it for public submissions on the live service. We have not confirmed an executed data processing agreement or a processing location for this provider;
• Amazon Web Services (Simple Email Service and Simple Notification Service): transactional and product email, and delivery event notifications for that email. Each live deployment sends through either this provider or Resend; our configuration records that the United States deployment uses this one. We cannot tell from the code alone which provider a given deployment is running, so treat both email entries as engaged. We have not confirmed an executed data processing agreement for this provider;
• Upstash Vector and Cloudflare Vectorize: hosted vector indexes for the repository code index. They receive the embedding vectors computed from your repository source chunks together with project identifier, repository name, file path, start and end line, chunk key, embedding model name, and index generation, namespaced by tenant identifier. They do not receive the source text itself. Both are optional configuration and are engaged only where repository code indexing is turned on; when both are configured the Upstash index is used. Our configuration notes record that the Cloudflare index is globally distributed with no region control, which is why a deployment that must keep the index in one region configures the Upstash index instead. We have not confirmed an executed data processing agreement or a processing location for either;
• Stripe: payment processing and billing;
• OpenRouter and the AI model providers it routes to: optional AI assisted diagnosis (redacted, derived metadata plus short, secret stripped payload snippets), embeddings for issue similarity search, and, only where a project administrator turns on Let AI read code for that project, raw repository source chunk text. By default those code carrying requests are sent with provider preferences that require zero data retention and deny data collection, so our gateway routes them only to a provider serving them under those terms and rejects the request when none is available. An organization administrator can remove that restriction for the whole workspace, and while it is removed those requests may reach providers that retain prompt content or use it to train their models. Embedding requests stay restricted either way;
• PostHog: aggregate, tenant level product metrics from our servers; dashboard product analytics and dashboard session recording, both associated with the email address you sign in with, where the recording can include captured session evidence displayed on screen; and marketing site analytics;
• Resend: transactional and product email for deployments configured to use it; and
• Composio: integration gateway for connectors we do not integrate directly. Data reaches Composio only where a tenant enables a gateway backed connector, and no other part of the Service routes through it. Where one is enabled, Composio holds the authorization for that tool and receives the arguments and results of every call we make to it. Composio's public materials conflict on whether it keeps those payloads. Its MCP Gateway page describes a zero data retention architecture in which tool call payloads and credentials are never stored on its infrastructure, and states that logs hold metadata only with retention configurable from 7 days to 1 year. Its own API documentation describes a Logs endpoint returning, for each tool call, the full request payload and response body. We cannot reconcile those two statements from public sources, so we treat payloads as retained and you should read this entry on that basis. Processing is in the United States. We have not located a published subprocessor list for Composio, so we cannot tell you who else is in that chain. Nothing reaches Composio unless you enable a gateway backed connector.

7. Customer directed integrations

When a tenant enables a connection from our connector catalog, data flows to and from that tool at your direction and under its own privacy terms. Where you connect an issue tracker, some flows post an advisory comment on a ticket. You authorize each connection with credentials you control, and you can disconnect any of them at any time. Because these connections run on your own account with the tool, the provider is not our subprocessor.

8. International transfers

We and our subprocessors are located primarily in the United States, and information may be processed there. Where we transfer personal information from the EEA, UK, or Switzerland, we rely on appropriate safeguards such as the Standard Contractual Clauses.

9. Data retention

Session and evidence data is retained for your plan’s retention window and then purged from both storage and our database. Default windows are 30 days on Team, 90 days on Business, and 180 days on Enterprise, with trial workspaces on the Team window, and can be adjusted for your tenant. Account and billing records are kept while your account is active and for as long as needed to meet legal, accounting, and security obligations, after which they are deleted or anonymized.

10. Security

We protect information with measures appropriate to its sensitivity, including encryption in transit. Durable object storage artifact copies are envelope encrypted per tenant when the deployment configures the artifact key, and the hosted deployment configures that key. The local staging volume on the capture host is not yet covered by this envelope layer. Connector credentials are sealed with authenticated encryption (AES 256 GCM) and are not readable back by us. API keys and CLI tokens are stored only as one way hashes, never in plaintext. Passwords are managed by our identity provider and never stored by us. A client side redaction layer masks values for sensitive fields before capture on a best effort basis; masking of all text and input values by default is not part of any published SDK version. No system is perfectly secure, so we cannot guarantee absolute security.

11. Your rights

Depending on where you live, you may have rights to access, correct, delete, port, or restrict the processing of your personal information, to object to certain processing, and to withdraw consent. If you are in the EEA or UK, you may also lodge a complaint with your local data protection authority.

If you are a California resident, you have the right to know what personal information we collect, to delete it, to correct it, and to opt out of any sale or sharing of it. We do not sell or share personal information, and you will not be discriminated against for exercising these rights.

12. Exercising your rights

To make a request about information for which we are the controller, contact us at contact@crumbtrail.ai; we will respond as required by applicable law and may need to verify your identity. If your request concerns end user data captured by a company that uses Crumbtrail, we will refer you to that company, which is the controller of that data.

13. Children

The Service is intended for businesses and is not directed to children. We do not knowingly collect personal information from children. If you believe a child has provided us personal information, contact us and we will delete it.

14. Changes to this Policy

We may update this Privacy Policy from time to time. When we make material changes, we will update the “last updated” date and, where appropriate, provide additional notice.

15. Contact

For privacy questions or requests, contact us at contact@crumbtrail.ai.