How we protect your data
Defense in depth, end to end.
Isolation is the foundation. On top of it sits encryption, hardened authentication, least-privilege access, and careful handling of AI over your data.
Encryption
Sensitive PII fields, such as email addresses and phone numbers, are encrypted at rest with AES-256-GCM under a per-value data key that is itself wrapped by a Google Cloud KMS key, with a dedicated key per deployment. On the contact record the plaintext columns those values used to live in have been dropped outright, not merely stopped being written, and a database constraint now makes a plaintext identifier unstorable. Being straight about the limit: addresses still appear in plainer form elsewhere in the corpus, in calendar organiser and attendee fields and in the search index, because that is what makes the encrypted identifiers findable again. We measure that surface rather than claim it away.
One honest detail, because it is the kind of thing a security team should hear from us rather than discover: so that encrypted fields remain searchable without being decrypted, we also store a keyed one-way hash of each value alongside the ciphertext. It is not reversible and it is not the encryption key, but it is a distinct mechanism and it is not KMS-backed.
The underlying storage also benefits from the cloud provider's standard at-rest disk encryption. Data in transit is protected with TLS.
Authentication & sessions
Identity is verified through Firebase Auth, used strictly as an identity provider. Sessions are short-lived JSON Web Tokens signed server-side and stored in httpOnly, Secure cookies, never bearer tokens in browser localStorage. Only your own verified email domain can sign in to your instance. The one exception is Triarch support: named Triarch staff can be admitted to your instance, and that admission is written into your deployment with an explicit expiry date, is recorded in the audit log on every single login, and can be revoked by you at any time from your own settings. It is not a hidden account and not a shared password, but we should be precise rather than flattering: while the grant is in force it is standing access for those named people, not a credential issued per incident. Access records are available to you on request.
Access control & audit
Role-based access control governs what each user can see and do. A finer capability layer sits on top of it and today governs user and role administration, with the business modules gated at the role tier; extending capabilities across every module is in progress rather than done. An audit log records access and actions, and your administrators can read it in the product, so you can see who did what, and when.
AI over your data (BYOK)
YourKith supports, and recommends, a bring-your-own-key model: you supply your own LLM provider key, so the provider relationship, the billing, and the terms are yours. Reasoning calls over your data require an attested no-training / zero-data-retention configuration, enforced in code at a single chokepoint: a call whose credential lacks that attestation fails closed rather than proceeding, and that check refuses our own managed key too. One exception we would rather state than have you find: the embedding step that powers semantic search does not yet run through that chokepoint, and where you have not supplied an embedding key it falls back to a Triarch-held provider key. Closing that gap is active work. The attestation itself is a configuration we set and record, not something the provider proves back to us.
If you do not supply a key, the platform falls back to Triarch's managed provider keys so the AI features work without setup. On that path the calls are made under Triarch's provider account rather than your own. Your data still stays inside your own isolated instance, but if you need the provider relationship to be yours, use BYOK.
Infrastructure & data residency
Every deployment runs on Triarch-managed cloud infrastructure. The application runs on Google Cloud / Firebase App Hosting in us-central1; your database is a dedicated Neon Postgres instance hosted on AWS in us-east-2. Each customer's infrastructure is provisioned and managed separately. If your firm has a specific data-residency requirement, talk to us before you sign, region placement is something we agree with you rather than something you self-select in the product today.
Built by a security firm
YourKith is built and dogfooded by Triarch Security. Isolation, least privilege, and auditability are treated as first-class, sellable properties, not afterthoughts. We hold ourselves to the standard we ask our own clients to meet.