How is my organization's data isolated from other tenants?

This is the question most buyers ask first, and it's the question we hold ourselves to most strictly. The short answer: every piece of customer data in MetaFrazo carries an organization identifier, and the database itself refuses to return data to a caller who isn't a member of the right organization — regardless of what the application code does.

We treat cross-tenant data isolation as the single highest-priority security control in MetaFrazo. Every change that touches authentication, access policies, or cross-tenant data paths is reviewed against this commitment before it ships.

The core commitment

When a member of organization A asks MetaFrazo to render a dashboard, the data they see is restricted to organization A's Jira events, organization A's audit trail, organization A's settings. They cannot see organization B's data — not by changing a URL, not by tampering with a request, not by exploiting a frontend bug. Their request never reaches the database with the right credentials to read organization B's rows.

This is enforced at three layers, in order:

1. Authentication. Every dashboard request carries an authenticated session token. The token names the human (you) and the organization you're currently viewing. The token is short-lived; we re-verify it on every request.
2. Authorization. The backend re-checks that you are an active member of the organization you say you're viewing. We don't trust the browser to make this claim.
3. Database-level scoping. Beneath the application, the database itself enforces that every query for tenant data carries an organization identifier and returns only rows belonging to that organization. If the application layer ever had a bug that tried to read organization B's data on behalf of an organization A member, the database would refuse.

That third layer is the one that keeps us honest. Application code can have bugs; isolation policies in the database don't get fooled by application bugs.

What this means in practice

• Your Jira events live in tables that the database treats as per-tenant. A SQL injection attack against MetaFrazo (if one were ever to occur) would still not return your competitor's data; the database would not surface it.
• Membership changes are real-time. If you revoke an ex-colleague's access, the next query they make is rejected. There is no "next-page cache" that lets them keep reading after removal.
• You cannot see what we can't see. Our own internal admin tooling is scoped to the same isolation policies; even MetaFrazo staff need an explicit reason and a paper trail to look at customer data. (And when we do, we always tell you.)

What this does not commit to

We are precise about the boundary of this commitment so you can rely on it:

• Encryption at rest is separate. All customer data is encrypted at rest using the standard managed-cloud encryption your data-processor agreement covers. That's a different control from tenant isolation; both apply.
• Backups are isolated the same way. Our backups carry the same organization scoping. A restore for one customer cannot leak another customer's data.
• AI provider choice changes the data-egress story. If you select OpenAI or Anthropic as your AI provider (see Choosing an AI provider), the Deep Analysis features then send relevant data to that vendor with your API key. That's a different flow with its own commitments, and you opt into it explicitly.
• Your Jira API key, if you have one, never reaches us. MetaFrazo authenticates with your Jira workspace via Atlassian's signed app-invocation tokens, not via a Jira API token. There is no Jira credential of yours stored in MetaFrazo.

How we know this works

Three things back the commitment up:

• The database isolation policies are the same code on every environment. There is no separate "production isolation policy" that diverges from what we test. The same rules guard the same data everywhere.
• The isolation policies are tested on every code change. Automated test suites probe cross-tenant access from multiple roles in multiple organizations — including all the obvious "can a member of organization A see organization B's data" scenarios — and a regression in those tests blocks the change from shipping.
• Architecture changes that touch isolation are reviewed explicitly. Any pull request that modifies authentication, access policies, view definitions, or cross-tenant data paths is flagged for separate review rather than bundled silently into a larger change.

What you can do to strengthen this further on your side

The most common cross-tenant leak in any SaaS isn't a database bug — it's a credential leak. To keep your MetaFrazo organization safe:

• Use single sign-on with your identity provider rather than email-and-password.
• Promote teammates to Admin only when they need to invite or remove others.
• Use Auditor rather than Admin for read-only investigators.
• Remove access promptly when someone leaves your team — the Roles and permissions page explains how.

Where to go from here

• Roles and permissions — who can do what inside your organization.
• GDPR, NIS2, DORA — what does MetaFrazo give me? — what artefacts your auditors get.
• Choosing an AI provider — the data-egress story for the AI features.