One platform, many customers, complete isolation.
Run a single GuardsArm deployment and deliver managed security to many clients, each seeing only their own data, under your own brand.
What is at stake
For a service provider, a single cross-tenant exposure is not a defect report — it is the kind of event a business does not reliably survive.
Enforcement at the data layer rather than in the interface is a materially different answer when a prospect’s auditor asks how separation works, and it is the question that decides enterprise deals.
A re-brandable console means you are not introducing your supplier to your customer. For most providers this is the commercial difference between reselling and having a product.
One deployment serving many tenants, with scriptable onboarding, means operational cost does not scale linearly with the customer count — which is the entire economic case for managed delivery.
Who carries this
The service-provider principal. This is a commercial module more than a technical one, and it is usually evaluated alongside the pricing model rather than the detection content.
The problem
Ask a vendor how their multi-tenancy works and you will often find the answer is that the interface filters by tenant. Every customer’s data sits in one store, and the separation is a clause in a query that the application is trusted to add.
That holds until something goes around the application: a crafted search, a direct API call, a bug in a new feature, a misconfigured role. The consequence of any of those is not a defect report — it is one customer seeing another customer’s security data, which for an MSP is the kind of incident a business does not always survive.
GuardsArm enforces isolation at the data layer, with per-tenant document-level security on the index itself. A query that reaches past the tenant boundary returns nothing regardless of which interface, API or account issued it, because the boundary is not in the interface.
Interface-only separation fails the first time a query is issued outside the console. That is not a hypothetical; it is how these incidents happen.
Capabilities
Each customer is a tenant and agents map to a customer group. Tenants are separated at the data layer and by RBAC — not by hiding rows in the interface.
Operators switch between tenants from one console, and each customer gets a dedicated portal view of their own estate.
The interface is re-brandable for white-label delivery, so the platform carries your identity rather than ours.
Customer onboarding creates the organisation, isolation, enrollment and welcome pack as one repeatable operation — and offboarding reverses it cleanly.
How it fits the platform
Data-layer isolation is what makes the multi-tenant claim defensible under scrutiny. An interface-only separation fails the first time a query is issued outside the console.
Isolation
Four layers. The third is the one that decides whether the claim survives scrutiny.
| Layer | Interface-only multi-tenancy | GuardsArm |
|---|---|---|
| The interface | Filters the view to the tenant the user belongs to. | Does this too — but it is the last line, not the only one. |
| Role-based access control | Governs which screens and actions a user reaches. | RBAC policies apply on top of data-layer isolation rather than instead of it. |
| The data layer | Usually nothing. The index holds every tenant and trusts the query. | Per-tenant document-level security on your own infrastructure. A query that reaches past the tenant boundary returns nothing, whoever issued it. |
| The failure mode | A bug, a crafted query or a direct API call exposes another tenant. | The boundary is enforced where the data lives, so it holds outside the console as well as inside it. |
How it works
Idempotent throughout, because an MSP onboards customers often enough that it has to be scriptable.
A new customer becomes a tenant. Onboarding is idempotent, which matters more than it sounds for anyone scripting it: re-running a partially failed onboarding converges rather than duplicating.
Document-level security and RBAC policy are applied for the new tenant at the data layer, so separation exists before any data arrives rather than being configured after.
Agents map to the customer group using expiring enrolment tokens. Group membership is what determines both configuration and tenant attribution.
Onboarding produces the customer-facing material as part of the same process, so a new tenant is deliverable rather than merely configured.
Offboarding is equally idempotent. Removing a customer cleanly is the step most platforms treat as an afterthought and most MSP contracts treat as an obligation.
The commercial case
Written for the person deciding whether this can be resold rather than only operated.
| Aspect | Reselling a cloud MDR | Delivering GuardsArm |
|---|---|---|
| Deployments to run | One per customer. Operational cost scales linearly with the customer count. | One deployment serving many tenants. |
| Cost shape | Per-customer metering, typically passed through with a margin on top of a margin. | Self-hosted licensing on infrastructure you own. Your margin is yours. |
| Whose brand the customer sees | The vendor's. | Yours. The console is re-brandable. |
| Where customer data sits | In the vendor's cloud, under their terms. | On your infrastructure, under yours — which is frequently what makes a regulated customer addressable at all. |
Terms
Access control enforced on individual documents in the index rather than in the application above it. This is the mechanism behind the tenant-isolation claim, and it is the one worth asking any multi-tenant vendor to describe.
An operator moves between customer contexts without logging out or running parallel deployments. One console, many customers, with the active tenant always explicit.
A customer-facing view of their own environment — incidents, assets, threat map, vulnerabilities, compliance, service and reports. A deliverable your customer logs into, not a PDF you email.
The console is re-brandable, so the product your customer sees is yours. For an MSP this is frequently the deciding feature, because the alternative is introducing your supplier to your customer.
Background
Plain explainers on the underlying ideas, written for someone evaluating rather than buying.
Questions
At the data layer, through per-tenant document-level security in your own infrastructure plus RBAC — not by hiding rows in the interface. An interface-only separation fails the first time a query is issued outside the console.
Yes. The console is re-brandable for white-label delivery, and each customer gets a dedicated client portal view of their own estate.
Onboarding creates the organisation, isolation, enrollment and welcome pack as one repeatable operation, and offboarding reverses it cleanly.
Yes — that is the model. Note that multi-node high-availability clustering is on the roadmap rather than generally available, so deployments are single-node today.
Works with
Every module runs in the same self-hosted stack and shares the same telemetry, severity model and response engine.
We will walk through the console, the deployment model and what it takes to stand it up in your environment.
