Skip to content
Cortex

Legal · v1.0

Security posture

Effective 2026-05-14

Cortex is built for businesses that need their AI advisors to handle sensitive context. This page is the public-facing summary of how we protect that data. For full technical detail under NDA, contact security@cortex.pleisys.com.

Tenant isolation

Three independent enforcement layers ensure that one tenant cannot read or modify another tenant’s data, even in the presence of an application bug:

  • JWT-bound tenant claim — every access token carries the tenant identifier; controllers reject any request whose claim does not match the URL slug.
  • Per-request SET LOCAL app.tenant_id — a Postgres GUC set inside each transaction; rolled back automatically when the transaction ends.
  • FORCED Postgres Row-Level Security — every tenant table has a policy that filters on tenant_id = current_setting(‘app.tenant_id’); even the application role cannot bypass it.

Authentication and session management

  • Argon2id password hashing (memory: 19 MiB, iterations: 2, parallelism: 1 — the OWASP-recommended minimum).
  • TOTP-based multi-factor authentication is planned but not yet available — the data model and encryption path exist, enrollment and verification flows are on the roadmap.
  • RS256 JWT access tokens with a persistent JWK file (no per-pod ephemeral keys).
  • Rotating refresh tokens with family reuse detection — replayed tokens invalidate the entire family.
  • SameSite=Lax, httpOnly, Secure cookies for both access and refresh tokens — Lax withholds cookies from cross-site fetch/XHR regardless of method, which is our CSRF mitigation for the same-origin app.
  • Brute-force-resistant rate limits on login and password-reset endpoints, tighter than the general API rate limit.

Data at rest and in transit

  • TLS 1.3 in transit; HSTS preloaded.
  • AES-256-GCM application-level encryption for sensitive stored fields (e.g. tenant API keys); AWS S3 (ap-south-1) server-side encryption for stored objects (memo PDFs, invoice PDFs, file uploads).
  • Automated encrypted off-site database backups are not yet running — this is a known gap on our roadmap, not a claim we make today.
  • Secrets (DB connection strings, API keys, JWT private key) held in environment configuration on the host, never committed to source control.

Audit logs

  • Append-only partitioned table; database triggers reject UPDATE and DELETE.
  • Captures actor, action, resource, request ID, IP, User-Agent, and PII-redacted metadata.
  • Retained for a minimum of 7 years to meet Indian Companies Act and GST requirements — append-only, so no deletion mechanism exists yet past that mark either.

Incident response

  • Documented internal incident-response playbook with defined severities, response SLAs, and a communication tree.
  • Breach notification target: 72 hours for GDPR-scoped tenants. As an India-incorporated, India-hosted company we are separately bound by India CERT-In’s stricter 6-hour cyber-incident reporting requirement, which governs first when it applies.
  • Responsible-disclosure channel: security@cortex.pleisys.com (see security.txt).

Application security

  • Content Security Policy with nonce-based inline-script allowlisting.
  • Argon2id-hashed refresh tokens with pessimistic write locks to prevent rotation races.
  • Webhook idempotency on a composite unique key (gateway, gateway_event_id).
  • Zod-validated request bodies, query parameters, and route parameters.
  • Per-client rate limiting (300 req/min per client, per endpoint), with a tighter limit and a temporary block on authentication endpoints.

Infrastructure

  • Postgres 17 + Redis 7 on a hardened, self-managed Hostinger VPS (Mumbai, India).
  • Native Nginx reverse proxy terminating TLS; OS-level firewall and fail2ban on the host.
  • Sentry for PII-redacted error monitoring.

Responsible disclosure

Found a vulnerability? Please report it to security@cortex.pleisys.com. Include reproduction steps and your preferred contact. We commit to:

  • Acknowledging your report within 2 business days.
  • An initial triage and severity assessment within 7 days.
  • Updates at least every 14 days until resolution.
  • No legal action against good-faith researchers who follow this policy.

Our machine-readable security contact lives at /.well-known/security.txt.

Acknowledgments

We thank the researchers who have helped us improve Cortex’s security. Send us a report you’re proud of and ask to be listed here.

Roadmap (transparent)

  • SOC 2 Type I — targeted for Q3 of the launch year.
  • ISO 27001 — targeted for Q4 of the launch year.