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 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; no repository source is sent for it at all. Raw repository source 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 keep a copy of that project's mapped repositories as ordinary git clones on our own application hosting, and we send the raw text of the specific files a failure points at, together with their repository, file path, and line provenance, to the opinion model that diagnoses an issue and, when Generate code fixes is also on, the models that draft a fix. No model receives your repository as a whole, and nothing computes a searchable index over it. 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 never carry repository source 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 the integration gateway below, WorkOS is our subprocessor rather than a connection you run on your own account. Processing is in the United States. WorkOS's data processing addendum becomes legally binding on the effective date of its subscription terms, and its execution counts as our signature to the Standard Contractual Clauses. You may object to this subprocessor on the grounds set out in section 4 of our Data Processing Agreement;
• Hostinger: virtual private server hosting for the application and its database, running in Hostinger's United States region. Hostinger's hosting agreement carries data processing clauses and a general authorization for it to engage its own subprocessors, and binds without a separate signature. It does not incorporate the Standard Contractual Clauses and sets no breach notification deadline, and we have not executed a separate agreement covering those;
• Cloudflare R2: durable object store copies of session evidence artifacts. These objects are envelope encrypted per tenant. Repository source is not stored here: where a project administrator has turned on repository code reading, we keep a copy of the repository as an ordinary git clone on our own application hosting, described in the section on what we send to AI providers;
• 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. Cloudflare's data processing addendum is incorporated by reference into its self serve subscription agreement and covers this product;
• 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. The AWS data processing addendum is incorporated into the AWS Service Terms and applies automatically to all customers;
• 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 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. OpenRouter's data processing agreement is incorporated by reference into its terms of service for organizations and commercial users, and carries Module 2 of the Standard Contractual Clauses, the UK addendum, and a seventy two hour breach notification deadline;
• 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
• Pipedream: integration gateway for connectors we do not integrate directly, and the one every connector card in the product routes through today. Data reaches Pipedream only where a tenant enables a gateway backed connector, and no other part of the Service routes through it. Where one is enabled, Pipedream holds the authorization for that tool, and every call we make to it is proxied through Pipedream, so the arguments and results of those calls pass through its systems. A data processing agreement is in force with Pipedream: its Data Protection Addendum forms part of its standard Terms of Service and incorporates the Standard Contractual Clauses. We have not confirmed a processing location or the retention of proxied payloads for this provider, so you should read this entry on the basis that those payloads may be retained. Nothing reaches Pipedream 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.

Where a project administrator has turned on Let AI read code, the copy we keep of that project's mapped repositories is not held on the session retention window. It is a working cache: we keep it while it is being used, remove the least recently used copies when we need the space, and delete it outright when the repository is unmapped, when the project or workspace is erased, or on your instruction. Deleting it removes only our copy; nothing is sent anywhere to delete it, because it came from your GitHub installation and is a copy of what is already there.

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. Where a project administrator has turned on Let AI read code, our copy of your repository is stored as ordinary source on the application host volume rather than under the envelope layer above, and is protected by deletion and access control rather than by encryption at rest.

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.