Security model
Adaya is built around a server-mediated architecture: browser applications call Adaya's backend, the backend validates the request and the user's company context, and only then does it access recruiting data. Database and service-role credentials are kept out of public browser bundles.
Our security work is risk-based and evolves with the product. This page describes safeguards currently represented in the Adaya codebase; it is not a promise that any system is immune from every threat.
Identity and access
Managed authentication
Dashboard identities are authenticated through Supabase Auth, and backend requests verify the user's current access token before returning protected data.
Active membership checks
Protected company routes require an active company membership for the requested workspace, not merely a valid account.
Role-aware access
Workspace roles and database policies distinguish owners, admins, recruiters, viewers, and system operations where supported.
Protected sessions
Dashboard access and refresh tokens are stored in HTTP-only, SameSite cookies; production cookies are also marked Secure.
Tenant and data controls
Company scoping
Recruiting queries and records carry company context so an authorized user operates within the intended workspace.
Row-level policies
Tenant, candidate, application, document, note, notification, audit, and AI-chat tables use PostgreSQL row-level security policies as a second layer of access control.
Private documents
Candidate resumes are limited to PDF, capped at 5 MB, stored in a non-public bucket, and delivered to authorized recruiters through short-lived signed URLs.
Server-side secrets
Database credentials, Supabase service-role keys, and AI provider keys are configured on backend services and are not intended for client-side exposure.
Application and API safeguards
Adaya validates route parameters, account inputs, job configuration, application submissions, file metadata, and AI tool inputs against explicit schemas. The API also uses security headers, configured cross-origin controls, request-size limits, and centralized error handling.
Hosted database connections are configured to use TLS by default outside local development. We continue to review data flows as integrations and communications features are added.
AI safety and human oversight
Application-review prompts instruct the model to use only job-relevant evidence and not to use or infer protected-class attributes. Structured output is schema-validated, provider and model metadata can be recorded, and the current review decision is explicitly marked human_review_required.
AI output can still be wrong or biased. Customers must review the underlying application, provide appropriate accommodations, monitor outcomes, and make the final employment decision.
A bounded role for AI
The product uses AI to prepare evidence and next steps for a recruiter—not to silently replace the recruiter responsible for the decision.
Auditability and operations
The product records audit events for important recruiting activity such as account and company setup, job changes, application submissions, document uploads, notes, AI reviews, and application status changes. Events preserve durable identifiers and limited context rather than duplicating full candidate payloads.
Operational request logging and product audit history support troubleshooting and accountability. Access to logs and production systems should remain limited to people with a legitimate operational need.
Customer security responsibilities
Manage access
Use individual accounts, assign the least-privileged role that fits the work, and disable access promptly when a person leaves or changes responsibilities.
Protect credentials
Use strong, unique passwords, protect access to connected email and calendar accounts, and report suspicious sign-in activity quickly.
Minimize data
Collect and upload only information that is necessary, lawful, and job-related. Do not upload patient records or unsupported high-risk identifiers.
Review automation
Keep humans accountable for candidate communications and employment decisions, and periodically review configured questions, criteria, and AI instructions.
Assurance posture
Security certifications, independent audit reports, penetration-test summaries, and regulatory commitments will be listed here only when they are current and applicable. Adaya does not claim a certification or compliance status merely because a cloud or infrastructure provider holds one.
The service is designed for recruiting data. Do not use it for patient clinical records or protected health information unless a separate written agreement expressly authorizes that use and identifies the required safeguards.
Report a security concern
Send suspected vulnerabilities or security incidents to hello@tryadaya.com with the subject “Security report.” Include the affected URL or feature, a concise description, reproduction steps, and your preferred contact information.
Do not access another person's data, degrade the service, use automated high-volume testing, or publicly disclose a potential issue before we have had a reasonable opportunity to investigate. We will acknowledge responsible reports and coordinate next steps based on severity and available information.