When a managed security service provider evaluates an enrichment platform for multi-tenant use, the term "tenant isolation" appears in every vendor's pitch deck. The term covers a wide spectrum of actual implementation architectures, ranging from database-level row filtering on a shared schema (weak isolation with significant bleed risk) to fully independent per-tenant enrichment pipelines with no shared infrastructure (strong isolation with corresponding cost implications). Understanding where a vendor's implementation sits on this spectrum is a due diligence requirement, not a nice-to-have.
The Five Isolation Layers
A rigorous isolation assessment examines five distinct architectural layers, each of which can be implemented at varying levels of isolation strength:
Data layer isolation: Whether tenant IOC submissions and enrichment results are stored in physically separate databases, logically separated schemas within a shared database, or separated only by row-level access control filters on a fully shared table. Physical separation provides the strongest isolation guarantee — a misconfigured query or a SQL injection vulnerability cannot reach another tenant's data if the data is in a different database instance. Row-level filtering provides weaker guarantees because the isolation depends entirely on the access control logic being correct in all query paths.
Enrichment pipeline isolation: Whether the enrichment pipeline processes each tenant's IOCs through dedicated compute resources, or whether tenant IOCs are processed through a shared worker pool. A shared worker pool that processes IOC batches from multiple tenants introduces two risks: (1) tenant A's IOC submission appearing in the enrichment cache in a way that influences tenant B's enrichment result for the same indicator (cache leakage), and (2) tenant A's high-volume submission displacing tenant B's IOC from the processing queue (noisy neighbor throughput interference).
API credential isolation: Whether each tenant's API key provides access only to their tenant's enrichment data, with no possibility of query construction that could retrieve another tenant's results. API isolation depends on both the credential scope (what data can this key access?) and the query parameter validation (can a malformed request retrieve data outside the credential scope?).
Enrichment context isolation: Whether contextual enrichment data that is built up from historical observations — "this IOC has been submitted 47 times by various customers over the past 30 days" — leaks any information about other tenants' IOC submission patterns. A well-designed multi-tenant platform strips customer-specific context from shared enrichment results so that one tenant cannot infer another tenant's threat environment from the enrichment data they receive.
Logging and audit isolation: Whether the audit log for one tenant's API activity is accessible to another tenant's users, and whether the enrichment platform vendor's own operations staff can access individual tenant IOC data without authorization logging and customer notification. For regulated industries (financial services, healthcare), the audit log isolation requirements may be contractually specified in the MSSP's customer agreements.
The Cache Leakage Problem
Cache leakage is the most subtle and most commonly overlooked isolation failure mode. When an enrichment platform caches the results of feed queries to reduce API call volume and improve response latency, the cache key typically includes the IOC value (IP address, domain, hash) and possibly the enrichment configuration parameters. If two tenants submit the same IOC for enrichment, the second submission can be served from the cache populated by the first tenant's query.
In most cases, this is harmless: the cached enrichment data represents public threat intelligence feed results that are not specific to any customer. A cache hit for a known malicious IP returns the same verdict regardless of which tenant submitted it. The problematic case is when the enrichment result includes customer-specific context: frequency of observation, temporal pattern of submissions, or organizational context tags that the first tenant's submission annotated onto the IOC.
The correct implementation strips all customer-specific context from cached results before returning them to a different tenant. The shared cache should contain only public threat intelligence feed results; customer-specific annotations should be stored and returned only within the submitting tenant's data scope. Not all enrichment platforms implement this correctly, and the failure is not visible in normal operation — it only surfaces when you specifically look for cross-tenant context bleed.
Testing Tenant Isolation
An MSSP can verify tenant isolation quality using a structured test protocol:
Data isolation test: Create two test tenants (Tenant A and Tenant B) with separate credentials. Submit a unique synthetic IOC (a clearly non-malicious domain with a distinctive string pattern) via Tenant A's API. Query the same IOC via Tenant B's API. If the result returns any data beyond "not found in feeds" — including a submission count, a timestamp of first observation, or any context suggesting the IOC has been seen before — there is cross-tenant context bleed.
Cache leakage test: Submit an IOC known to be in public threat feeds via Tenant A, wait for the result, then submit the same IOC via Tenant B. Verify that the Tenant B result contains no fields indicating Tenant A submitted the IOC or when Tenant A's submission occurred. The enrichment verdict (malicious/clean) may legitimately be the same — the test is specifically for customer-specific metadata leakage.
Noisy neighbor test: Submit a high-volume batch of IOCs via Tenant A (1,000+ in rapid succession) and simultaneously measure the enrichment response latency via Tenant B. If Tenant A's batch significantly degrades Tenant B's response latency (more than 2x degradation), the enrichment pipeline does not provide throughput isolation between tenants. This is a service quality issue rather than a security isolation issue, but it affects MSSP SLA compliance for individual clients.
API credential scope test: Attempt to construct API requests using Tenant A's credentials that retrieve Tenant B's IOC history or enrichment audit logs, using predictable tenant ID values if the API uses sequential identifiers. This tests whether access control is enforced at the query level or only at the credential validation level.
Contractual and Compliance Implications
For MSSPs serving regulated industries — particularly financial services clients subject to SOX and GLBA, and healthcare clients subject to HIPAA — the enrichment platform's tenant isolation architecture has compliance implications that extend beyond operational security. If client IOC data (which may include internal IP addresses, employee account names associated with compromise events, or patient record system identifiers) is submitted for enrichment, the data handling requirements for that submission may be subject to the client's data processing agreements.
The due diligence questions for compliance purposes: Does the enrichment platform's data processing agreement cover multi-tenant MSSP deployment? What are the data residency commitments (EU data stays in EU, for GDPR-regulated clients)? What are the data retention commitments for submitted IOC data? Is the enrichment platform willing to provide a data processing addendum for individual MSSP clients, or only at the MSSP account level?
ThreatPulsar's enterprise tier includes per-tenant data residency configuration, allowing MSSP accounts to specify the data region for each tenant's enrichment data independently. Tenant isolation in the ThreatPulsar data model uses separate encryption key hierarchies per tenant, so data at rest is isolated at the cryptographic level, not just the access control level.
When Shared Infrastructure Is Acceptable
Full per-tenant infrastructure isolation carries corresponding cost implications — dedicated compute, storage, and pipeline resources per tenant are more expensive than shared infrastructure. For MSSPs managing many small clients, the cost of full physical isolation may not be proportional to the actual isolation risk, particularly when the clients are in different industries with no confidentiality relationship between them.
Shared infrastructure with strong logical isolation is an acceptable architecture when: the enrichment results are limited to public threat intelligence feed data with no customer-specific annotation; the API credential scope is correctly enforced; and the MSSP has no contractual obligation to physically isolate client data. The test protocols above can verify that logical isolation is functioning correctly without requiring physical infrastructure separation.
Conclusion
Tenant isolation is a spectrum, and vendors who claim it without specifying their implementation layer are leaving MSSP buyers without the information needed to make an informed assessment. The five isolation layers — data, pipeline, API credentials, enrichment context, and audit logging — each carry different implementation approaches and failure modes. Testing isolation quality with the structured protocol above is a straightforward due diligence step that provides direct evidence of isolation fidelity rather than relying on vendor assertions.
The operational cost of a tenant isolation failure in an MSSP environment is high: client data breach notification obligations, potential regulatory enforcement, and loss of client trust. The due diligence investment to verify isolation before deploying a multi-tenant enrichment platform is small in comparison.