Organisations and data isolation
How your data is kept apart, and what you control about it.
Organisations #
Every deployment holds one or more organisations. An organisation has its own members, roles, credentials, settings and telemetry, and nothing is shared between organisations.
Telemetry is written under the organisation that owns the API key that sent it, so a sender cannot place data in another organisation.
How isolation is enforced #
Isolation is applied at the storage layer rather than in the query, so a missing filter cannot widen a result set.
- Relational data carries its organisation on every row, and a query only ever returns rows matching the organisation in the request.
- Telemetry is partitioned and filtered by organisation on every read.
- Every query that reads telemetry must name its organisation, and a build-time check fails if one does not.
Member access #
A request must arrive as a member of the organisation it is asking about. A token that names no member is refused, and a member of one organisation cannot read another's data.
A service credential is not a member
Machine credentials authenticate the sender but do not grant read access to an organisation. Reading is always performed on behalf of a named member.
Deleting an organisation #
Deleting an organisation removes its members, credentials, settings and telemetry. The deletion is recorded in the platform audit trail, which is kept independently of the organisation so the record of the deletion survives it.
Deletion is permanent
Removing an organisation removes its telemetry. Archive anything you need to keep before you delete.
What to review periodically #
- Members who no longer need access.
- API keys for workloads that have been decommissioned.
- Archive configuration for buckets you no longer own.
Onward #
This page is about where data sits. Who may see it is Identity and roles, what your workloads may send under their own name is Scoped API keys, and every change to any of it is recorded in the Audit trail.