Skip to content
Built by Triarch Security

Security is the architecture, not a setting.

YourKith is built by a security firm, for advisory and security firms. Every customer runs on dedicated, isolated infrastructure, your own cloud project, your own database, your own domain. There is no shared multi-tenant database to misconfigure, because customers are physically separated at the infrastructure layer.

Isolation by architecture

Your data never shares a table with anyone.

Each customer gets a dedicated, single-tenant deployment: its own Google Cloud / Firebase project, its own Neon Postgres database, and its own domain. No shared database. No shared application instance. No commingled tables.

The data model has no tenant-ID columns and no row-level-security filters, because there is nothing to filter. There is no runtime "which-customer-is-this?" check that could be misconfigured to leak data across customers. A boot-time guard binds each instance to its own database, so an instance physically cannot connect to another customer's data.

  • Dedicated database per customer, physically separate data, not logically partitioned.
  • No shared tenant model, nothing to leak across customers because nothing is co-mingled.
  • Boot-time database binding, each instance is wired to its own database and cannot reach another's.
  • A security firm's product, isolation is the differentiator, a property you can sell to your own clients.
Customer A
own project · own DB · own domain
Customer B
own project · own DB · own domain
One versioned codebase
deployed isolated · no shared data plane

Isolation lives in the deploy pipeline, not the data model.

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. The plaintext columns those values used to live in have been dropped, not merely stopped being written.

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: when access is required to help you, it is granted only through short-lived, time-boxed credentials that are logged and audited, never a standing back door. Access records are available to you on request.

Access control & audit

Role-based access control governs what each user can see and do, with granular capabilities layered on roles. An audit log records access and actions so you can see who did what, and when, accountability built into the platform, not bolted on.

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. On BYOK, AI calls over your data require an attested no-training / zero-data-retention configuration, enforced in code, a call whose credential lacks that attestation fails closed rather than proceeding. Your data is not used to train third-party models and is not retained by them.

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.

Vulnerability disclosure

Found something? Tell us.

We welcome responsible disclosure from the security community. If you believe you've found a vulnerability in YourKith, please report it privately so we can investigate and remediate before any details are made public. Please do not access or modify data that isn't yours, and give us a reasonable window to respond before disclosure.

Compliance

Practices first, attestations on request.

This page describes the security practices engineered into YourKith: isolation, encryption, authentication, access control, and auditability. We do not claim any formal compliance certification on this page. Formal attestations and supporting documentation are available on request and are part of our roadmap. If your procurement process requires a specific framework or questionnaire, contact us and we'll work through it with you.

Practices documented Attestations on request Frameworks on the roadmap

See the architecture for yourself.

Book a walkthrough and we'll show you exactly how isolation, encryption, and access control work in a real, dedicated deployment.

Security reports: mike@triarchsecurity.com