Skip to content
Cortex
Request

Legal · v1.1

Security posture

Effective 2026-10-03

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.

AI and your data

  • The AI executive offices use Anthropic’s Claude models through Anthropic’s commercial API, which does not use API data to train models by default. Anthropic is listed on our sub-processors page.
  • Offices read your data under the same row-level security as the rest of the application: an office can only ever see its own company’s records.
  • Offices are read-only. No AI office can create, change or delete an entry in your books.
  • Offices read your books through fixed, server-written queries, never free-form database access. Offices are not given PAN numbers or contact details — only whether a PAN is on file. Bank statement lines reach the finance offices as the bank wrote them.
  • You can connect your own Anthropic API key instead of ours.

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

  • 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 on every endpoint, with a tighter limit and a temporary block on authentication endpoints.

Infrastructure

  • PostgreSQL 16 and Redis on a self-managed Hostinger VPS in 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.

Not yet in place (transparent)

  • We do not hold SOC 2 or ISO 27001 certification.
  • Two-factor sign-in for customer accounts and single sign-on are on the roadmap.
  • Automated encrypted off-site backups are not yet running (see above).