Privacy, retention, and individual requests

GrayPass processes derived interaction evidence for action-specific assurance, without inferring health, disability, emotion, demographics, productivity, or unrelated traits. This chapter describes data handling and integration responsibilities; your executed agreements and applicable privacy notices govern the legal terms of processing.

Before collecting evidence, explain its purpose to users and provide a recovery and support route. Integrate GrayPass alongside your authentication with transparent, purpose-specific collection. See supported use and customer responsibilities.

Minimize collection at the integration boundary

The browser SDK summarizes how interaction occurred, without uploading the typed content or raw event streams as behavioral evidence. Optional camera processing is local; only coarse derived summaries are sent when enabled. These properties apply to the SDK evidence path. Your backend can separately transmit sensitive data in subject metadata or action context, so review those fields independently.

Use an opaque customer reference where practical. Store your account-to-subject mapping in your own authorized system and scope identifiers to their customer, environment, site, and purpose.

Retention is record-specific

Retention is applied by a periodic sweep, rather than at the exact instant each record reaches its age limit. The sweep also stops abandoned sessions. Use environment settings for operational retention and the applicable agreement for contractual retention commitments.

Revocation

Use POST /api/v1/subjects/{id}/revoke when assurance for a subject must stop, including suspected compromise or the beginning of recovery. Revocation marks the subject revoked, revokes its outstanding proofs and registered passkeys, cancels pending challenges, stops associated sessions, retires browser-token access, and discards the stored Brainprint template.

Revocation preserves relevant lifecycle and decision records according to their retention rules. Use deletion for erasure. Recovery creates a fresh enrollment and template under the subject's recovery policy. Check proof status online to observe revocation of a previously issued proof.

Deletion

Use DELETE /api/v1/subjects/{id} through an authorized server or administrative workflow. Deletion stops the subject's sessions, removes the stored template, deletes subject-scoped records including evidence, enrollments, authorizations, proofs, challenges, passkeys and research consent records, and removes linked research donations. It records a deletion event without retaining the deleted subject identifier in that event payload.

Keep a customer-side deletion request record and confirm successful completion. For an error response, inspect its code and retry according to the lifecycle procedure. Use the subject deletion operation for erasure and revocation for stopping reliance on the subject.

Backups, billing evidence, independent administrative audit records, customer systems, and webhook recipient copies follow separate retention and erasure procedures. Queued webhook deliveries and delivery-retry records continue through their delivery lifecycle, so an older event can arrive after subject deletion. Keep a minimal deletion marker at your receiver to discard stale events for that subject. Coordinate remaining service-side records through the agreed privacy process, including backup and legal-retention handling.

Export scope

POST /api/v1/subjects/{id}/export returns the subject representation, template-presence metadata, enrollment history, and selected authorization, session, passkey, and research-consent records. Template vectors and passkey credential material remain protected within the service and are excluded from the export.

Authorization, session, passkey, and research-consent lists include at most 500 records each; enrollment history includes at most 100 records. The endpoint returns this bounded view without pagination. Check these bounds against the scope of an individual request, especially for a long-lived subject.

For an individual request requiring additional records, contact founders@graypass.org with the requested scope. Agree a secure retrieval and transfer process for personal records before sharing an export.

Research choices

Research participation is optional and off by default. Set up the applicable research disclosure with GrayPass before offering it. Research retention requires deployment and environment enablement, a current granted receipt from the subject, and explicit opt-in on each donated evidence frame. Collect each person's consent separately from tenant configuration.

Collect and honor the person's choice as follows:

1. Present the applicable research purpose and disclosure separately from your core application terms and any camera permission.
2. After the authenticated person makes a choice, have your backend call POST /api/v1/subjects/{id}/research-consent with {"consented": true} or {"consented": false}. Use the subject resolved from your authenticated account mapping.
3. Keep your own record of the choice and disclosure shown. The endpoint returns the subject record; GrayPass stores a separate receipt with the fixed purpose behavioral_model_research and disclosure version research-consent/1. Show the disclosure matching that version. Receipt metadata is included in the bounded subject export.
4. Enable researchConsent: true on the browser observer only for a granted choice. It sends the required per-frame JSON field research_optin: true; opt-in is evaluated from this body field, independently of request headers. The ordinary observer default is false.
5. On withdrawal, record {"consented": false} and stop the opted-in observer. If ordinary observation continues, restart it with research consent disabled. Continuing to send opted-in frames without current environment permission and subject consent returns a validation error.

Receipts are append-only: a new grant or withdrawal changes the current choice while preserving its history. The session's research_enabled field summarizes environment and subject eligibility at session creation. Storage is evaluated separately at research-write time and requires deployment enablement, the current granted receipt, and per-frame opt-in. A withdrawal takes effect for subsequent writes, including those from existing sessions.

Withdrawal stops future research writes and preserves historical records. Subject deletion removes the linked consent receipts and donations through the procedure above. Research records are pseudonymous personal data; apply the appropriate disclosure, access controls, and retention handling.

Logs, support, and disclosures

Service logs use identifier fingerprinting and secret redaction where applicable; audit records can retain identifiers needed for investigation. Review customer-provided metadata separately before logging it. When escalating an issue, share request identifiers, timestamps, environment kind, reason codes, and a synthetic reproduction first.

Your user notice should explain the consequential actions covered, the kinds of derived evidence, the authentication used for enrollment, the recovery route, relevant retention, and how to make an individual request. Explain and collect optional camera and research choices separately. Use an approved privacy notice and data-processing agreement for your deployment and users.