Security and Workspaces

Veritik applies authentication, workspace authorization, server-side data access, and PostgreSQL security controls. Security is a shared responsibility between the platform and each organization using it.

Authentication

Veritik supports:

• Email and password authentication.
• Google SSO through Supabase Auth.

Google SSO requires a verified Google email. When it matches an existing account, Veritik links the Google identity rather than duplicating the account. Veritik then issues its standard secure application session.

Sessions

Application sessions use an HTTP-only cookie. Session tokens are stored as hashes in the database and expire after the configured session lifetime.

Users should log out when using shared devices and should never share cookies, tokens, passwords, OAuth codes, or screenshots containing secrets.

Users with a Veritik password can change it from Profile. Veritik verifies the current password, requires a new password of 8–256 characters that differs from the current one, and revokes other sessions after a successful change while preserving the current session. Google-managed accounts continue to manage their password through Google.

Workspace Isolation

Recruitment data is associated with a workspace, including jobs, candidates, status history, notes, and usage. Protected server operations verify both the authenticated user and their workspace membership.

A platform administrator may have separate administrative authorization. Administrative capability should not be confused with ordinary workspace membership. The Candidates and Global Pipeline pages are also workspace-scoped even though they combine records from multiple jobs.

Profile Information

The Profile page displays the signed-in user's full name, email, login method, membership role, company or workspace, plan, account status, and relevant creation dates. Full name is editable; identity, membership, and plan fields are read-only because they come from authentication and workspace records.

Optional Product Analytics

The public landing page asks for permission before enabling first-party product analytics. When accepted, Veritik stores a random identifier in an HTTP-only cookie to measure landing visits and CTA usage. It is not based on device fingerprinting and does not contain account or candidate information. Declining does not block the website or recruitment workflow.

Authenticated activation events are recorded from successful server operations and use verified user/workspace context. Product analytics metadata excludes resume contents, candidate personal data, prompts, and AI output.

Database Security

Public PostgreSQL tables use Row Level Security and restricted grants where configured. The Supabase service-role key can bypass RLS, so Veritik only uses it in server-side modules and route handlers.

Never expose SUPABASE_SERVICE_ROLE_KEY to browser code or prefix it with NEXT_PUBLIC_.

Request Rate Limits

Veritik applies server-side rate limits to authentication, password recovery, public analytics, resume upload, rubric generation, and interview-question generation. Normal use and the supported CV batch concurrency remain within these limits. Repeated or unusually high-volume requests may receive HTTP 429 with a Retry-After value indicating when the user can try again.

Rate-limit counters are shared through PostgreSQL so they remain consistent across application instances. Network and account identifiers are protected with a keyed hash before storage; Veritik does not store raw IP addresses or email addresses in the rate-limit table. Rate-limit storage failures are recorded without candidate content and do not expose internal database errors to users.

Internal Operational Alerts

Super Admin monitoring creates sanitized alerts for actionable CV processing, AI provider, stale-processing, and telemetry-storage failures. Expected user-input outcomes such as OCR-required documents, invalid files, and trial quota limits remain visible in aggregate metrics but do not create operational alerts.

Alerts contain workspace and operational UUIDs, category, severity, lifecycle status, occurrence count, and timestamps. They do not contain candidate names, filenames, contact details, resume text, prompts, or AI output. Alert lifecycle values are Open, Acknowledged, and Resolved. A repeated operational failure reopens a resolved fingerprint, while a stale-processing alert is resolved when that attempt is no longer stale.

Candidate Data Responsibilities

Organizations using Veritik should:

• Have a lawful basis or proper authorization to process uploaded resumes.
• Upload only data required for recruitment.
• Limit access to authorized team members.
• Follow applicable privacy, retention, and deletion policies.
• Verify AI output before using it in a decision.

Authorized workspace users can permanently delete an individual candidate from Candidate Profile after exact-name confirmation. Server authorization verifies the active user, workspace, job, and candidate before a service-role-only database function performs the operation atomically. Candidate notes and status history are removed, current CV quota is released, and candidate references in retained operational telemetry become null.

Deletion audit records intentionally exclude candidate names, contact information, resume text, AI output, and recruiter notes. They retain only operational UUIDs, actor, reason, and timestamps. Automated retention and workspace deletion are separate controls and are not enabled by individual candidate deletion.

Service Providers

Veritik relies on authorized infrastructure, database, authentication, hosting, and AI providers to operate the service. Depending on the feature, this may include Supabase, Vercel, OpenAI, and Google. Candidate data is not sold, but it may be transmitted to these providers when necessary to deliver the requested functionality.

Review the public Privacy Policy, Terms of Service, and AI Disclaimer before using Veritik with production candidate data.

Reporting an Issue

Do not include passwords, API keys, service-role keys, OAuth client secrets, session cookies, or complete candidate records in a support message. Describe the issue and provide redacted evidence where possible.