_Post 12 of the AI in cyber series._
The single most valuable property of a managed AI SOC service is the one that is hardest to engineer responsibly: the fact that protecting one customer well teaches you to protect every other customer better. The intelligence the platform develops from one tenant's incident — without ever exposing that tenant's data — flows into every other tenant's protection. This is the commercial premise of the SaaS variant and it is the property that the on-premises single-customer deployment, by construction, cannot offer.
I have referred to this property obliquely through the series. This post treats it directly. What the cross-tenant intelligence problem actually is, what engineering it well looks like, and the seven principles EmilyAI's v1.1 schema work was built around. The comparison to the LLM-based competitors is sharp here because, in the products I have evaluated, the cross-tenant intelligence question is largely not being addressed at all — and the customers do not yet know to ask.
The problem, in one paragraph
A managed AI SOC sees, in aggregate across its customer base, more attack telemetry than any single customer could ever generate from their own network alone. The intelligence value of that aggregate is enormous. The privacy and contractual risk of that aggregate is also enormous. Customer A's data is, often by contract, never to leave Customer A's tenancy or be processed for any purpose other than serving Customer A. Customer A's data, if exposed to Customer B, is a contractual breach. The engineering challenge is to extract the intelligence value of the aggregate without ever moving raw customer data across the tenant boundary, and to be able to demonstrate, by audit, that this has been done.
The seven principles
The v1.1 schema work — described in our technical due diligence document — formalises seven principles that govern cross-tenant intelligence in EmilyAI.
Raw events never cross the tenant boundary. Customer A's events are processed in Customer A's tenancy. Period. The cross-tenant intelligence model is built from derived artefacts, not from raw events. This is enforced structurally — the tenant identifier is on every record, every stream key, every database query, and every authorisation check. A record without a tenant or a query without a tenant filter is invalid by construction.
Derived intelligence is anonymised before promotion. When a finding from Customer A is promoted to the fleet, it is stripped of customer-identifying information before promotion. The anonymised form is a structured artefact — pattern shapes, indicator hashes, anomaly fingerprints — that does not contain any of the source customer's specific data.
Promotion requires a tenant-count threshold and a cool-off period. No single customer's experience promotes to the fleet alone. A pattern has to appear in at least N tenancies before it is eligible for promotion, and a cool-off period prevents promotion within a narrow time window that might allow inference back to the original source. The thresholds are configurable per indicator type; they are not negotiable below a documented floor.
Customer consent is recorded as data. Cross-tenant promotion happens only for tenants who have opted in to the fleet model. Consent is recorded on every record the policy governed, not as a one-time setting in a config file. An external assessor can read the audit tables and see, for any specific promoted indicator, that the source tenant had consented and that the policy was in force at the time.
Audit transparency. The platform's audit log is hash-chained and continuously shipped off-host. The promotion service's actions — artefact X was promoted from tenant Y to the fleet at time Z under policy version W — are visible in the chain. The chain is tamper-evident; a complete host compromise cannot rewrite the historical record.
The fleet tenant has structural privileges that are themselves auditable. The fleet model that benefits from cross-tenant intelligence is itself represented as a distinct tenant within the schema, with the same identifier rules as a customer tenant. Whose data was used to update the fleet model when is queryable from the same tables that govern customer data.
On-premises deployment loses the cross-tenant uplift by construction. A customer who deploys EmilyAI on their own hardware, on their own premises, gets the same analyst, the same connectors, the same continuous learning from their own feedback — but the cross-tenant intelligence is unavailable because there is no fleet of one. This trade-off is explicit in the architecture and explicit at sale.
Why this is harder than it sounds
Three properties of cross-tenant intelligence that make the engineering subtle.
Anonymisation is not a single technique. A naive strip the customer name and replace with a hash approach is broken because the patterns themselves can identify the customer. A promoted indicator that says unusual outbound DNS to a specific subdomain, in a specific TLD, on a specific port pattern may be so customer-specific that the anonymisation does no real work. The threshold-and-aggregation discipline is what makes the anonymisation robust. N tenancies have seen this pattern is what makes the pattern non-identifying.
Promotion latency is a real concern. A threat indicator that has just appeared in Customer A's tenancy is most useful to Customer B before it appears in Customer B. But the tenant-count threshold means the indicator does not promote until it has appeared in N tenancies. The trade-off between early warning value and anonymisation strength is irreducible. Different indicator types warrant different thresholds.
The audit trail has to satisfy a regulator who has not been in the conversation. The customer's regulator may ask, years later, how cross-tenant intelligence sharing has worked for that customer specifically. The audit trail has to make the answer specific, reproducible, and verifiable by someone who was not part of the engineering. This is the property that makes the consent as data on every record discipline pay back.
What the LLM-based vendors do instead
The dominant pattern in the LLM-based cyber AI category is, in cross-tenant intelligence terms, structurally simpler and structurally more concerning.
The vendor's model is trained centrally on a corpus that may or may not include customer data. The customer's contractual position varies — some vendors disclose explicitly, some are vague, some are silent. The retraining cadence is determined by the vendor. The customer's ability to audit was my data used in your training set, and if so, when, and under what terms is, in most current products, limited.
This is not a malicious posture. It is a posture inherited from the consumer-LLM origins of these products and not yet updated for the enterprise-security buyer's expectations. The expectations are catching up. I expect, through the remainder of 2025 and into 2026, a wave of explicit contractual language and product changes to address the cross-tenant intelligence question more rigorously. The vendors who have been thinking about this for years will have a smaller catch-up to do than the vendors who have not.
What customers should ask
Three questions worth pushing on with any AI security vendor.
What of my data is used to train your model, and on what schedule? The vendor who cannot answer specifically is not yet engineered for the enterprise-security buyer. The answer should be in the contract, not the marketing.
If my data is used, how is it anonymised before being aggregated with other customers' data? If the answer is we do not aggregate, you do not get the cross-tenant uplift. If the answer is we aggregate but anonymisation is X, you can evaluate whether X is robust.
What does my consent record look like? Is it a one-time tickbox or is it recorded against every promoted artefact? The latter is the audit-grade discipline; the former is the policy-assurance discipline. They are not equivalent.
What is next
In six weeks: the agent demos vs the agent in production, eighteen months on. The shape of the agent that actually ships, in the wild, in production, in 2025. What we have learned from the first generation of operator-style deployments.