Trust

Security

Effective: 2026-05-21 · Version 1.0

TalentOS handles candidate data, offer letters, salary information, and audit-grade hiring decisions for multi-subsidiary enterprises. This page summarises the controls we have in place today and the policy that governs how we work with independent security researchers. Every claim about the platform maps to code in our production deployment; nothing is aspirational.

Reporting a vulnerability? Jump directly to How to report or read the full coordinated disclosure policy. The machine-readable contact lives at /.well-known/security.txt.

Data at rest

  • Vercel KV (Upstash Redis) stores all tenant business data — vacancies, candidates, offers, audit log, sessions, library items, API keys. Encryption at rest is provided by the platform.
  • Vercel Blob (CDN-fronted) stores binary uploads — CVs, JD attachments, assessment files, tenant logos. Each blob has an unguessable id and is access-gated by our /api/upload/[id] route.
  • AES-256-GCM is applied on top of platform encryption for highly sensitive per-tenant secrets — customer-supplied Anthropic API keys, SSO client secrets. Derived from a 32-byte platform key never exposed to the client.
  • Passwords never stored in plaintext. Hashed with scrypt (N=16384) + per-user 128-bit salt; constant-time verification via Node's timingSafeEqual.

Data in transit

  • TLS 1.2+ everywhere. The talentosglobal.co certificate is auto-renewed by Vercel; HTTP requests redirect to HTTPS at the edge.
  • Outbound webhooks require HTTPS endpoints and are signed with HMAC-SHA256 (key = your webhook secret). Every payload includes a Unix timestamp in the signed envelope so receivers can reject replays older than 5 minutes.
  • API tokens use a 67-character format (tk_… + 64 hex). Tokens are never logged; only the first 12 chars are persisted in plaintext for UI display. The full token is hashed on storage (same scrypt parameters as passwords).

Authentication

  • Password policy: 12-character minimum, mixed character classes (or 16+ passphrase), and a Have I Been Pwned k-anonymity check on every signup + reset. Breached passwords are refused with the breach count surfaced to the user.
  • Two-factor authentication (TOTP / RFC 6238) is available for every account from /account → Two-factor. 10 single-use recovery codes are generated at enrollment. Disabling 2FA requires a fresh password proof.
  • Single sign-on (OpenID Connect) is available per tenant — admins paste their issuer + client id + client secret on /account → Single sign-on. Client secrets are encrypted at rest with the platform key.
  • Sessions are HttpOnly + SameSite=Lax + Secure cookies, 14-day TTL. Users can list and revoke active sessions from /account → Where you're signed in.
  • hCaptcha is enforced on /signup and /login — bounces non-browser clients before any credential or rate-limit logic runs.

Tenant isolation

TalentOS is multi-tenant from day one. Every storage row carries a tenantId; every API route filters by the caller's tenant before returning data. Cross-tenant requests are masked as 404 (existence-hidden) rather than 403, so attackers cannot probe identifier space to discover what exists in other tenants.

The isolation gate applies to: vacancies, candidates, offers, interviews, library items, uploads (when tagged with a tenantId), audit events, AI cost attribution, webhooks, API keys, SSO config, and tenant settings.

Application security

  • CSRF defence: every state-mutating endpoint checks the Origin header against an allow-list (apex, tenant subdomains, vercel.app preview hosts). Bearer-token callers (API integrations) bypass since they're not browser contexts.
  • Rate limiting: per-IP on signup, login, anonymous CV uploads, 2FA verify, and password reset; per- session on every AI route (30 / minute).
  • AI budget enforcement: tenants set a monthly USD cap on /account → Branding. AI routes return HTTP 402 (Payment Required) when the cap is reached.
  • Per-tenant Anthropic key (BYO): tenants can paste their own Anthropic key on /account. When set, AI calls use that key — costs land on their Anthropic bill and rate limits stay isolated from other tenants.

Audit + observability

  • Tamper-evident audit trail: every create, update, delete, login, AI call, and config change writes an append-only LIST event with actor, timestamp, entity, tenantId, and outcome. Admins export to CSV from /audit → Export, with 17 columns covering everything an SIEM ingestion needs.
  • Error tracking: Sentry captures uncaught errors across client + server with full stack traces. Source maps are uploaded on every deploy so traces map back to readable code.
  • Health endpoint: /api/health exposes live posture — AI provider, email provider, captcha, storage probe, tenant count, audit error rate. Polled by /status and safe to monitor with external uptime tools.

Privacy + data-subject rights

We comply with NDPR (Nigeria), GDPR (EU + UK), CCPA / CPRA (California), POPIA (South Africa), LGPD (Brazil), PIPEDA (Canada), AU Privacy Act, PDPA (Singapore), and Kenya DPA 2019. Admins self-serve data export and tenant delete from /account — no support ticket required, no waiting period beyond the typed-confirmation step.

Full details on data we process, where it lives, and how to exercise data-subject rights live on the Privacy Notice and the Data Processing Agreement.

Infrastructure + uptime

  • Vercel hosts the application across multiple regions (us-east, eu-west) with automatic failover. Deployments are atomic with instant rollback.
  • Upstash backs Vercel KV with multi-region replication and snapshot recovery.
  • Resend delivers transactional email from a DKIM-verified talentosglobal.co domain (SPF + DKIM + DMARC configured).
  • Anthropic serves the AI workload. Calls are non-streaming where deterministic JSON is required and streaming for the AI Recruiter chat surface. No customer data is used for Anthropic model training (Anthropic's commercial-API privacy policy applies).

Coordinated vulnerability disclosure

We welcome reports from independent security researchers and treat coordinated disclosure as a partnership. The policy below mirrors the machine-readable contact published at /.well-known/security.txt per IETF RFC 9116.

In scope

  • talentosglobal.co (apex + www)
  • *.talentosglobal.co — every tenant subdomain served by the platform (e.g. acme.talentosglobal.co)
  • /api/* — every authenticated and public API route under the apex and tenant subdomains
  • The public career portal at /careers/* and the anonymous CV upload endpoint
  • The platform's outbound webhook signing scheme and Bearer-token API surface

Out of scope

  • Third-party platforms we build on — Vercel, Upstash (Vercel KV), Anthropic, Resend, Sentry, Stripe, hCaptcha. Report directly to those vendors' security teams. We're happy to coordinate where appropriate.
  • Findings that require physical access to a user's device, social engineering of TalentOS staff, or compromise of a customer-owned account (those are tenant-side issues we can't fix on the platform).
  • Missing security headers without demonstrated impact, clickjacking on pages with no state-changing actions, CSV injection in tenant-controlled export fields, and email spoofing of domains we don't control.
  • Denial-of-service via volumetric traffic, automated scanner output without a reproduced finding, and self-XSS that requires the victim to paste attacker-controlled code.
  • Best-practice notes without a concrete vulnerability (e.g. “cookie not HttpOnly” on a cookie that's not security-sensitive by design).

Safe harbor for researchers

If you make a good-faith effort to comply with this policy while researching a vulnerability, we:

  • Will not pursue or support any legal action against you related to your research
  • Will not report you to law enforcement for activity that stays within the bounds of this policy
  • Will treat your research as authorised under the Computer Fraud and Abuse Act, the UK Computer Misuse Act, the EU NIS2 Directive, and analogous statutes — subject to the limits below
  • Will work with you to understand and resolve the issue quickly, and credit you publicly (with your permission) in our changelog once the fix ships

In return, please:

  • Make a good-faith effort to avoid privacy violations, degradation of user experience, or destruction of data
  • Stop testing and report immediately if you encounter customer data; do not exfiltrate, copy, or retain it
  • Don't run automated scanners at a rate that would impact service availability (start at ≤ 5 req/s and back off on errors)
  • Test only against your own tenant or accounts you own; don't target real customer tenants or candidate records
  • Don't publicly disclose the issue before we've had a reasonable opportunity to remediate (see the timeline below)

Disclosure timeline

Our default coordinated-disclosure window is 90 days from receipt. The clock starts when you send the report (not when we triage), and we'll keep you updated on progress at least every two weeks.

  • Within 48 hours — acknowledge receipt and assign a tracking reference
  • Within 7 days — initial triage result (validity, severity rating using CVSS 3.1, expected fix window)
  • Within 30 days — fix shipped to production for High and Critical severity findings
  • Within 90 days — fix shipped for all accepted findings, regardless of severity
  • After fix ships — public credit in our changelog (with your permission) and CVE assignment for qualifying findings

If we need more than 90 days (e.g. for an architectural change), we'll explain why and agree an extension with you in writing before the window closes. We will not invoke legal escalation as a stalling tactic.

Rewards

TalentOS does not currently run a paid bug-bounty programme. We expect to launch one alongside our SOC 2 Type II audit (target Q4 2026); until then, valid reports receive:

  • Public credit in our changelog and on this page's hall-of-fame section (with your permission)
  • A swag pack (T-shirt, stickers) — confirmed by email once the fix ships
  • Priority consideration if you later apply to TalentOS engineering or join our security advisory panel

How to report a vulnerability

The fastest channel is email. We monitor the inbox during business hours (UTC+1) and on rotation outside them.

Email
Encrypted email (PGP)
Fingerprint: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

The key currently published is a placeholder; a real keypair will be in place by 2026-09-01. Until then, send plaintext reports and we'll respond from the verified address before exchanging sensitive details.

Machine-readable contact

What to include

  • Affected URL, endpoint, or component
  • Step-by-step reproduction (curl snippets, browser steps, or a minimal proof-of-concept script)
  • Impact narrative — what an attacker could do, and the approximate user / data scope
  • Suggested CVSS 3.1 vector if you have one (we'll score independently regardless)
  • Your preferred name + handle for public credit (or “anonymous”)

If your report is time-sensitive (active exploitation in the wild, customer data at imminent risk), please put [URGENT] at the start of the subject line so the on-call engineer is paged.

Hall of fame

We publicly credit researchers whose reports led to a fix. The list will populate here after our first valid report — we'd be honoured for yours to be the first.

Incident response

If we become aware of a data incident affecting tenant data, we notify affected admins within 72 hours via the email on file with concrete details: what was accessed, by whom, for how long, and what's being done. We commit to the same 72-hour notification timeline that GDPR Article 33 requires of controllers.

Roadmap

Areas under active development:

  • SOC 2 Type II audit (target: Q4 2026).
  • Customer-managed encryption keys (CMEK) for tenants who require key sovereignty.
  • SAML 2.0 (in addition to OIDC) for enterprise IdPs.
  • Webhook auto-disable on consecutive failures (already shipped); next iteration adds per-tenant configurable thresholds.
  • Tenant-scoped audit retention controls (currently global).

Contact