The truth about how Tessarac protects your data.
Compliance status, sub-processors, security architecture, incident response, vulnerability disclosure — published in one place, updated when status changes (not when an audit closes). If you're a Tessarac customer or considering becoming one, this page is the answer to your security-team's questionnaire.
Security architecture
Tenant isolation, encrypted credentials, fail-closed data protection.
This describes ACOG, the service we run today. The Security Platform is in beta and is not part of the production service described here.
- Every organization's data is scoped to that organization in every store; one customer can never read, list or infer another's
- Per-organization vector databases and credentials, named and derived under per-environment keys held in AWS KMS
- Your model-provider API keys are stored under envelope encryption and used only to forward your own requests
- TLS at the edge and mutual TLS between services inside the cluster
- Data loss prevention on prompts before they leave for a provider, opt-in per data type, failing closed by default if the scanner is unavailable
- Edge WAF and DDoS mitigation; continuous backups with point-in-time restore
Compliance status
Honest snapshot of where each framework stands today. Updated when status changes.
| Framework | Status | Notes |
|---|---|---|
| SOC 2 Type 2 | Targeted | Our first attestation, and the next one we will pursue. No auditor is engaged yet and no observation period has started, so there is no report to share. |
| ISO 27001:2022 | Roadmap | Not started. We will consider it after SOC 2 Type 2. |
| HIPAA | Roadmap | We do not sign Business Associate Agreements today, so do not send protected health information through Tessarac. |
| PCI DSS | Ready | For our own billing only: card details are entered in our payment processor's fields and never reach Tessarac systems (SAQ A scope). Tessarac is not a PCI-validated service provider for your cardholder data. |
| GDPR | Ready | Data Processing Agreement available. Customer data is stored in the United States (AWS us-east-1); EU data residency is not offered. |
| FedRAMP | Roadmap | Not started. No sponsoring agency or assessor is engaged. |
| DoD IL5 | Roadmap | Not started. It would follow a FedRAMP authorization. |
| CMMC 2.0 L2 | Roadmap | Not started. |
"Ready" — in place today, as the note describes. "Targeted" — the next attestation we will pursue; not started. "Roadmap" — planned, not started. None of these is a third-party attestation.
Sub-processor categories
The categories of sub-processors we use to operate ACOG, with data residency. The named-vendor list (with the specific provider in each category) is shared on request. We notify customers under contract 30 days before any change.
| Category | Purpose | Data residency |
|---|---|---|
| Cloud infrastructure | Compute, datastores, backups, key management, and the edge (CDN, WAF, DDoS mitigation) | US (us-east-1) |
| Authentication | Sign-in, social login and single sign-on for the ACOG console | US |
| Payment processing | Card and bank payments for invoices | US |
| Transactional email | Invitations, verification and billing notices | US |
| Source control, CI/CD and container registry | Engineering toolchain | US |
ACOG sends your prompts only to the model providers you configure, using your own provider keys. Self-hosted deployments transit none of these sub-processors.
Incident response
We treat every customer incident as our incident. The short version of how we handle one is below.
- Detection
- Automated monitoring and alerting across the gateway, the control plane and every datastore, delivered to our engineers, with live service health on the status page.
- Containment
- Sessions, API keys and provider credentials can be revoked per organization, and every service runs under its own least-privilege identity.
- Customer notification
- Confirmed customer-impacting incident → notification within 24 hours per the customer agreement.
- Post-mortem
- Public post-mortem within 7 business days for every customer-visible incident; root-cause analysis with action items.
Vulnerability disclosure
We rely on the security community. If you've found something, get in touch — we'll respond fast and we don't pursue good-faith researchers.
- Where to report
-
security@tessarac.com
Also published at/.well-known/security.txt - First response
- Within 1 business day.
- Triage SLA
- CVSS 9.0+ within 24 hours. CVSS 7.0+ within 3 days.
- Patch SLA
- Critical: 2 business days. High: 10 business days.
- Safe harbor
- Good-faith research that respects user privacy and doesn't disrupt service is welcomed and protected from legal action under our coordinated-disclosure policy.
Need a security questionnaire turned around?
Email us for the architecture diagrams and the sub-processor list.