Trust

Security

lurq runs inside your editor and your CI. This is the boundary it operates behind, stated precisely enough to check.

What lurq never receives

lurq answers questions about packages, not about your code. The distinction is architectural, not a policy we promise to follow:

Your source code never leaves your machine. The MCP tools take package names and version ranges. There is no request shape that carries a file body.
Upgrade checks run locally. lurq check-upgradeintersects lurq’s surface diff with your source on your own runner. lurq is sent the result, which is symbol names and counts — never the lines they were found on.
No database credentials touch your machine. lurq is a hosted index; setup writes an API key and an HTTPS endpoint, and nothing else.

API keys

Keys are stored hashed. The dashboard shows a six-character prefix so you can tell two keys apart; the body is shown once, at creation.
Setup copies your key into each agent’s MCP config, so lurq logoutclears only the CLI’s copy. To invalidate a key everywhere, revoke it from the dashboard — that takes effect on the server, regardless of what is still written on disk.
Every authenticated request is rate limited per key, and every response carries standard RateLimit-* headers so an agent can back off correctly instead of retrying into a wall.

The GitHub App

Autopilot opens pull requests without lurq ever holding write access to your repository. It can do that because the writing happens in your CI, with your token:

Permission	What it is for	What it cannot do
Contents: read-only	Read manifests and lockfiles to compute drift.	Cannot push, open a PR, or write a file.
Metadata: read-only	Resolve repository names and default branches. Mandatory for every GitHub App.	Cannot change any setting.
No write scope of any kind	Every write in the upgrade loop uses your own GITHUB_TOKEN, inside your own runner.	Revoking is `git rm .github/workflows/lurq-upgrade.yml`.

The rewriting agent in that workflow runs under a fixed allowlist — Read, Edit, Write, and Bash limited to your package manager. It cannot touch version control, so it cannot push a branch, amend history, or change a workflow file, including its own.

Transport and browser hardening

HTTPS only, with HSTS (max-age two years, including subdomains) on every response from this site and the API.
X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy that denies camera, microphone, geolocation, payment, USB and ad topics — none of which this site has any use for.
The API server is fronted by helmet, a per-IP limiter ahead of authentication, and a per-key limiter behind it.

Reporting a vulnerability

Email contact@lurq.run with [security] in the subject. Include what you found, how to reproduce it, and what it lets an attacker do.

We respond within 3 business days to acknowledge, and aim to have a fix or a timeline within 14.
Please give us 90 days before public disclosure, and do not access or modify data belonging to anyone else while testing.
Good-faith research reported this way will not be met with legal action. There is no paid bounty today; there is credit, below, if you want it.

Machine-readable version: /.well-known/security.txt.

Acknowledgments

Researchers who have reported a valid issue are credited here with their permission. The list is empty so far.

What lurq does not have yet

Stated plainly, because finding this out during procurement instead of here helps nobody:

No SOC 2 report. lurq is operated by an individual. The controls above are real; the audit that would attest to them has not been run.
No Content-Security-Policy on the web app yet. A correct one has to be rolled out in report-only mode first, and that work is queued rather than done.
No public status page yet. Incidents affecting the API are announced by email to affected accounts in the meantime.

If one of these blocks an evaluation, tell us which one — that is the signal that moves it up the list.