Last updated: June 5, 2026
This is what HireKey looks like behind the front-end: where the data lives, who can touch it, and what we do to keep it safe. We have tried to avoid security theater. We do not use phrases like "bank-grade" or "military-grade" because those words do not describe anything. The specifics below are what we actually do.
Application hosting. HireKey's frontend and backend run on Vercel. Production services are isolated by environment.
Application database. Customer content (resumes, transcripts, briefings, account data) is stored in Supabase, a managed PostgreSQL service, encrypted at rest with provider-managed keys. Row-level security policies control which records each user can access.
Object storage. Uploaded resumes (PDF, DOCX) and saved voice recordings are stored in an encrypted object store with access policies that block public access.
AI inference. When users invoke AI-powered features, the relevant input is sent to our AI providers' APIs. We do not store a separate copy of their server-side logs.
Backups. Supabase maintains regular encrypted database backups on a rolling retention window.
In transit. All connections to HireKey use TLS 1.2 or higher with modern cipher suites. HSTS is enforced.
At rest. Database and object storage are encrypted with AES-256 using provider-managed keys.
Secrets. Application secrets are stored in a managed secrets manager, not in source code or configuration files.
Production access. Limited to a small, named set of engineers who need it to operate the product. Access requires SSO with hardware-backed multi-factor authentication.
Privileged actions. Production database access and changes to security-critical configuration are logged and reviewed.
Customer access. End users authenticate with Google OAuth. Sessions are tied to short-lived tokens. Suspicious sign-in events trigger additional verification.
Offboarding. When someone leaves, their access is revoked the same day.
Code review. Changes to production code require peer review before merge.
Dependency scanning. We track and patch known vulnerabilities in third-party dependencies on a rolling basis. Critical CVEs are addressed quickly.
Web application defenses. Standard protections against SQL injection, cross-site scripting, and CSRF are in place. We use a Content Security Policy on the web application.
Rate limiting and abuse prevention. Per-IP and per-account rate limits, behavioral anomaly detection, and hashed device fingerprints help prevent automated abuse.
Application logs. Errors, warnings, and significant events are captured by Sentry and retained for 30 days.
Security logs. Authentication, authorization, and administrative actions are logged and retained for at least 1 year.
Alerting. Automated alerts notify the on-call engineer about availability issues, error spikes, and suspicious activity patterns.
We have a written incident response process. Detection → Triage (within 1 hour for P0/P1) → Containment → Investigation → Notification (within timelines required by law if personal data was affected) → Postmortem.
Reports of suspected security issues: security@hirekey.io. We acknowledge reports within 1 business day.
Supabase maintains regular database snapshots and continuous point-in-time recovery. Backups are encrypted at rest with the same key management as production data. We test backup restoration regularly..
Personnel with production access undergo background checks where permitted by local law. All employees and contractors sign confidentiality agreements covering customer data. New hires receive security training during onboarding, and the team reviews security topics at least annually.
| Vendor | Purpose | Data received |
|---|---|---|
| Vercel | Application hosting and CDN | Request metadata, application traffic. Does not receive resume content or AI inputs. |
| Supabase | Managed PostgreSQL database | All structured customer data: account profiles, resumes, transcripts, briefings, application tracker, usage records. |
| Anthropic | AI inference (primary) | Resume text, job descriptions, interview responses, coaching context. Not used to train public models under our contract. |
| OpenAI | Text-to-speech (voice coaching only) | Text of AI coaching responses for audio synthesis only. Does not receive your voice input or resume. |
| Stripe | Payment processing | Name, email, billing address, payment method. HireKey does not store full card numbers. |
| Google (OAuth) | User sign-in | Email, name, profile photo, Google account ID only. |
| PostHog | Product analytics | Usage events, basic device info, anonymized user ID. Does not receive resume content or transcripts. |
| Sentry | Error tracking | Error stack traces, browser info, redacted request context. PII redaction is enabled. |
We do not use third-party advertising networks, data brokers, enrichment vendors, or HR/hiring data marketplaces.
HireKey does not currently hold a SOC 2 report. Most of the controls a SOC 2 audit would test are already implemented and described in this document. We are working toward SOC 2 Type 1 and will update this page when the report is ready. We would rather be a company that says "not yet" than one that pads its credentials.
We do not yet have a formal bug bounty program. We accept responsible disclosure at security@hirekey.io and will credit reporters who request it.
Our AI providers are Anthropic (reasoning and content features) and OpenAI (text-to-speech). Customer content sent to either provider is not used to train their public models under our contractual agreements. Network communication with both providers is over TLS. We do not send unnecessary data: payment information, account IDs, and other non-AI-relevant fields are excluded from all AI calls.
Security questions and reports: security@hirekey.io