Threat model

GrayPass evaluates evidence about the operator of an authenticated application session and binds its decision to a specific action. This threat model explains what each participant must protect, which protocol controls address an attack, and where independent customer controls are needed.

The scope includes the customer API, browser and Node SDKs, proofs, and your application's integration boundary. Use it when choosing protected actions, policies, verification rules, and recovery procedures.

Assets and adversaries

Protect the subject-to-account binding, stored Brainprint, session evidence, policy configuration, proof-signing authority, pending business operation, and resulting financial or administrative action. Decision traces, enrollment records, and administrative activity also require confidentiality and integrity.

Relevant adversaries include an account attacker, a person taking over an unattended session, a script controlling the page, a thief replaying a proof, an operator using the wrong environment, and an administrator weakening a policy. Select controls for each attacker capability, including the page and device assumptions in Endpoint security.

Trust boundaries

Boundary	Responsibility	Integration control
Customer identity system	Authenticate the account and authorize enrollment.	Retain the account-to-subject mapping and enrollment evidence.
Browser and SDK	Collect derived observations under a scoped session.	Apply page and endpoint controls to the evidence producer.
Customer backend	Define the intended operation and enforce its decision.	Validate ownership and save the exact request before authorization.
GrayPass service	Evaluate policy, manage subject/proof state, and sign the result.	Interpret typed claims with coverage, freshness, and assessment context.
Relying-party verifier	Check proof binding and current state before execution.	Verify independently expected values and consume online.
Webhook channel	Deliver authenticated asynchronous events.	Deduplicate, handle reordering, and reconcile API records.

Threats addressed by protocol and implementation controls

Threat	Control	Integration requirement
Action substitution	Canonical action hash includes consequential request fields; verifier compares an independently stored request.	Include every consequential field and compare with the saved request.
Proof replay	Expiry, nonce binding, online revocation state, and single-use consumption.	Check current revocation and consumption through online verification.
Forged proof	ES256 signature validation against the expected issuer and key set.	Protect signing authority and configure independent verifier expectations.
Sandbox proof in live use	Separate signing keys and explicit tenant/environment checks.	Validate the expected tenant and environment for every proof.
Cross-tenant object access	Tenant and environment predicates; foreign-object requests receive non-disclosing failures.	Your own account-to-subject mapping must also be correct.
Evidence replay	Session-bound authentication, frame identifiers, timestamp/order checks, and overlapping-window rejection.	Protect the page that produces new authenticated evidence windows.
Malformed numerical evidence	Schema checks and validation of finite, in-range input.	Assess evidence provenance alongside numerical validity.
Browser policy tampering	Policies and authorization decisions live server-side under server credentials.	Restrict policy changes to approved administrators.
Repeated challenge loops	Bound challenge count and escalation to hold.	Your application must preserve the authorization chain and stop execution while unresolved.
Enrollment poisoning	Explicit anchor provenance, recovery policy, and customer-authenticated enrollment.	Establish the rightful account owner through your enrollment process.

Behavioral threats and evidence interpretation

For stolen-session use and operator handoff, examine continuity against the enrolled Brainprint and change indicators within the session. Review the claim status, evidence coverage, freshness, and quality together. Missing or insufficient evidence should follow the policy's explicit safe path rather than being treated as a match.

Automation indicators describe regularity or replay patterns in the observed evidence. Combine them with your endpoint controls and account authentication. Interpret freshness and coverage as evidence properties. Evaluate outcomes with representative users, input methods, handoff scenarios, and accessibility needs for the workflow you intend to protect.

Integration assumptions

Maintain a trusted browser, endpoint, first-party script environment, and extension policy.
Establish the rightful account owner before enrollment and recovery.
Apply independent controls for physical coercion and malicious intent by an authenticated user.
Execute protected operations only after the required decision and proof checks succeed.
Protect privileged access and signing-key authority with operational access controls and audit.
Include every consequential business field in the action binding.

Customer acceptance exercises

Test a changed destination or amount after authorization, a proof for another subject or audience, an expired or revoked proof, concurrent duplicate execution, stale evidence, a cross-environment credential, and an unavailable verification service. Each should reach the intended safe outcome without executing the protected mutation.

Test recovery with a weaker anchor, an unauthorized reviewer, and a previously revoked passkey. Test the crash between proof consumption and your business commit, including reconciliation across those separate transactions.

Use synthetic tests to exercise protocol handling, and consented participant sessions to measure challenge rates, holds, insufficient evidence, and false positives for your workflow. Set acceptance criteria before the evaluation and investigate differences across input methods and accessibility needs. See evaluation.

Review and change

Revisit this model when changing protected actions, enrollment/recovery policy, browser dependencies, proof verification, hosting, or role assignment. Request controlled supporting material through founders@graypass.org; its availability and permitted recipients are agreed separately.