Data handling & security

01 Implemented controls

Facts about the running system today:

• Private by default — nothing is published, listed or indexed, and there is no public registry, no aggregate scan-activity endpoint, and no endpoint that lists or enumerates analysed sites or searches across other customers' reports. A signed-in scan requires your session to view at all. A guest scan (no account) is bound to the browser that ran it by a private, HttpOnly cookie — knowing the report link is not enough to open it — and can be saved into an account from that same browser. Reports are shared only through signed, revocable /s/ links.
• Private report access — account-owned reports and screenshots require the owning signed-in session or API key, and are never linked from any public page or accessible by anyone else, including with the direct URL. A guest report's own link is its access credential (above) — treat any report link, guest or owned, as private.
• Redaction before storage — we never store raw response bodies, cookie values or browser-storage values, and tokens and authentication headers are stripped before any evidence is persisted. Cookie and storage names are shown so you can identify the affected item — a name is not a secret, its value is.
• Account & transport security — TLS in transit, salted PBKDF2 password hashing, HMAC-signed HttpOnly/Secure/SameSite session cookies, and an edge-only architecture. Billing is handled by Stripe; we never see or store card details.
• SSRF protection — a scan target's hostname is resolved before the scan starts and rejected unless every address it resolves to is public (a name that doesn't resolve is rejected too); outbound audit requests block loopback, private, link-local and cloud-metadata addresses and re-validate every redirect hop.
• No model training on your scans — audit content is sent to AI models only to produce your report at the time of the audit; it is not used to train models.

02 Product boundaries

Talon reads what your website already exposes to any visitor: response headers, the rendered DOM, network requests, cookies and browser storage created during a normal page load. It performs passive, low-impact analysis only. It does not exploit vulnerabilities, brute-force paths or credentials, run destructive tests, attempt authentication bypasses, flood ports, or perform denial-of-service or unauthorised active scanning. A Talon report is not proof that a site is secure or compliant, and Talon is not a replacement for an authorised penetration test. Entering a URL does not grant authorisation for active testing — only submit sites you own or are explicitly authorised to test.

03 Data handling

What we capture, redact, store and delete:

• Captured — response headers, rendered HTML, network request metadata, cookie flags, cookie and storage key names (not values), a screenshot, and the derived findings.
• Never captured or stored — cookie values, browser-storage values, raw tokens, authentication credentials, or full response bodies.
• Demo isolation — the "See Talon in Action" report uses the fictional domain northstar-demo.example and hand-written findings, isolated from production data. Customer data is never used in demos or marketing without explicit, documented consent.
• Retention — see Privacy Policy §08. Account-owned reports are kept until the owner deletes the report or account. Account data is deleted within 30 days of closure, and operational logs are rotated by our infrastructure provider after a few days.
• Deletion — signed-in users can delete individual reports and their full account from the dashboard. You can also email privacy@raptorlabs.dev; we complete accepted deletions within 30 days.

04 Responsible disclosure

If you believe you have found a security issue in Talon, email info@raptorlabs.dev and enough detail to reproduce it. Please do not access other users' data while testing. We aim to acknowledge reports within two business days and will keep you updated on remediation.

05 Planned controls

Domain-ownership verification, targeted verification scans for deterministic and supported browser-session findings, and weekly monitoring are already live in beta — see the docs for how they work. Client-side secret detection — pattern-matching the rendered page source for well-known live-credential formats — is live for verified domain owners only and never runs for guests or unverified accounts. Not yet implemented: the remaining deeper instruments that will require a verified domain (DNS & email posture, exposed-file scanning, technology and vulnerable-component inventory, and attack-surface / subdomain monitoring). These are labelled Beta or Planned wherever they appear on the site, and we do not present any of them as shipped until they are.