Security & trust for TIVA Cortex

Cortex is Mindshine's data-governance platform: governed data pipelines, business workflows with human and AI participants, project agents, and governed applications. This page describes — plainly and verifiably — how customer data is protected, what our compliance status actually is, and which documents you can take into your own review.

SOC 2 Type II — readiness complete · examination scheduled

Continuous audit — weekly infrastructure scans

Encryption — in transit & at rest

No training on customer data

Platform security

What is actually running — every claim below is re-verified by Cortex's own continuous-audit system of record.

Tamper-evident audit trail

Security-relevant events land on an append-only, hash-chained audit log whose chain is verified on read. Every customer pipeline change is a versioned commit by construction — full who/what/when history.

Continuous scanning

Application checks every audit cycle; CIS Kubernetes benchmarks weekly; AWS account scans weekly under a dedicated read-only SecurityAudit role. Every failing check becomes a tracked issue with a recorded disposition — nothing is dropped silently.

Hardened runtime

Non-root containers, read-only root filesystems, RuntimeDefault seccomp, resource limits, digest-pinned data stores, and an admission policy constraining privilege-granting operations — verified live after every deploy.

One path to production

Images are built exclusively by CI behind a verify gate (tests, dependency audit blocking on critical advisories, secret scan). Infrastructure changes only through versioned declarative applies. No ad-hoc mutations.

Least-privilege access

Staff SSO federated to Google Workspace with MFA at the identity provider; a central authorization policy on every project operation; short-lived OAuth 2.1 tokens; no direct human access to production data stores — cluster access only via a single audited jumpbox.

Tenant isolation

Organization-scoped queries behind the central access policy, per-project data stores, and an isolated namespace per deployed customer application.

Fail-closed secrets

Services refuse to boot without their secrets; there are no fallback values. A CI gate blocks secret material from ever entering source control, with continuous secret-hygiene scanning behind it.

Resilience by construction

RPO 24h / RTO 8h targets per store; the estate is rebuildable from code plus versioned configuration — recovery is a re-apply, not an archaeology exercise.

Compliance

Stated honestly — statuses below distinguish what is operating from what is scheduled.

SOC 2 Type II

Readiness complete A management-prepared readiness assessment structured after an AICPA SOC 2 report — system description, 76 criteria-mapped controls with tests and results, and disclosed open matters — is complete and published below.

Examination scheduled Type I examination by a licensed CPA firm is the scheduled next step, followed by a Type II observation window. No auditor-issued report exists yet, and we won't imply otherwise.

Continuous evidence

Operating Evidence is generated by the platform, not assembled for audits: automated collectors (repository settings, CI pipelines, AWS scans, incident register), quarterly access reviews, and change records — on a tamper-evident log, available to customers under NDA.

Penetration testing

Automated — operating Continuous automated security testing, including adversarial re-tests of enforcement controls performed as the identities they constrain.

Independent test planned A third-party penetration test is planned ahead of the SOC 2 examination.

Subservice assurance

Carve-out AWS (SOC 1/2/3, ISO 27001), Anthropic (SOC 2 Type II), Atlassian (SOC 2, ISO 27001), Google (SOC 1/2/3) — see the subprocessor list below.

Nature of our claims. Everything on this page is management-prepared and evidence-linked; it is not a certification or an independent attestation. Open items are disclosed in the documents below with owners and plans, rather than omitted.

Data protection

How customer data is classified, isolated, and disposed of.

Purpose-bound use

Customer data is processed only for the service purposes the customer configured. It is never used to train foundation models. Where a project is flagged as containing regulated data, LLM row-sampling is disabled.

Encryption

TLS on all external surfaces. Server-side encryption on object storage; EBS encryption-by-default account-wide, with public snapshot access blocked. Volume disposal via encrypted-key destruction.

Data map & retention

Every data class is inventoried with location, purpose, encryption status, and retention. Deletion paths exist per asset class — record, source, project, account — with understood cascade semantics.

Data-subject requests

A DSAR runbook (access / correction / deletion) with a 30-day SLA; corrections propagate structurally through pipeline lineage.

Subprocessors

Verified against actual data flows, not self-declared usage. A vendor receiving customer data requires a DPA before integration.

Vendor	Service	Data that flows there	Assurance
Amazon Web Services	EKS, EC2, EBS, S3, ECR (us-east-1)	All platform data	SOC 1/2/3, ISO 27001 · AWS DPA (GDPR SCCs)
Anthropic	Claude API — assistants, mapping suggestions, enrichment	Recipe metadata, prompts, excludable sampled rows	SOC 2 Type II · DPA countersignature in progress (disclosed)
Atlassian (Bitbucket)	Source hosting + CI	Source code; scoped CI credentials — no customer data	SOC 2, ISO 27001 · DPA
Google	Workspace identity (staff SSO)	Staff identity claims only — no customer data	SOC 1/2/3, ISO 27001

Report a vulnerability · security contact

We publish a security policy with a reporting channel, acknowledgement expectations, and severity-based SLAs.

security@mindshine.com — vulnerability reports, security questionnaires, NDA evidence requests, and DPA inquiries. Reports are acknowledged and triaged per the published SLAs; incidents follow the Incident Response Plan (document 08).