An MSP’s monitoring platform holds telemetry, topology and credentials for many customers at once. A cross-client leak is not a minor bug; it can end a contract. The same questions apply to any network operations team that serves several business units, regions or subsidiaries. “Multi-tenant” on a feature list should prompt questions about exactly where isolation is enforced.
Isolation is more than a tenant column
A tenant identifier on database rows is a starting point. Data also moves through caches, search indexes, message buses, live event streams, exports, logs, notification channels and any AI enrichment step. A leak in any of them defeats the database controls. Ask where tenant scoping is enforced and whether it is enforced by the platform itself or left to each developer to remember on every query.
Layers to verify
- Storage: database access rules that fail closed when the tenant is missing
- Application queries: tenant scope derived from the authenticated session, never from a client-supplied field
- Caches and indexes: keys and namespaces that include the tenant
- Real-time events: WebSocket or streaming messages delivered only to authorized tenants
- Notifications and exports: destinations configured per tenant
- Logs and support access: operator actions attributable and scoped
- AI providers: prompts limited to one tenant’s data with documented redaction and retention
Credentials and collectors
Device credentials should be stored per tenant, ideally least-privilege where the monitoring goal allows it, and never shared across clients. Collectors that run inside a customer network should authenticate with per-tenant identity and be revocable without affecting anyone else. For a fuller look at safe collection, see least-privilege network monitoring for NOC teams.
Roles that match how MSPs work
MSP staff need to operate multiple clients, while a client user should see only their own environment. Useful role models separate a platform administrator, an MSP technician limited to assigned clients, a customer administrator and a viewer with no edit rights. Every role should be checked on the server, not merely hidden in the interface.
Per-tenant thresholds and noise
One client’s normal is another’s outage. A shared global CPU or utilization threshold produces noise for some clients and misses problems for others. Thresholds, maintenance windows and notification routes should be configurable per tenant, and one noisy tenant should not degrade processing for the rest.
Tests you can run in an evaluation
- Sign in as one tenant and attempt to request another tenant’s device or incident by identifier
- Open two tenants side by side and confirm live updates never cross
- Search for a hostname you know exists only in another tenant
- Remove a user’s role and confirm access stops immediately
- Ask how a tenant’s data is deleted when the contract ends
AssureMesh’s approach to evidence and claims is described on the evidence page, and the security summary is on the security page.