Data access controls
Row Level Security (RLS)
Every table with user data has RLS enabled. Policies enforce that users can only read and write rows that belong to them. Workers cannot read other workers’ credentials, proofs, or profile fields beyond what they have explicitly disclosed.
SECURITY DEFINER functions
Sensitive cross-user operations (resolving disclosure scope, generating disclosed profiles, validating share links) run as SECURITY DEFINER stored procedures. These functions run with elevated privilege inside the database, where the full context is available, and return only the authorized subset to the caller. Application code cannot short-circuit this logic.
Employer isolation
Employers can only see credentials and clearance data that workers have explicitly shared with them. Clearance checks are scoped to the requesting employer’s jobsite configuration. Anomalous access patterns are detected and flagged automatically.
Share links and tokens
Hashed token storage
Share link tokens are SHA-256 hashed before storage. The raw token is only held in the URL given to the worker. The database stores only the hash — a database breach does not expose usable share link tokens. Expiry and single-use options are enforced server-side.
Audit trail
Profile access logging
Every access to a worker’s public profile — whether via direct URL, authenticated session, or share link — is logged with viewer identity (if authenticated), access type, the disclosure scope granted, and a timestamp. Workers can review who has accessed their profile. Eligibility recomputations are also logged with the full component breakdown.
Fraud signals
Duplicate credential detection
System flags identical documents submitted by different workers. Both profiles are flagged for admin review.
Velocity anomaly
5 or more credential uploads within 24 hours triggers a fraud signal flag on the worker profile.
Document tampering detection
AI extraction flags inconsistencies between document metadata and extracted fields. Flagged credentials are held for manual review.
Expiry manipulation
Credentials with altered or implausible expiry dates are flagged. Admin review is required before approval.
Operational security
All data is stored on Supabase-managed infrastructure. Database connections use TLS in transit. Supabase enforces encryption at rest.
Service role keys are not exposed to client-side code. All privileged operations go through server-side Next.js route handlers or server components using the anon key with RLS.
Admin actions (proof approval, clearance overrides) require an authenticated session with admin role confirmed server-side before any mutation is executed.