Security

• In transit: TLS 1.3 on every public endpoint. HTTP Strict Transport Security (HSTS) enforced with a 2-year max-age and includeSubDomains preload.
• At rest: AES-256 on the application database and on uploaded files, in US data centers.
• Secrets: Application secrets are never logged. They live in our hosting provider's encrypted environment store, segregated per environment.

• Row Level Security (RLS) is enabled on every table holding user data: profiles, conversations, messages, violations, moderation logs, billing transactions, user memories. Each policy scopes reads to auth.uid() = user_id.
• Customer isolation: Row Level Security denies cross-tenant reads at the database, so an application bug alone cannot expose data belonging to another account. Admin client usage is limited to billing and security paths and always filters by user_id explicitly: defense in depth on top of RLS.

• Managed authentication with password hashing via bcrypt.
• Google OAuth supported for customers who prefer SSO.
• Session cookies are HttpOnly, Secure, and SameSite=Lax.
• Post-auth redirects are validated as same-site paths: no open-redirect exposure.

• Primary model: Claude by Anthropic, an American AI company, reached through Anthropic's API. Anthropic does not train on our conversations and retains API inputs and outputs only briefly for abuse monitoring under its commercial terms; its own security and privacy documentation covers how it runs that API.
• Backup model, American and US-only: if Claude is ever unavailable, our backup, a frontier open-weight model, is served by an American company on infrastructure we selected and configured, through a serving path that runs exclusively in the United States. Backup requests are never routed outside the country, and the backup answers only during an outage, disclosed on screen.
• Zero data retention on the backup: prompts and answers exist only in volatile memory for the length of the request and are never written to persistent storage by the backup's hosting provider. When prompt caching is active, cached prompt data lives in memory for a few minutes, then is gone.
• Encryption: TLS 1.2 or higher in transit and AES-256 at rest on the backup hosting provider's side, matching our own.
• Audited: the backup hosting provider holds ISO 27001 (information security), ISO 27701 (privacy) and ISO 42001 (AI management), is SOC 2 Type II certified, and supports HIPAA workloads. Certifications are maintained through continuous monitoring and annual audits.
• Operational controls: on the backup host, workload isolation between customers, all data access logged and tamper-protected, least-privilege access for a minimal set of provider personnel, DDoS protection, continuous vulnerability scanning, regular penetration testing, and a formal incident response plan with customer notification.

• Every chat message passes through a layered pipeline: rate-limit check, input sanitization, local content moderation (jailbreak and spam detection), progressive violation penalties.
• Outages are handled honestly, not uniformly: endpoints that cost us money or run without a signed-in account fail closed, so a dependency outage stops them rather than letting checks be skipped. The pacing windows on chat fail open, so an infrastructure problem on our side never walls a paying member out of a conversation they have already paid for. Moderation and authentication always run, in every case.
• If Claude is ever unavailable, JCIL switches to its backup, a frontier open-weight model hosted and processed in the United States, and tells you on screen: a notice above your conversation and a label on every answer it wrote. The switch happens by an operator's decision, or automatically after repeated failures of Claude, and it is always disclosed. What the backup receives is listed on the subprocessors page.
• Progressive violation penalties: 10 min → 1 hour → 24 hour → 7 day → permanent. Zero tolerance for CSAM, terrorism, credible threats against persons, or content sexualizing minors.
• Rate limits enforced per user, per endpoint, and per client IP through a managed rate-limit store, with a bounded in-memory fallback for the limiters that keep enforcing when that store is unavailable.

• All payments flow through Stripe. JCIL.AI never receives card numbers; we're out of PCI-DSS scope.
• Stripe webhooks are verified with Stripe's signed payload and de-duplicated by session.id so retries cannot double-credit.
• Atomic charge + monthly-cap checks live in a single Postgres function to prevent race conditions under concurrent chat requests.

If you believe you've found a security issue in JCIL.AI, please report it through the compliance contact form with topic: security. We respond within 48 hours, acknowledge good-faith reporters, and do not pursue legal action against researchers following coordinated disclosure.

Machine-readable disclosure info lives at /.well-known/security.txt per RFC 9116.

• 2026-04-17: Launch readiness audit closed these gaps: row level security added to moderation_logs; explicit policies added to violations; Stripe webhook deduplication via stripe_session_id unique index; atomic spending-cap enforcement; security pipeline failing closed on infra outage; DOMPurify sanitization of preview HTML.