Production operation
Configure, monitor, and operate your hosted GrayPass integration. Assign owners for evidence collection, policy administration, request handling, and outcome reporting. Use live shadow mode alongside your existing execution path; exercise proof-backed execution in your sandbox.
Keep configuration explicit
Record the tenant, environment, API origin, proof issuer, audience, SDK archive versions, action key, active policy version, registered browser origins, and webhook endpoint. Separate sandbox and live secrets and application state. Resolve subject and merchant ownership from the authenticated application session.
Give runtime services only the credential scope they need. Keep action and policy administration in a controlled setup path. Rotate credentials through a reviewed process and verify the new credential identity before withdrawing the old one. Never log secret keys, browser tokens, raw proofs, full request bodies containing sensitive material, or webhook secrets.
Roll out in stages
- Complete sandbox schema, challenge, proof, replay, lifecycle, and failure testing around a mock business operation.
- Review the data flow, user messaging, account recovery, optional evidence consent, and operating responsibilities.
- Run an agreed shadow evaluation alongside the existing application path. Label actual outcomes accurately and budget for applicable production usage.
- Review evidence coverage, decision distribution, support needs, and the evaluated sample.
- Record the evaluated configuration and your security and business owners' rollout decision. Confirm the action's effective mode after each configuration change; if the API rejects a change, keep the previous mode and investigate the returned code.
Changing policy requirements is a versioned configuration change. Review and activate a new version, observe its results, and preserve a rollback target. Investigate the evidence and risk behind challenge rates before approving a policy change.
Monitor the application boundary
| Signal | Why it matters | Operational response |
|---|---|---|
| API errors and timeouts | Decisions may be unavailable | Refuse or hold; investigate dependency health |
| Rejected or stale evidence | Coverage may not satisfy policy | Check origin, token, transport, timing, and browser lifecycle |
| Challenge and hold rates | User friction or policy mismatch | Inspect reasons and evaluated populations |
| Proof verification failures | Binding, time, key, or scope problem | Stop execution and preserve a safe diagnostic trace |
| Online consumption ambiguity | Business operation may need reconciliation | Use your durable request ledger |
| Outcome-report lag | Evaluation data may be incomplete | Retry reports without replaying business mutations |
| Webhook and reconciliation lag | Notifications may be delayed or missing | Inspect delivery state and fetch authoritative records |
| Usage and invoice differences | Commercial accounting may need review | Compare the agreed billing window and meter definitions |
Set alert thresholds from your application requirements and observed behavior. Confirm any contractual service commitment with GrayPass and record the incident contact and escalation procedure with your operators.
Failure and retry policy
Retry transient transport failures with bounded exponential backoff and jitter. Preserve the same logical request, idempotency key, nonce, and security-relevant payload. A changed request requires a new key. Resolve policy, schema, credential, or ownership errors before retrying.
If an idempotent request is still in progress, wait before retrying. If its stored result became stale because the subject, action, or policy changed, create a newly reviewed request. A consumed proof has completed its single use. Timeouts after consumption need business-state reconciliation.
Maintain synchronized clocks for request freshness, proof validity, and webhook freshness. Keep a supported TLS configuration and restrict egress to reviewed service origins. Generate the authorization timestamp from the backend's synchronized clock.
Incident response and recovery
For a suspected compromised customer account, suspend affected business operations through your application, revoke the subject as appropriate, stop active observers, and invalidate your own sessions. Review pending requests and proofs. Use your established account recovery process before re-enrollment or passkey registration.
For a leaked server credential, revoke and replace it, inspect its activity and configuration changes, and rotate related application secrets according to your incident scope. Coordinate GrayPass subject revocation with your application's own login-session revocation.
Preserve trace IDs, timestamps, environment, stable error codes, versions, and sanitized descriptions of expected versus observed behavior. Contact founders@graypass.org for integration assistance; use the security reporting process in Security for vulnerabilities.
Data and commercial operation
Assign an owner and schedule for customer-side deletion and export requests, review retention settings, and distinguish subject lifecycle from billing records. Match each export request to the endpoint's response bounds and arrange additional history through the agreed privacy process. Keep optional research consent separate from ordinary service use. Retain a suitable deletion marker in asynchronous receivers so a delayed event cannot recreate a deleted subject. Queued webhook deliveries and dead letters follow a separate delivery lifecycle; follow Webhooks when handling them.
Use the contractual billing window in Console Billing when reviewing usage. Assessment retrieval can record qualifying assurance activity, so avoid using session-assessment requests as health probes. Use service health or a bounded operational check instead. Disputes, corrections, invoices, payment issues, renewal, and termination follow Usage and billing, Invoices and payments, and Renewal and lifecycle.