A narrow attack surface, on purpose.

Cortext is a memory layer for your AI identity. Security isn't a feature here; it's the whole product. The attack surface is intentionally narrow, the dependency tree is intentionally shallow, and every path that touches user data is reviewed by a human before it ships.

This page describes the technical and operational measures we take. If you find a gap, please tell us.

In transit

• All connections to cortext.ai, app.cortext.ai, and api.cortext.ai require TLS 1.2 or higher; TLS 1.3 is preferred and used for the majority of traffic.
• HSTS is enabled with a one-year max-age and includeSubDomains; preload.
• We publish CAA records restricting certificate issuance to our two approved CAs.

At rest

• Memory content, account data, and backups are encrypted with AES-256-GCM.
• Each tenant gets its own data encryption key, wrapped by a key encryption key held in a dedicated KMS. KEKs rotate automatically every 365 days; DEKs are rotated on a configurable schedule.
• Database-level encryption is layered beneath this; compromise of storage alone is insufficient to read any customer data.

• Every Cortext service, including internal tooling, requires SSO with hardware-backed MFA. Password-only access is not enabled anywhere.
• Production access is role-gated with a principle of least privilege. Read access to customer data is limited to three named roles, and each session generates a signed audit record retained for 13 months.
• Break-glass access (raw database read) requires approval from a second engineer, is capped at 60 minutes, and automatically expires. Every break-glass event pages the on-call channel.
• All employee workstations are managed with disk encryption, automatic patching, and malware protection. Personal devices are prohibited for production access.

• Compute and storage live in two regions: us-east and eu-west. Traffic is pinned to a user's home region unless they explicitly opt in to cross-region replication.
• No database or queue is exposed to the public internet. Application tiers reach data tiers over private networking only.
• Deploys are reproducible from a signed, immutable container image. The image supply chain is attested via SLSA L3.
• Secrets are injected at runtime from the KMS; no secret ever lands on disk or in a container layer.

• No model training. Cortext does not use Your Content to train machine-learning models — general-purpose or otherwise. We don't even use it for autocomplete on our own internal tooling.
• Deletion is real. When you delete a memory, segment, or account, the delete propagates across hot storage within 10 seconds. Encrypted backups that contain the data age out within 30 days; once they do, the cleartext is unrecoverable.
• No shadow copies. We do not maintain analytics warehouses of Your Content. Aggregated operational metrics use counts and timings only.
• Provider routing is explicit. The only time Your Content leaves Cortext is when you invoke /v1/context/inject. The destination provider is the one you named in the request.

• Every pull request is scanned by static analysis (CodeQL), dependency audit (OSV), and container vulnerability scan before merge.
• Dependencies are patched on a weekly cadence. Critical CVEs are patched and deployed within 72 hours of a fix being published upstream.
• Independent penetration testing is performed annually by a third-party firm; the most recent report is available under NDA on request.

• Application and infrastructure logs are centralized, encrypted, and retained for 90 days of hot access and 13 months of cold archive.
• Privileged actions — authentication, role changes, break-glass access, data exports — are logged to an append-only audit trail with cryptographic integrity.
• Anomaly detection runs continuously on authentication events, API behavior, and egress patterns. Alerts page the on-call engineer directly.

• Cortext follows a documented incident response plan with pre-defined severity tiers, owners, and communication templates.
• In the event of a confirmed breach that affects customer data, we will notify affected users within 72 hours via the email on file and post a public summary on the Status page.
• Post-incident reviews are written for every sev-2+ incident and published internally within two weeks. Customer-facing postmortems are published for any incident that affected their data.

Cortext uses the following subprocessors. We maintain DPAs with each and review their security posture annually.

We notify customers at least 30 days before adding or changing a subprocessor that handles Your Content. Subscribe to updates via the Status page.

• SOC 2 Type II — audit in progress with a target report date of Q4 2026. The Type I report is available under NDA.
• GDPR / UK GDPR — Cortext operates as a processor for most customer deployments. SCCs and UK IDTA are incorporated into our DPA.
• CCPA / CPRA — We honor consumer rights requests within the statutory timelines. We do not sell or share personal information for cross-context behavioral advertising.
• HIPAA — Not supported at this time. Do not submit Protected Health Information to Cortext.

If you find a security issue in Cortext, please report it to security@cortext.ai. We encrypt sensitive reports with PGP; our key fingerprint is 4F2E 7A91 3C8D 55B4 1E76 D9A2 0C33 F187 6A9B 84E2.

What we promise:

• We acknowledge reports within 24 hours.
• We commit to an initial severity assessment within 72 hours.
• We will not pursue legal action against researchers who act in good faith — no accessing other customers' data, no degrading service, no extortion.
• We credit reporters in the postmortem unless they ask us not to.
• We're working toward a paid bug bounty program; until then, high-impact reports receive Cortext swag and a permanent credit in our hall of fame.

Out of scope: findings on third-party services, volumetric DoS, social engineering of our support, and self-XSS.