For agents

Privacy and data flow

This chapter follows the data needed for an action from the customer's application through GrayPass and back to the customer's backend. It distinguishes browser evidence from the fields the customer independently submits. Use the privacy chapter for retention and individual requests.

The action journey

Step Sender and recipient Information crossing the boundary
1. Authenticate User and customer application Your existing login, session, and account controls establish the account used by the integration.
2. Associate a subject Customer backend to GrayPass A customer-selected external reference and optional minimized metadata; GrayPass returns an opaque subject identifier.
3. Issue a browser token Customer backend to authenticated browser A short-lived token bound to the intended subject and allowed origin.
4. Observe interaction Browser SDK to GrayPass Bounded derived feature windows, session and integrity metadata, and optional coarse camera-derived summaries when enabled.
5. Request a decision Customer backend to GrayPass Subject, action, resource, context, audience, nonce, and idempotency identity.
6. Return a result GrayPass to customer backend Decision, typed Assurance Profile, reasons and limitations, and a proof or challenge where applicable.
7. Verify and execute Customer backend and GrayPass Proof status/consumption request, then the customer's own business transaction and outcome report.
8. Notify asynchronously GrayPass to configured customer receiver Selected event data through signed webhooks, alongside the synchronous authorization result used for execution.

The customer's backend maintains the account-to-subject mapping and the authoritative transaction record. Reconcile browser-supplied identifiers and transaction details with that authenticated session and saved record before proceeding.

Webhook destinations become additional recipients of event data. Apply access and retention controls, deduplicate deliveries, and reconcile lifecycle state through the API. Use the export process for an audit request. Recipient copies and previously queued deliveries follow their own retention and delivery lifecycles after subject deletion. See webhooks and individual requests.

Browser-derived evidence

The SDK computes summary statistics about interaction timing and movement. It does not transmit typed characters, clipboard contents, page text, form values, screen contents, audio, raw input event streams, or raw pointer paths as behavioral evidence. Keyboard handling may inspect physical key codes locally to derive timing and hand-class summaries; the codes and typed characters are not transmitted as evidence.

Evidence summaries are pseudonymous, subject-linked data. Protect their derived features, session identifiers, timestamps, and network metadata with the applicable access and retention controls.

Camera processing is optional and off by default. After an explicit choice and browser permission, the SDK processes images and face geometry on the device. Coarse gaze summaries and measured quality may enter the evidence window. Images, eye crops, face geometry, and raw gaze paths stay local. Calibration lasts for the current camera session. See optional camera evidence for consent, stopping, asset hosting, and quality handling.

Customer-supplied information

Choose the fields sent through subject metadata, resource identifiers, and action context deliberately. Apply the same data minimization to your application logs.

Use opaque identifiers and the transaction facts needed by the policy. A destination fingerprint binds an exact payment destination while keeping the full bank record in your system. Treat a fingerprint linked to a person as pseudonymous personal data. Keep free text, credentials, full documents, payment-card data, and unrelated business records in their dedicated systems.

Anchor evidence references record the customer's enrollment provenance. Your integration verifies the identity-provider assertion or identity-verification result and retains the evidence associated with that reference.

Processing and storage

GrayPass associates evidence and decisions with tenant- and environment-scoped subjects. An environment-scoped keyed hash transforms the external reference, preserving separation between customer environments.

Processing produces an enrollment template when enrollment succeeds and typed assurance when requested. The browser credential receives coverage and status. Authorization results and proofs belong to the customer backend, which decides what to show to the user.

Retention differs by record type. Decision traces, evidence-derived artifacts, sessions, events, and proof records follow environment retention rules. Subjects and templates persist until subject lifecycle operations remove them. Billing, administrative audit, and backup records have separate purposes and lifecycles. Use privacy to coordinate retention and erasure procedures.

Other service data

Console authentication processes administrator identity and session information. Administrative activity supports access control and incident investigation. Logs use redaction and identifier fingerprinting in relevant paths, while audit records may intentionally retain identifiers. Handle audit identifiers under the applicable access and retention controls.

Commercial operation adds contracting contacts, invoice details, payment status, and usage totals. The configured payment service handles payment collection separately from browser evidence. Usage totals follow the contractual meter definitions in usage and billing.

Research is a separate path

Research participation is off by default and is separate from the evidence processing needed to provide the service. Research retention requires all of these conditions:

  1. Research retention is enabled for the GrayPass deployment.
  2. Your environment permits research participation.
  3. The subject has a current granted consent receipt for the research disclosure.
  4. The submitted evidence frame explicitly opts in. The browser SDK's researchConsent: true option sends research_optin: true in each frame body.

The session response's research_enabled field reports environment and subject eligibility when the session starts. Storage is evaluated separately for each write against all four conditions above. Per-frame opt-in uses the JSON body field; request headers are independent of that choice.

Withdrawal records a revocation and stops future research writes. Historical donations remain until deletion; ordinary product processing continues for the service your application requests. Use the research and deletion procedures for those choices. Collect camera permission separately.

Research records are pseudonymous personal data. Apply the relevant disclosure, access, and retention controls, and collect each person's consent independently of environment settings.

Deployment and procurement questions

The hosted service runs in a United States cloud region. Review the applicable agreement and data-processing materials for the deployment, parties, subprocessors, transfer arrangements, and retention commitments that apply to your use.

Send review requests to founders@graypass.org with the scope and deployment details. Agree a secure transfer process before sharing confidential records.