Public Security Details

Last updated: 2026-06-01

This page is the public-facing companion to the Security Policy and the Threat Model. It expands on the controls Nomatica AI applies across the platform without revealing operationally sensitive details (specific rate limits, WAF rules, internal escalation paths, employee names).

What we publish here

1. Data classification — what categories of data we store, and how we handle each
2. Encryption — at rest, in transit, and for backups
3. Access control — authentication, authorization, MFA
4. Logging and monitoring — what we record, who can read it
5. Sub-processors — a list of vendors that may process customer data
6. Compliance — current and in-progress certifications
7. Incident response — what happens when something goes wrong

What we deliberately do not publish

• Specific rate-limit values, WAF rules, or bot-detection thresholds
• Specific internal escalation paths or on-call rotations
• Specific employee names, roles, or contact information
• Detailed audit findings, even after remediation
• The full list of CVEs we've patched in the last 90 days
• Penetration test reports (executive summaries are available to enterprise customers under NDA)

1. Data classification

Class	Examples	Handling
Account	Email, hashed password, MFA factors	Encrypted at rest. Access logged.
Tenant content	User prompts, generated outputs, uploaded files	Encrypted at rest. Access scoped to tenant.
Billing	Last 4 of card, billing address, invoice history	Tokenized via payment processor. Card data never touches Nomatica servers.
Audit	API calls, auth events, admin actions	Append-only log, HMAC-chained for tamper evidence.
Telemetry	Anonymized usage counters	Aggregated; no per-user identifiers retained.

2. Encryption

Layer	Algorithm	Notes
In transit (browser ↔ edge)	TLS 1.3 only	HSTS preload, 2-year max-age
In transit (edge ↔ origin)	TLS 1.3	mTLS where supported
In transit (origin ↔ DB)	TLS 1.3	Cloud-provider private networking
At rest (primary DB)	AES-256-GCM	Cloud-provider managed keys
At rest (object storage)	AES-256	Customer-managed keys for Enterprise tier
At rest (backups)	AES-256	Separate key, rotated quarterly
Application-level (secrets at rest)	Fernet (AES-128-CBC + HMAC-SHA256)	See nomatica-security-sdk

3. Access control

• Authentication. Email + password (with mandatory MFA), OAuth 2.0 (Google, GitHub, Apple), passkeys (WebAuthn). Session tokens are JWTs with a 15-minute access lifetime and a 7-day refresh lifetime; refresh tokens are rotated on every use and revoked on logout.
• Authorization. A centralized policy engine evaluates every request: (subject, action, resource, context) → allow/deny. Application code never rolls its own checks.
• Multi-factor authentication. Required for all new accounts. TOTP and WebAuthn supported. SMS is supported as a fallback but not recommended.
• Session management. Access tokens are held in memory on the client. Refresh tokens are held in an HttpOnly, Secure, SameSite=Lax cookie scoped to the apex domain, so a single login persists across all subdomains.

4. Logging and monitoring

• Application logs are structured JSON, shipped to a managed log sink, retained for 30 days hot / 1 year cold.
• Audit logs of all security-relevant events (login, MFA changes, key rotation, payment changes) are written to a tamper-evident HMAC-chained log and retained for 7 years.
• Real-time monitoring fires alerts on:
  • Auth events from a new country or device
  • A spike of 4xx or 5xx responses from a single tenant
  • Any cross-tenant read attempt (always a finding)
  • Any modification of an audit log entry (should be impossible; if it happens, the alert is the highest priority)
• Uptime monitoring is performed externally every 30 seconds from at least three continents; status is published at status.colorfulmoves.com.

5. Sub-processors

Sub-processor	Purpose	Data shared	Region
Cloudflare, Inc.	Edge network, DDoS protection, KV cache	All HTTP traffic, no application payloads inspected at the edge	Global anycast
AWS	Primary compute, managed Postgres, Redis	All application data	us-east-1, eu-west-1 (customer choice)
OpenAI, Anthropic, Google	Model inference (per-customer opt-in)	Prompts and tool results, encrypted in transit	Provider region
Stripe, Square	Payment processing	Tokenized card data; no raw PAN ever reaches Nomatica	US, EU
Resend	Transactional email	Email address, message body	US
Sentry	Error monitoring	Stack traces; PII fields are scrubbed at the source	US

The full, current list is available in the in-product Sub-processors page; you can subscribe to be notified of changes.

6. Compliance

Standard	Status	Notes
SOC 2 Type II	Annual report	Most recent: 2026-Q1; next: 2027-Q1
GDPR	Compliant	DPA available on request
CCPA	Compliant
HIPAA	BAA available on Enterprise tier	Not enabled by default
ISO 27001	In progress	Target: 2026-Q4
PCI-DSS	SAQ-A	Card data never touches Nomatica servers

Executive summaries of the SOC 2 report are available to prospective enterprise customers under NDA.

7. Incident response

When we detect (or are notified of) a security incident:

1. Triage within 1 hour. Severity assigned (P0–P3).
2. Containment within 4 hours for P0, within 1 business day for P1.
3. Eradication and recovery — full root cause and remediation documented.
4. Customer notification — within 72 hours for incidents that materially affect customer data, per GDPR Art. 33.
5. Postmortem — published internally within 14 days; executive summary shared with affected customers on request.

We commit to notifying affected customers before public disclosure, unless law enforcement instructs otherwise.

How to report an issue

See Security Policy → Reporting a vulnerability.