Security

01How your data is protected

• Collecting less. The website tag keeps page addresses only as origin and path and sets no cookies. The installer hook reads only CLItrail receipt files inside browser storage folders and a few coarse system facts, never history, cookies or passwords, and exits at once under DO_NOT_TRACK=1, CLITRAIL_DISABLE=1 or in CI (unless you set CLITRAIL_ALLOW_CI=1). CLItrail collects no names or contact details of your visitors and installers.
• Hashes, not values. Visit receipts, handoff tokens and dashboard session tokens are stored only as SHA-256 hashes, and invitation links as keyed hashes. IP addresses are never stored by CLItrail: rate limits and reconstruction use keyed hashes, and reconstruction hashes are deleted when its window ends (72 hours by default, at most 7 days).
• Credentials in a separate store. Every credential you give CLItrail, from GA4 API secrets and Google service account keys to Meta, TikTok and X Ads tokens and keys, S3 access keys and signing secrets, is encrypted with AES-256-GCM and bound to its own record. The encrypted values live in a dedicated store, a separate Durable Object that serves no HTTP and answers only the service. The main database holds only a reference, the last four characters and a fingerprint.
• Keys apart from both. The master keys are platform secrets, never stored in either database. The service does not start without them in production, and they can be rotated without downtime.
• Write-only credentials. A saved credential is never shown again. Deleting one overwrites it with zeros before removing it.
• Logs without secrets. Every request CLItrail receives and sends is logged with its exact body, but access tokens, API secrets, signatures and Authorization headers appear as [redacted], receipts and tokens as keyed hashes, and IP addresses as keyed hashes.
• Encryption in transit and at rest. CLItrail is published at an HTTPS address with HSTS, and requests that carry a credential are refused unless they arrive over HTTPS. Cloudflare® encrypts the stored data at rest with AES-256.
• Access. Sign-in is with Google, or with a one-time sign-in link sent to your email address, through Firebase Authentication; CLItrail keeps no password. Every request is checked against your role in the organisation. Deleting a website, an organisation or your account asks for a fresh sign-in.
• The web app. A strict Content Security Policy, no third-party scripts apart from Google’s sign-in helper on the dashboard, framing blocked, and a limited referrer policy.
• Recovery. Cloudflare keeps point-in-time recovery data for 30 days.

Annex II of the Data Processing Addendum lists every measure. Security and secrets in the documentation explains how they work.

02Where it runs

CLItrail runs on Cloudflare Workers®, with its database and its separate secret store in Cloudflare Durable Objects™ and our operator copy of the logs in Cloudflare R2. Sign-in is provided by Google through Firebase Authentication, and payments by Stripe. The Subprocessors page lists every provider, and how we tell you before that list changes.

03Your part

• Protect the Google account or mailbox you sign in with, using 2-step verification or a passkey.
• Give each person the lowest role they need, and remove people who no longer need access. Invitation links work once, for 7 days, and only for the invited email address.
• Create destination and log-stream credentials with the narrowest access the platform allows (for S3, only s3:PutObject on your prefix), and revoke them at the platform when you stop using them.
• Keep the installer hook’s opt-outs (DO_NOT_TRACK, CLITRAIL_DISABLE, CI detection) in place.
• Never paste secrets or other people’s personal data into a support request.

04If an account or credential is compromised

1. In Account and security, sign out every other session.
2. Secure your Google account or mailbox.
3. Revoke any destination or log-stream credential you are unsure of at the platform that issued it, then replace it in CLItrail.
4. Email founders@pilotprotocol.network.

05Incidents

If a personal data breach affects your organisation’s data, or credentials you gave us may have been exposed, we tell your organisation’s owners by email from founders@pilotprotocol.network without undue delay after we become aware of it, with what we know, what we are doing and whom to contact. The Data Processing Addendum sets out the details.

06Report a vulnerability

Email founders@pilotprotocol.network. You do not need a CLItrail account.

Include

• what you found and where: a page or API route on clitrail.com, the website tag (browser.js), the installer hook (report.sh) or the collection API;
• the steps to reproduce it, and what an attacker could do with it;
• how to reach you.

Please

• use only accounts, websites and data you own or are allowed to test with;
• stop as soon as you have shown the problem: do not keep access, change or delete data, or read other people’s data;
• never send live credentials, private keys or other people’s personal data; use redacted samples;
• do not test by overloading the service, and do not use social engineering, phishing or physical access;
• give us a reasonable chance to fix the problem before you publish it.

Out of scope

• vulnerabilities in Google, Meta, TikTok, X, Stripe, Cloudflare or Firebase themselves: report those to the company concerned;
• reports that only list missing headers or software versions without showing an impact;
• rate-limit or volume tests against the live service.

What happens next. We read every report, work with you on the details, and tell you when the problem is fixed. We do not run a bug bounty and do not promise a fixed response time.

The same contact is published in /.well-known/security.txt.

07What we do not claim

CLItrail holds no third-party security certification and makes no uptime commitment (Terms §2).

08Related

Data Processing Addendum · Subprocessors · Privacy policy · Terms of service · Security and secrets in the docs