Security practices.

Last updated: 2026-05-27

1. Threat model

We protect against:

• Unauthorized access to customer data at rest or in transit
• Cross-tenant data leakage (one customer's data ending up in another's response)
• Inference traffic interception over the federated network
• Account takeover via credential compromise

We do not protect against:

• State-level adversaries with subpoena power in Taiwan (no service can)
• Physical seizure of our hardware (no service can without HSM-based key escrow)
• Insider threat from our own staff (mitigated by being a small team where actions are auditable, but not by formal SoD controls yet)

2. Data at rest

Data class	Where stored	Encryption
Account credentials	Supabase managed Postgres (EU region)	AES-256 at rest, hashed passwords (bcrypt cost 12)
Stripe customer data	Stripe (we never store cards)	PCI-DSS L1 (Stripe's certification)
Customer RAG corpus	Per-tenant LUKS-encrypted volume on our hardware (Taipei)	AES-256-XTS
Customer GGUF (Pro+ tier)	Same per-tenant volume	AES-256-XTS
Inference logs	Aggregate metrics only, no prompt / completion content	—

3. Data in transit

• Public endpoints: TLS 1.3, HSTS, certificate via Let's Encrypt, ratcheted monthly
• Inter-node inference traffic: Tailscale-encrypted WireGuard tunnel between orchestrator and workers. No raw cleartext on the public network.
• Federation pool nodes: receive only intermediate layer activations (already encrypted by Tailscale), never raw prompts

4. Tenant isolation

This is the central guarantee.

Tier	Compute isolation	RAG isolation
Free	Federated pool, may share workers with other free users	None — no RAG on free
Basic	Federated pool, prompt-isolated (each request independent)	Shared encrypted volume, per-user encryption key
Pro	Dedicated tenant node we own. No co-tenancy.	Dedicated encrypted volume per tenant
Org	Dedicated tenant node + dedicated API key + audit log	Dedicated volume + access log retained 90 days
Enterprise	On-prem on your hardware, or dedicated bare-metal owned by you	Your control · we have no access

5. Access control

• 2FA required for all team accounts (1-person team currently — Ho Yiing Chen)
• Hardware key (YubiKey 5C) for production server root access
• SSH access via Tailscale only, no public-internet SSH
• Database access via PostgreSQL Row-Level Security policies for multi-tenant separation

6. What we don't have yet (transparent timeline)

Control	Status	Target
SOC 2 Type I report	Not started	Q4 2026 (required for Medical / Government tiers)
SOC 2 Type II report	Not started	Q2 2027
ISO 27001 certification	Not started	2027
GDPR Data Processing Agreement (DPA) template	Available on request	Self-serve at Pro tier signup by Q3 2026
HIPAA BAA	Not yet — required for US Medical customers	Q1 2027 if US-Medical demand materializes
Penetration test	Not yet performed	Q4 2026 (third-party, before Enterprise launch)
Bug bounty program	Email-based responsible disclosure	HackerOne or similar by 2027

7. Backups & disaster recovery

• Customer RAG / GGUF: snapshotted nightly to a separate encrypted volume on a different machine in the same datacenter. Off-premise backups only with your explicit written consent.
• Database (account / billing): managed by Supabase, point-in-time recovery to 7 days
• Stated RPO: 24 hours. Stated RTO: 4 hours (one-person team, best effort).

8. Security incident response

If we discover a breach:

• Within 1 hour: isolate affected systems
• Within 24 hours: notify affected customers via email with what we know so far
• Within 72 hours: file required notifications per GDPR Article 33 (EU) or 個資法 §12 (Taiwan)
• Within 14 days: publish a post-mortem at charenix.com/studio/security/incidents/

9. Responsible disclosure

If you find a security vulnerability, email norika@charenix.com with:

• Description of the vulnerability
• Steps to reproduce
• Suggested fix (if you have one)

We commit to:

• Acknowledging within 48 hours
• Providing a remediation timeline within 7 days
• Crediting you in the post-mortem (or keeping you anonymous if you prefer)
• Not pursuing legal action against good-faith researchers

10. Supply chain

We use only well-known open-source dependencies (llama.cpp, mergekit, HuggingFace transformers, FastAPI). All are pinned to specific versions in our deployment. We monitor for CVEs and patch within 7 days of public disclosure for high/critical severity.

11. AI-specific risks

• Prompt injection: mitigated via our MASL safety layer (AFU Brain, open source, 23⭐ on GitHub) for Alfred / Metis. Frankenstein domain experts have basic guardrails; advanced injection defense is roadmap.
• Training data leakage: we do not train on customer data by default. If you opt in to "let us train on this", we anonymize before incorporating into shared training sets.
• Model exfiltration: Pro+ customers can download GGUF weights, so this is by design. We don't promise the weights aren't extractable.

12. Contact

General security: norika@charenix.com
Privacy and data requests: norika@charenix.com (subject "Data Request")
Incident reports: phone available on request for paying customers