Data Isolation

Mirox is operated as a shared platform for many customers. Your organization is your tenant: everything that belongs to it — plants, portfolios, measurements, files, events, tickets, reports, alert rules, members and API tokens — is separated from every other organization. This page describes how that separation works and what the only sanctioned way across it looks like.

Three mechanisms carry the separation, each for a different kind of data:

Measurements: a tenant of your own

Every organization receives its own tenant in the time-series database when it is created. The agents of your plants deliver their measurements into that tenant and nowhere else: an agent authenticates as the device registered for its plant, and that registration fixes which plant — and therefore which tenant — its data is written to.

On the way back out, every read starts from the plant you ask for. The platform resolves the plant's organization, and with it the tenant, before the query is built; the query then runs inside that one tenant. There is no request shape that reads "all tenants" or "all plants" — a graph, a KPI, a report or an export always names its plants, and each of them is checked against your permissions first.

This also holds for raw access to the measurements. The Data Export, the Metric Export API and the Grafana dashboards do not talk to the database directly. They go through a proxy that authenticates the request, resolves the plants the caller may see, rewrites the query so that it can only match those plants, and only then forwards it. A query that names a plant you may not see returns nothing for that plant — the proxy does not rely on you asking politely.

Configuration and operational data: a check on every access

Plants, portfolios, members, events, tickets, reports, alert rules and all other configuration are kept in one relational database, and the boundary between organizations is enforced by the permission system on every single request:

• The request is authenticated first; a request without a valid session or API token is rejected before any data is touched.
• The permission system then decides per resource. A plant is checked against your roles; everything that belongs to a plant — its components, events, tickets, files, comments, contracts — is checked against that plant, never against the sub-item alone.
• Lists are filtered, not hidden: a list of plants, events or reports is built only from the resources you may see. There is no "show everything" path that is later narrowed down in the browser.
• The check runs inside the same database transaction that reads or changes the data. A result can never be assembled from rows the check did not cover.

What you cannot see also does not exist for you in any other form: it is not in search results, not in notifications, not in the AI assistant's answers and not in exports. The assistant and the agentic wizards work with exactly the permissions of the person using them.

Files

Documents, images and generated exports are stored in object storage under the plant or organization they belong to. They are never served directly from storage: a download is requested through the platform, which performs the same permission check as for the plant itself and then hands out a signed link that expires. A link cannot be guessed or reused for another plant.

Dashboards

Each organization gets its own organization inside Grafana with its own data source. Dashboards, folders and saved queries of one customer are not visible in another's Grafana organization, and every query a dashboard sends still passes the proxy described above — the Grafana organization is a convenience boundary on top of the real one, not a replacement for it.

Agents

Every plant has its own Mirox agent. The agents run decentralised on agent clusters in regions separate from the platform itself. Agents never share a service, a memory region or a tunnel, and an agent can only deliver data for the plant it is registered to. The deployment options describe how the agents are isolated from each other on the agent clusters.

Crossing the boundary on purpose

There is exactly one way for someone outside your organization to see your data, and it is deliberate, visible and revocable:

• A cooperation grants another organization access to named plants or portfolios. It is created by an Admin or Moderator of your organization, lists what is shared, and ends the moment it is revoked. Nothing is copied — the partner reads the same data under the same checks, and their access is bounded by the cooperation restrictions.
• An External member is invited into your organization with a limited role and sees only what that role allows.
• An API token can only restrict the permissions of the user who created it, never extend them.

Everything else — another customer, a search, a guessed identifier, a crafted query — ends at the boundary. The access audit log records who accessed which plant, so you can verify this for your organization at any time.

Frequently asked questions

Can another Mirox customer ever see my plants? No. Their requests are executed with their permissions and inside their tenant; your plants are not part of either.

Does a cooperation copy my data to the partner? No. A cooperation is a permission, not a copy. The partner reads the shared plants live, and nothing remains on their side after the cooperation is revoked.

Is the separation the same for the API and for the web app? Yes. The web app, the mobile app, the API and the AI assistant all go through the same backend and the same checks. There is no second path with weaker rules.

How can I verify who accessed my data? Open the access audit log of your organization. It lists every access to your plants, including those through cooperations.

Related pages

• Permission System — the roles and layers that decide every access
• Cooperations and Cooperation Restrictions — the sanctioned way across the boundary
• Access Audit Logging — the record of every access
• Cloud Overview — how the platform is built