"No customer data leaves the tenant" is either a property of your architecture or a sentence in your marketing. The difference is whether a prospect can check it. Here is what in-tenant actually means in this system, the two places the absolute claim breaks, and why volunteering those is the strongest move available.
What in-tenant means here
The agent runs as a container inside the customer's own cloud subscription, deployed by their service provider, using an identity that lives in their directory. It queries their SIEM, reads their telemetry, and writes its findings back into their own incident records.
Everything that a normal security product would ship to a vendor cloud — raw log excerpts, entity names, intermediate findings, investigation state, the audit trail of every query it ran — stays inside their subscription. Not encrypted in transit to me. Not anonymised before sending to me. Never sent.
The write surface is deliberately narrow: incident comments, verdicts, and messages to a chat channel. The agent cannot disable an account, isolate a device, or modify a rule. That is a safety decision as much as a sovereignty one, and it is the subject of its own argument about where responsibility sits.
The two residuals
An absolute claim is a liability, because a diligent prospect will find the exceptions and then discount everything else you have said. There are two.
Inference. The reasoning runs on a language model, and during the proof of concept phase that model was reached using my API key, which means investigation content — including log-derived text — transited a model provider on my account. This is the single largest residual and it is the reason the inference backend moved to a model the customer provisions inside their own cloud. Until that migration is complete for a given deployment, the honest statement is "everything except inference", not "nothing".
Telemetry and threat intelligence. Attacker artefacts — hashes, addresses, domains, technique identifiers — are submitted to a central store so that a confirmed finding in one tenant improves detection in the next. That is a real outbound flow. It is defensible, it is stripped of customer environment data, and it is optional. It is not nothing, and describing it as nothing would be a lie a competent buyer could catch.
| Category | Leaves the tenant? |
|---|---|
| Raw telemetry, log excerpts, query results | No |
| Entity names, user identifiers, host names | No |
| Investigation state, findings, audit records | No |
| Verdicts and reports | No — written to their own incident and chat |
| Model inference content | Yes, until in-tenant inference is provisioned |
| Attacker artefacts for threat intelligence | Yes — environment-stripped, optional |
The move: don't trust us, audit us
An unknown vendor's assurance is worth nothing, and it should be worth nothing. A security buyer who accepts "we're safe by design" from a company they had not heard of last month is not doing their job.
What changes the conversation is not a stronger assurance. It is handing them the means to check. That means publishing the exact permission list with a justification for each individual permission, the exact outbound endpoints with what transits each one, the precise boundary of what the agent can and cannot write — and then telling them how to verify it from their own side, by watching the container's outbound connections with their own cloud network logging, which they control and I cannot influence.
Why this is a business decision, not a technical one
In-tenant deployment looks like a constraint imposed by paranoid customers. It is better than that. It resolves data residency structurally rather than contractually, which means the same architecture serves a regulated customer in one jurisdiction and a small business in another with no variant build. It moves the compute cost onto the customer's bill, which is what makes the unit economics work. And it removes an entire category of liability: I cannot leak data I never receive.
The cost is operational. Debugging a system you cannot see into is harder. Telemetry about the agent's own health has to be designed deliberately and narrowly rather than collected by default. Shipping a fix means a customer-side deployment rather than pushing to my own infrastructure. Those costs are real, and every one of them is a cost I would pay again, because the alternative is a claim I cannot defend in the one conversation that decides the sale.