Trust

Privacy constitution

The rules below are implementation constraints. Where the code and this page disagree, the code is a bug.

1. Derived features only

The SDK computes summary statistics about how input happened: timing distributions, movement kinematics, scroll and focus rhythm. It does not transmit keystroke content, clipboard content, page text, form values, screen contents, audio, or video as behavioral evidence. Keyboard handlers read physical key codes locally to derive timing and hand-class summaries; those codes and characters do not leave the browser.

Optional eye tracking processes camera images, face geometry, and gaze estimates locally. Only coarse derived summaries and measured sampling and calibration quality enter evidence windows. Images, eye crops, face geometry, and raw gaze paths are never uploaded by the SDK.

2. Local computation, minimal transmission

Feature extraction happens in the browser. What crosses the network is a bounded feature window under a documented schema (features/v1), plus integrity metadata. Raw event streams do not leave the device.

The camera is off by default and starts only after an explicit choice and browser permission. Local calibration is kept in memory for the current camera session. Declining or stopping the camera supplies no gaze evidence and no camera-related penalty; other permitted interaction collection can continue.

3. Tenant-scoped, non-portable identifiers

A subject id is opaque. It maps to your identifier through a keyed hash (HMAC-SHA-256 with a deployment pepper) computed per environment. The same person enrolled in two tenants produces two unrelated hashes. There is no global identity graph, and no API that could build one.

4. No universal tracking

Evidence is scoped to a session created for a declared purpose. There is no persistent cross-site identifier, no third-party pixel, no analytics vendor, and no shared cookie. The product loads no third-party scripts, fonts, or network endpoints: the Content Security Policy for every product surface allows first-party origins only.

5. Revocable by the subject, deletable on request

• POST /api/v1/subjects/{id}/revoke immediately stops the Brainprint being used and revokes outstanding proofs.
• DELETE /api/v1/subjects/{id} deletes the template, kills live sessions, and clears subject metadata.
• POST /api/v1/subjects/{id}/export returns what GrayPass holds. It does not return the template vector, because a template is not human-readable and releasing it would create exactly the cross-context matching risk this document forbids. The export says so explicitly rather than pretending the data does not exist.

6. Retention minimization

Each environment has a retention window (sandbox defaults to 1 day, live to 90 days) covering evidence-derived artifacts, decision traces, and events. Subjects and their templates are never removed by the retention window in a customer environment; they are deleted only on request or by revocation and recovery. The public demo environment is the single exception: it is marked ephemeral, and visitor subjects are deleted when its one-day window lapses. The retention sweep is implemented and locally tested. Scheduling it on a hosted service remains an external launch gate.

7. Encryption

Templates, recoverable proofs, and stored request material are encrypted at rest with Fernet keys held outside the database. The production design requires asymmetric keys in AWS KMS; local development uses separate test keys, and non-development code accepts no local private-key fallback. The deployed KMS, TLS, and surrounding infrastructure are verified by operators as part of each release, not by the application itself.

8. Model artifacts separate from identity

Model weights and calibrators contain no subject identifiers. Research artifacts, when consented, are pseudonymized with a salted hash before storage.

9. Research participation is explicit and revocable

Off by default at the environment level and in each browser session. A versioned, immutable subject consent receipt is also required for every research write. Withdrawing consent appends a revocation receipt and stops future donation immediately. Product processing and research participation remain separate.

10. No score to the browser

A browser calling the canonical API with a browser credential receives a coverage level, accepted-window count, active time, modalities present, freshness, and a human-readable status. Challenge completion returns only a receipt for the customer backend. That credential never receives a trust score, similarity, per-signal breakdown, threshold, full Assurance Profile, or Proof of Agency. A relying-party backend may deliberately render its own decoded proof and Assurance Profile, as the local demo does. Scores are not shown because a number invites a false sense of precision that our evaluation does not support.

11. No data sales, no trait inference

GrayPass does not sell, rent, or share behavioral data. It does not infer health, disability, neurological status, emotion, demographics, or any trait unrelated to session control. See prohibited-use.md.

12. Logs are peppered and redacted

Application logs carry peppered fingerprints instead of identifiers, and a redacting formatter strips secrets. Notes attached to outcomes are stored only as digests.

What your users should be told

Include something like this in your own privacy notice:

For actions that could cause you harm if performed by someone else, we ask GrayPass to check whether the person operating this session is still you. GrayPass measures patterns in how you type and move, never what you type or see. You can ask us to delete this at any time.

Generated from the API contract in contracts/ and the source in docs/. The build fails if this page disagrees with the running API.