Legal

Security

How CLItrail protects the data it handles, what you can do to protect your organisation, and how to report a security problem. CLItrail is a project developed by Pilot Protocol and operated by Vulture Labs, Inc.

Status
In effect
Effective
24 September 2026
Applies to
The hosted CLItrail service at clitrail.com, the website tag, the installer hook and the collection API
On this page

Summary

Credentials
Encrypted at rest and never displayed in full after you save them.
Addresses and tokens
No raw IP addresses stored by CLItrail. Receipts, tokens and sessions kept only as hashes.
Reports
Email founders@pilotprotocol.network. No sign-in needed.

How 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).
  • Encrypted credentials. Saved destination and log-stream credentials are encrypted at rest and are not displayed in full again. You can replace them in the dashboard or revoke them through the platform that issued them.
  • Write-only credentials. A saved credential is never shown again. Removing a destination or log stream deletes its saved credentials.
  • 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, allowlisted third-party scripts for Google sign-in and Google Analytics and X measurement with visitor opt-out controls, 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 to manage your credentials.

Where it runs

Cloudflare hosts CLItrail and stores its data. Google provides sign-in through Firebase Authentication, and Stripe processes payments. The Subprocessors page lists every provider, and how we tell you before that list changes.

Your 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.

If 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.

Incidents

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.

Report 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.

What we do not claim

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

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