Cross-Tenant Leakage in Shared Detection Models

Multi-tenancy in cloud security platforms is an engineering achievement: a single trained model serving many organizations is dramatically more cost-efficient than training a separate model for each, and the pooled training data produces a model that generalizes better than any single organization's data could support. The privacy cost of this architecture has received attention — training a model on pooled customer data raises straightforward confidentiality questions about what information the training data reveals. Less attention has been paid to the inference-time privacy cost: what information can a tenant infer about other tenants by querying the shared model, observing its outputs, and analyzing its behavior? This article addresses that question systematically, because the answer — that meaningful inference is possible under realistic conditions — has direct implications for how shared SOC detection models should be architected, deployed, and governed.

The Shared Detection Model Architecture

A shared detection model is a machine learning system trained on pooled telemetry from multiple organizations and used to provide detection services for all of them. In MSSP and SaaS autonomous SOC contexts, shared models are attractive for three reasons: the pooled training dataset is larger and more diverse than any individual organization's dataset, reducing the base-rate problem and improving the model's generalization; training and maintenance costs are amortized across many customers; and behavioral patterns observed in one organization's environment can inform detection in others.

The shared model receives telemetry from each tenant, applies learned detection logic to that telemetry, and returns detection scores and, in autonomous SOC deployments, triggers response actions. The tenants interact with the model through a defined API: they submit events, they receive scores, and they may provide feedback signals (alert ratings, post-incident classifications) that are incorporated into the model's ongoing training. What the tenants typically do not receive is visibility into the model's internal parameters, its training data, or the specific events from other tenants that influenced its behavior.

The privacy assumption embedded in this architecture is that the model's API — score queries and feedback submissions — provides only output information, not input information from other tenants. This assumption holds when the model's behavior is perfectly independent of the specific training samples from each tenant. It fails, to varying degrees, when the model's output for a given input is influenced by the presence or characteristics of specific training samples from other tenants — which is the standard case for overfit or partially overfit machine learning models.

Chandola, Banerjee and Kumar (2009) note that anomaly detection models trained on specific behavioral baselines will produce different scores for the same event depending on what the baseline contained. This observation implies that the score a shared model assigns to a tenant's event is a function not just of that event but also of the training data from all other tenants — creating the possibility that the score reveals information about other tenants' behavior.

Three Cross-Tenant Leakage Channels

Cross-tenant leakage can occur through three distinct channels, each exploiting a different property of the shared model's relationship to its training data.

Membership inference is the ability to determine whether a specific event from another tenant was included in the model's training data. Gretton et al. (2012) characterize the general statistical problem of two-sample testing — distinguishing whether two samples came from the same distribution — which underlies membership inference. A model trained with gradient descent memorizes certain training samples, particularly those in sparse regions of the feature space. These memorized samples produce distinctively low anomaly scores when submitted to the model, because the model has explicitly learned to classify them as normal. An attacker who submits a candidate event and observes a distinctively low score can infer that the event (or events very similar to it) was present in the training data from another tenant.

Feature inference is the ability to reconstruct statistical properties of other tenants' behavioral baselines from the model's behavior across a set of queries. If the shared model's anomaly score for an event is a function of the distance from that event to the learned behavioral centroid, then submitting events at different positions in the feature space and observing how scores vary reveals the shape and location of the centroid — which in turn reveals information about the behavioral baseline that was used to train it. For a shared model trained partly on another tenant's baseline, this inference reveals information about that tenant's network behavior.

Model inversion is the ability to reconstruct representative examples of training data from the model's learned parameters. This channel requires access to the model's gradients or intermediate outputs and is therefore primarily relevant in settings where tenants can directly query the model with custom inputs and observe fine-grained outputs. Apruzzese et al. (2023) document the general vulnerability of ML security systems to inference attacks; the model inversion channel is the most technically demanding but also the most powerful, as it can directly reconstruct behavioral patterns from the training data.

Conditions for Feasible Membership Inference

Membership inference against a shared detection model is feasible under conditions that are frequently present in practice. The necessary conditions are: (1) the model has memorized some training samples to a degree that produces distinctively different outputs for those samples compared to samples not in training; (2) the attacker can submit candidate inputs and observe the model's output; and (3) the attacker has enough prior knowledge to identify which candidate inputs to test.

Condition (1) is related to model overfitting but is not identical to it. A model may generalize well on average while still memorizing specific anomalous or sparse training samples. Anomaly detection models are particularly susceptible because they explicitly model what is normal — sparse or unusual events in the training data are precisely the events that a sophisticated adversary would want to test, because the model's treatment of them reveals what behavioral patterns it has learned from other tenants.

Condition (2) is the standard access model for MSSP/SaaS detection: tenants can submit events and observe scores. This access model is necessary for the service to function and cannot be eliminated without breaking the service.

Condition (3) depends on the attacker's goals. An attacker who wants to know whether another tenant uses a specific application, network address range, or user identity pattern needs enough domain knowledge to construct candidate events that would appear in that tenant's telemetry. This is often feasible for well-resourced attackers targeting specific competitors in the same MSSP platform.

Sommer and Paxson (2010) observed that ML-based intrusion detection is vulnerable to adversarial probing precisely because the model's behavior reveals its internal structure to a patient probing adversary. The membership inference channel instantiates this observation: the model's differential treatment of training versus non-training samples is a form of internal structure leakage.

Feature Inference and the Behavioral Baseline Side Channel

Feature inference against a shared detection model exploits the fact that the model's anomaly score for an event reflects the event's relationship to the learned baseline, which is a function of all tenants' training data. By submitting events at different positions in the feature space and observing how scores vary, an attacker reconstructs a map of the baseline's structure — which reveals statistical properties of other tenants' behavior.

The practical attack proceeds in two phases. First, the attacker calibrates their understanding of the shared model's structure by submitting events from their own environment and correlating observed scores with their own known baseline. This establishes the relationship between score magnitude and distance from the baseline. Second, the attacker submits events corresponding to behavioral patterns not present in their own environment and observes whether the model assigns unusually low anomaly scores. Low scores for events not in the attacker's own baseline suggest those events were present in another tenant's training data.

The information this reveals is limited by the resolution of the feature inference — the attacker can detect the presence of broad behavioral patterns (a specific network protocol, a specific application fingerprint) but may not be able to reconstruct fine-grained details. However, even coarse-grained behavioral information can be valuable competitively: confirming that a competitor uses a specific cloud provider, operates in a specific geographic region, or employs a specific security technology may be inference-worthy for industrial espionage purposes.

The OWASP Agentic Security Initiative (2025) identifies unauthorized inference from AI systems as a primary threat class for AI-enabled security platforms; feature inference instantiates this threat for shared detection models specifically.

Isolation Controls: Reducing Leakage Without Losing Scale Benefits

The leakage channels identified above do not require eliminating shared model training — that would sacrifice the scale benefits that motivate the architecture. Instead, they require architectural isolation controls that reduce the amount of information available per query and limit the ability of any tenant to reconstruct information about other tenants from model behavior.

Differential privacy provides a formal framework for limiting information leakage from trained models. A differentially private model provides a mathematical guarantee that the presence or absence of any individual training sample — or any tenant's complete dataset — has bounded influence on the model's outputs. Implementing differential privacy in the training process adds noise in a controlled way that is analytically bounded; the privacy-utility trade-off can be adjusted by the privacy budget parameter. For shared SOC detection models, the appropriate granularity of privacy guarantee is at the tenant level: the model's outputs should be approximately the same whether or not any given tenant's training data was included.

Federated learning provides an alternative architecture that achieves some scale benefits without centralizing raw training data. In federated learning, each tenant trains a local model on their own data and sends only model updates (gradients or parameter deltas) to a central aggregator, rather than sending raw events. The aggregator combines the updates into a global model. Raw events from individual tenants never leave their environment. This architecture eliminates the training-time leakage risk but does not eliminate inference-time leakage: the shared model that results from federated aggregation still reflects properties of each tenant's data and can still be probed for membership information.

NIST AI 100-1 (2023) identifies privacy as a core AI risk category and requires that AI systems deployed with access to multi-party data assess and mitigate privacy risks specific to the shared data context. Cross-tenant leakage in shared detection models is precisely the privacy risk that this requirement addresses.

Limitations

The leakage analysis presented here is qualitative: it identifies the channels and conditions but does not quantify the bits of information leaked per query for a specific shared model deployment. Quantifying leakage requires empirical measurement against the specific model and architecture in use, which depends on model details that are rarely disclosed by MSSP and SaaS providers. Organizations should treat the qualitative analysis as sufficient justification for requiring leakage controls during procurement, and use the controls to bound the risk even in the absence of exact leakage quantification.

Differential privacy guarantees are mathematically precise, but their practical security value depends on the privacy budget selected and the sensitivity of the function being protected. Too-large privacy budgets provide weak guarantees; too-small budgets significantly degrade model utility. Calibrating the privacy budget for a shared SOC detection model requires domain expertise and empirical evaluation that is rarely conducted by MSSP providers today.

Federated learning reduces raw data sharing but does not eliminate gradient-based leakage: model updates (gradients) can themselves reveal information about local training data. Gradient-based membership inference is an active research area, and organizations adopting federated learning as a privacy control should monitor the literature for attacks that apply to their specific architecture.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

Glossary

Cross-Tenant Leakage

The inference of behavioral signals about one organization from a machine learning detection model trained on pooled data from many organizations, achievable through query analysis without any breach of raw data isolation.

Membership Inference

A leakage channel in which an adversary determines whether a specific event or behavioral pattern was included in a shared model's training data by observing the model's differential treatment of candidate inputs.

Feature Inference

A leakage channel in which an adversary reconstructs statistical properties of another organization's behavioral baseline by submitting events at different positions in the feature space and observing how the shared model's scores vary.

Model Inversion

A leakage channel in which an adversary reconstructs representative training data from a model's parameters or gradients, directly revealing behavioral patterns from other tenants' training datasets.

Differential Privacy

A mathematical framework for limiting the information that a trained model's outputs reveal about any individual training sample, achieved by adding calibrated noise to the training process in a way that bounds the sensitivity of the model to any single input.

Federated Learning

A distributed machine learning architecture in which local models are trained on each participant's data and only model updates are shared with a central aggregator, rather than raw training data, reducing training-time leakage.

References

1. Chandola, Banerjee & Kumar — Anomaly Detection: A Survey (ACM Computing Surveys, 2009)
2. Gretton et al. — A Kernel Two-Sample Test (Journal of Machine Learning Research, 2012)
3. Sommer & Paxson — Outside the Closed World: On Using Machine Learning for Network Intrusion Detection (IEEE S&P, 2010)
4. Apruzzese et al. — The Role of Machine Learning in Cybersecurity (Digital Threats: Research and Practice, 2023)
5. NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
6. OWASP Agentic Security Initiative: Agentic AI Threats and Mitigations (2025)
7. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems