<!-- Markdown version of the Capcat doc "Hosted data and privacy" (rendered page: https://capcat.ai/guide/privacy.html). Docs index: https://capcat.ai/llms.txt, full single-file version: https://capcat.ai/llms-full.txt -->

# Hosted data and privacy

This page describes the hosted service at `capcat.ai`. A self-hosted deployment is operated by its owner and does not send data to Capcat unless that owner explicitly connects it to the hosted service.

## Default verification

Capcat uses a signed, single-use computational challenge and browser instrumentation to validate each attempt. The widget does not use advertising cookies or create a cross-site advertising identity. Normal HTTP request data is still processed to deliver and secure the hosted service, so “no ad tracking” does not mean that no security data is processed. This includes how a verification request reached us: the HTTP protocol and TLS parameters reported by our network edge, round-trip time, and which request headers were sent (names, not values). For abuse detection these are reduced to coarse classes, such as "HTTP/2, TLS 1.3, Chrome-shaped headers", and counted per hour; raw TLS handshake values are not kept.

## Optional Account Defense

Account Defense is off unless both the site owner and Capcat's rollout controls enable it for the exact site. A signed challenge policy authorizes collection; a page cannot turn collection on by itself.

When enabled, the widget may process a page-scoped window of at most 15 seconds and 128 samples. It sends only bounded aggregates such as input modality, activation, focus and visibility state, motion/timing histograms, and sample counts. Raw pointer coordinates and raw event sequences remain in browser memory and are cleared after redeem, reset, disconnect, or timeout.

The hosted Worker may also derive coarse network/protocol categories and short-window velocity. Raw IP addresses are used transiently to create keyed pseudonyms. Those pseudonyms rotate daily, are kept inside a per-site coordinator, and are not returned to another customer. Account Defense does not place raw IP, full user-agent strings, raw behavior payloads, tokens, or pseudonymous IDs in its hourly aggregate table or customer verdict.

## Retention and outputs

| Data | Operational retention | Notes |
| --- | --- | --- |
| Raw in-browser samples | Current bounded collection window | Never uploaded as coordinates or event sequences |
| Risk metadata bound to a verification token | Configured token lifetime (5 minutes for new sites; 20 minutes for sites created before November 2026) | Deleted on one-time consumption or expiry |
| Token context bound to a verification token (solve time, page hostname, keyed digest of the /24 or /64 network prefix, network ASN, coarse browser family and version) | Token lifetime | Not returned to the browser; kept until the token expires so that a retried verification can be answered. No raw IP or full user agent |
| Per-site rotating network/cohort pseudonyms and velocity events | 20 minutes | Daily key epoch; no cross-tenant lookup |
| Low-cardinality `risk_hourly` aggregates | 30 days | Bounded scheduled cleanup; no event or user identifier |
| Hourly counts of connection and header classes (coarse browser family and version, protocol/TLS class, header-shape digest, consistency flags) | 35 days | Per site and hour, capped number of rows; no IP, full user agent, header values, or per-request rows |

Event-level assessment/feedback datasets and ML training cohorts are separate, defaults-off features. They require an explicit approved cohort and their own purpose, access, retention, and deletion terms before collection. Ordinary Account Defense traffic is not silently promoted into ML training labels.

The browser receives only an opaque verification token. If a site selects score mode, its secret-authenticated backend may receive a versioned `risk_*` verdict with a `0..100` risk index, coarse reason codes, model version, and signal coverage. Other tenants' data and raw identifiers are never included.

## Widget badge referrer

The Capcat badge in the widget corner links to `capcat.ai` and, when clicked, passes the embedding page's origin (for example `https://example.com`, never the full URL or path) so we can attribute the referral. To suppress this, set `window.CAP_DISABLE_WIDGET_REF = true` before `cap.js` loads; the link then carries no origin. Paid plans can hide the badge entirely (see [Hiding the badge](https://capcat.ai/guide/widget.md#hiding-the-badge-paid-plans)). No referrer is sent by loading the widget alone.

## Site-owner responsibilities and controls

Site owners should disclose the hosted verification and any enabled Account Defense processing in their own privacy notice, choose the appropriate legal basis for their users and jurisdiction, and provide any required user-rights channel. They can disable behavior, edge, realtime, score exposure, or managed enforcement independently. Disabling enforcement does not require deleting compatibility readers; in-flight one-time tokens remain bounded by their expiry.

For the exact integration behavior, see [Protection Stack](https://capcat.ai/guide/protection.md) and [Server-Side Verification API](https://capcat.ai/guide/siteverify.md).
