A data governance vendor asks you to do one strange thing on day one: copy a stream of your most sensitive telemetry into their cloud so they can watch it for you. To govern the data, you first hand a copy of it to a new owner. To shrink the blast radius, you widen it.
For a security team under residency rules, that is where the evaluation stalls. The detection looks strong. Then the infrastructure team asks where the data goes, the answer is "out," and the conversation ends.
Hilt runs single-tenant by default. Your deployment lives in your own account on AWS, GCP, Azure, or Ali Cloud. The collector watches on your hosts, the analysis runs on your infrastructure, the case gets written in your account, and the events never leave it. The vendor ships software. The vendor does not become a second copy of your environment.
Logical partition is not the same as your account
"Single-tenant" gets stretched to cover things it should not. Most offerings labeled single-tenant give you a dedicated logical partition inside the vendor's multi-tenant SaaS. Your data still lands on the vendor's infrastructure. It is walled off from other customers, which is worth something, and it is not the thing you were promised. Your telemetry left your account.
Single-tenant in your own cloud is stricter. The collector runs on your hosts. The pipeline that turns a raw kernel event into a written case runs on infrastructure you own and audit. The findings live where you can see them. You operate the controls; the vendor operates the code.
Here is the test, and it is one you can run yourself. Cut the network path to the vendor entirely. Does the product still see your data move and still write the case? If it goes dark, the analysis was never in your account. It was in theirs, and you should know exactly where "theirs" is.
The default decides who carries the residency risk
When the default is "ship your telemetry to us," you spend the next month negotiating it back. A data processing addendum. A regional commitment. A subprocessor list. A yearly attestation that the vendor still handles your data the way the contract claims. You pay for all of it in legal time, and at the end a copy of your sensitive telemetry still lives outside your control. The contract describes the risk. It does not remove it.
When the default is single-tenant in your own cloud, the residency question is answered before anyone asks it. There is no telemetry whose location you have to negotiate, because nothing moved. The governance system inherits the residency, sovereignty, and access controls already enforced on the account it runs in. Nobody carves a new exception into your boundary.
The same instinct governs what Hilt reads. Metadata only is the default vantage, so the system sees that a pattern of movement is wrong without opening the files. Content-aware inspection is there when you want it, never as the price of admission. Single-tenant residency and metadata-only inspection answer the same two questions a vendor usually answers wrong: where does the data have to live, and who has to read it. With Hilt, the answer to both is nobody new.
What actually stays in your account
"Your data stays put" is easy to say and easy to hand-wave. Walk the path instead.
The collector watches data movement at the kernel, metadata only by default, off the path. Its footprint stays small enough that it is not a real tenant on the host: on the order of 0.1% of one core and 4 to 8 MB of memory. It never sits inline. It does not block, drop, or alter traffic. It watches the move; it does not stand in front of it.
Each move resolves to a probabilistic, source-dependent identity. Which user. Which job. Which destination. Whether this fits what that identity normally does. That resolution happens in your account. The baseline, the history of how your data actually moves, gets built from your environment and stored in your environment. When the pattern turns anomalous, the case gets written in your account. When the response fires, it is host-level network isolation, quarantine from the control plane, also in your account.
Nowhere on that path does a copy of your events route through a vendor's SaaS to get processed. The vendor ships software and updates. Your data does the work where it already lives.
Where the deal usually breaks
Every governance evaluation has a moment where security and infrastructure stop nodding at each other. Security wants the coverage. Infrastructure asks where the data goes. The answer is "out," and for a firm under residency rules or a plain "our data does not leave our account" posture, that answer ends the meeting no matter how good the detection scored.
Single-tenant by default deletes that moment. Infrastructure keeps its hard line: nothing sensitive leaves the account. Security gets the runtime visibility anyway. Nobody trades residency for coverage, because the architecture never set up the trade.
It also keeps you off someone else's target list. A vendor holding movement telemetry from hundreds of customers is a fat target. Your one account is not. When your governance data never pools into the vendor's infrastructure, breaching the vendor does not breach your most sensitive movement data. There is no shared pool to breach.
Five questions that separate the real thing from the label
Read these to any vendor claiming single-tenant. The label survives marketing. These answers do not.
Where does the event become a case? Not where data is "stored," but where the correlation, scoring, and case-writing happen. In your account, or in their cloud?
What crosses the boundary in normal operation? Software updates and license checks are fair. Your events, your metadata, and your findings should not appear on that list. Ask for the list.
Does it survive a severed vendor path? Cut the connection. A real single-tenant deployment keeps seeing data move and keeps writing cases. If it goes dark, the work was happening on the other side of the cut.
Who can read your findings? Single-tenant should mean the vendor cannot browse your cases. Ask what standing access the vendor keeps to the running deployment, and under what conditions.
Does it inherit your account's controls? Your IAM, your keys, your logging, your network boundaries should already apply. Confirm the deployment needs no carve-out that weakens any of them.
A vendor that answers all five cleanly is rare. The answers are not opinions; they are facts about where the code runs.
Governance that demands a copy of your telemetry to watch your telemetry is a contradiction the industry learned to ignore. It is also why a lot of strong detection never reaches the accounts that need it most: the residency objection kills it first.
Single-tenant by default settles the objection up front. The collector runs in your account. The analysis runs in your account. The case is written in your account. The events never leave. Runtime data movement governance, without widening the surface you were trying to protect.
If you want to trace the path host by host, from the kernel event to the written case, and confirm for yourself that nothing crosses the boundary, we can do that in a thirty-minute technical call, engineer to engineer.