Vulnerability Disclosure Policy

Last updated: August 24, 2026

If you have found a security problem in LinearPilot, we want to hear about it — we would rather hear it from you than from an incident. This page says what you may test, what protection you have while testing it, and what we will do when your report arrives.

What you may test

These are ours, and they are in scope:

• linearpilot.com — the public marketing site
• app.linearpilot.com — the product
• admin.linearpilot.com — the platform console
• The public API those applications call

These are out of scope, because they are not ours to authorise you to test:

• The systems of the providers that process data for us — Google, OpenAI, Anthropic, Deepgram, Groq, Soniox and Stripe. Report issues in their products to them; each runs its own disclosure programme.
• Content a customer placed in their own workspace. A customer's document being visible to that customer's colleagues is a configuration question, not a vulnerability in LinearPilot.

Safe harbour

Rules of engagement

Staying inside these is what keeps safe harbour in place:

• No denial of service, no load testing, and nothing else that degrades the service for the people using it.
• No social engineering or phishing of our staff, our customers, or our vendors. No calls, no pretexting, no password resets on an account that is not yours.
• No physical intrusion, and no testing of anyone's premises or hardware.
• Never access, modify, or copy data belonging to anyone else. Create your own account to test against, and use it.
• If you reach someone else's personal data, stop at once, do not keep it, and say so in your report. Proving you could get there is enough — we do not need the data as evidence.
• Automated scanning is fine at a rate that does not disrupt the service. Turn it down if you are unsure.
• Give us time to fix it before you publish. We will agree a date with you rather than ask you to wait indefinitely.

What we will not treat as a vulnerability

These are often correct observations about things that are not exploitable here. We will still read them, and we will close them without a fix:

• A missing security header with no demonstrated path to impact
• Self-XSS, or anything that needs the victim to paste code into their own console
• Absent rate limiting on endpoints that carry nothing sensitive
• A dependency a scanner calls outdated, without a working path from it to our service
• Mail configuration findings that do not affect delivery or allow spoofing
• Clickjacking on pages that take no authenticated action

How to report

Email us. Include as much of this as you have:

• The address, endpoint, or screen affected
• The steps to reproduce it, in order
• A proof of concept — a request, a script, or a short recording
• What an attacker gets out of it, in your assessment
• The test account you used, so we can trace it in our logs

What happens next

• We acknowledge your report within three business days.
• We give you our assessment within ten business days — whether we can reproduce it, how severe we think it is, and what we plan to do.
• We keep you updated until it is resolved, rather than going quiet after triage.
• We tell you when the fix ships, and we will confirm with you that it closes what you found.

Recognition

We do not pay bounties. We are a small company and we would rather say so here than let you discover it after the work. What we do offer is credit: with your permission we will name you as the finder when we publish the fix, in whatever form you prefer.

Conditions

You are responsible for complying with the laws that apply to you, including sanctions and export rules — we cannot accept reports from parties we are prohibited from dealing with. This policy is not open to LinearPilot employees or contractors, who have other routes to raise the same thing.

Contact

Send reports to [email protected].

This policy is also published in machine-readable form at /.well-known/security.txt.