How we crawl, score, and fix — safely.

How our crawler behaves

• Polite by construction: each crawler instance limits itself to about one request per second, with a self-identifying User-Agent that links back to our methodology.
• robots.txt is honored. Sites that disallow crawling are excluded from scans and marked excluded on the Index rather than crawled anyway. We sell trust in agent behavior; our own crawler goes first.
• Public pages only. Scans read what any anonymous visitor can read. We never crawl behind authentication.

Server-side, fail-closed gating

• Every gate is enforced server-side — plan limits, rate limits, spend budgets, and ownership checks are re-validated where the work happens, never only in the UI.
• Fetches are SSRF-guarded: every scan, audit, and journey — public, private, and Index — fetches through a guard that refuses private, loopback, link-local, and cloud-metadata address ranges and re-validates every redirect hop. The opt-in JS-rendering diagnostic mode is confined by construction: it can only be started against our curated Index target list — never customer submissions — its browser traffic is default-denied to those targets' own domains by request interception (service workers blocked, WebSockets denied) with the same resolved-address checks, backed by a connect-proxy allowlist whose tunnels refuse non-public addresses, and its non-rendered fetches re-validate every redirect hop — the same egress discipline our live interaction-testing runner uses.
• Missing security configuration halts the feature rather than degrading it — for example, the public scanner refuses to run at all if its IP-hashing salt is absent.

Domain verification before anything acts on your behalf

Agent journeys, whole-site audits, and fix pull requests only run for a domain after its owner proves control via a DNS TXT record — checked when you request the work andre-checked server-side at the moment it runs. Live interaction testing is additionally gated on an explicit, recorded consent grant, and its checkout-class tasks refuse to start if a live payment key is detected on the target.

Untrusted content stays untrusted

• Crawled pages are data, never instructions. Content we scan is delimited and marked untrusted before any model reads it, and scoring agents are instructed to ignore instructions embedded in scanned pages.
• Scoring agents are read-only: the probe and journey agents used for scoring can fetch pages and record findings — they structurally have no tool that mutates anything.
• No fabrication: fix suggestions must cite evidence from your actual pages; models are instructed to leave a TODO rather than invent URLs or facts.

The GitHub App: minimal scope, PR-only

• Repository contents (read & write) on the repositories you select — nothing org-wide. This is the one permission fix delivery needs: reading your docs and pushing a fix branch.
• Everything ships as a pull request. Nothing is ever merged by us — a human on your side reviews and merges, or closes.
• AI-drafted edits are labeled. When a PR contains model-drafted doc edits (an explicit per-repo opt-in), the PR discloses it prominently, marks each such edit, and names the model.
• Revocable at any time from your GitHub settings; the link between a property and a repo is re-checked against the App's current grant every time before a PR opens.

Data handling

• Scan snapshots are of public pages, retained to make scores reproducible and disputable (see disputes & corrections).
• IP addresses are stored only as salted hashes for rate-limiting, with the salt held server-side as a managed secret.
• No analytics SDKs, no tracking cookies, no consent banner needed — see the privacy policy for the full statement.
• Sub-processors: Anthropic (scoring models), Supabase (database), Stripe (billing), Vercel (hosting), Tinybird (agent-traffic analytics, paid opt-in feature), Resend (transactional email), Google Workspace (our own email) — the same list as the privacy policy, kept in lockstep.

Where we are on formal compliance

We are early: no SOC 2 report yet. We maintain a controls checklist mapped toward SOC 2, every production-touching change passes an internal security review before merge, and this page will state it plainly when a Type I report exists — not before.

Responsible disclosure

Found a vulnerability? Email contact@prolectio.com with details and a way to reach you. We'll acknowledge quickly, keep you informed, and credit you if you'd like. Please don't access other users' data or degrade the service while testing.