Per-tenant encryption and data isolation: how we keep customer data separate

When a tool asks for your Jira token, your GitHub token, and read access to your Slack, the reasonable next question is: where does that go, and who else can reach it. This post answers that for MyrmexIQ, in more detail than a security page usually does, because the details are the point.

The shape of the problem

We're multi-tenant. Many customers, one running system. That's normal for SaaS, and it's also the thing that has to be gotten right, because the failure mode — one customer's data becoming visible to another — is not a bug you recover from with an apology.

There are two things to isolate: the data we sync (your tickets, messages, code), and the credentials we use to sync it (your API tokens). They have different risk profiles, so we handle them differently.

Isolating the data

Every piece of synced content is stamped with a tenant ID at write time. Every query is scoped to a single tenant ID before it runs — not filtered afterwards, scoped before. The search index, the vector store, the file storage, the database rows: all partitioned by tenant.

Within a tenant, you can further divide data into projects, each with its own configuration for which sources it includes. A project can be restricted to specific Jira project keys, specific Slack channels, specific repos. This is what lets one customer run, say, a "customer-facing" project and an "internal" project against the same connected tools without the two seeing each other's scope.

The default project sees everything the tenant has connected. Non-default projects see only what their filters allow. That distinction is enforced at the query layer, so a project that excludes a repo genuinely cannot return results from it, regardless of how the question is phrased.

Isolating the credentials

This is the part we spend the most care on.

Your integration tokens are encrypted before they're stored. Not with one master key for the whole system — with a key derived per tenant. So the stored form of Customer A's GitHub token and Customer B's GitHub token are encrypted under different keys. Compromising the storage of one tells you nothing about the other, and there is no single key whose exposure unlocks everyone.

The consequence we live with: the master encryption key is genuinely load-bearing. When we migrated our own infrastructure recently, verifying that every tenant's credentials still decrypted under the migrated key was the go/no-go check for the whole move. If it had failed, every customer would have had to re-enter every integration. It didn't fail, because the key was carried across exactly, but the fact that this is the scariest step is a feature — it means the encryption is actually doing something.

Tokens are decrypted only in memory, only for the duration of a sync or an API call, and never written back out in plaintext. They don't appear in logs. The AI models we call never see them — they see the data the tokens fetched, not the tokens.

What we don't do

We don't train on your data. Your tickets and messages are indexed for your retrieval and nobody else's. They aren't pooled, aren't used to improve a shared model, aren't visible to other tenants in any form.

We don't keep more than we need. If you disconnect an integration, its synced data and its stored credential are removed. If you delete a project, its scoped data goes with it.

We don't have a "god mode" that reads across tenants. Our own support access is scoped the same way customer access is. Looking at a specific tenant's data to debug an issue is a deliberate, logged action, not an ambient capability.

The honest caveats

We're a young company. We don't have SOC 2 yet — it's on the roadmap, and if you need it before you can adopt a tool, we understand and would rather tell you now. Enterprise plans can run with SSO/SAML and, where required, an on-premise deployment where the whole system runs inside your own infrastructure and none of the data leaves it.

If you're evaluating us and want to go deeper than this post — the exact key derivation, the audit logging, the data flow diagram — email contact@myrixlabs.com and we'll walk through it properly. Security questions from prospects are welcome, not a nuisance.

Read more about the platform or start with a project scoped to a single repo if you want to keep the initial blast radius small.