Data handling & security

01 Implemented controls

Facts about the running system today:

• Private by default — reports, screenshots and findings are stored only for you to revisit. Nothing is published, listed or indexed. 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.
• Private report access — account-owned reports and screenshots require the owning signed-in session. Report and screenshot URLs are never linked from any public page. Treat any report link 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 — 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 §07. 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 findings, and weekly monitoring are already live in beta — see the docs for how they work. Not yet implemented: the deeper security instruments that will require a verified domain (DNS & email posture, exposed-file scanning, client-side secret detection, technology inventory and attack-surface 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.