A support engineer opens an admin console to fix one customer's broken export. In the next forty minutes that same session reads records across nineteen other tenants. Every read is authorized. The role grants it, the token is valid, the audit log marks all nineteen a success. Nothing fires.
A SaaS platform moves customer data for a living. Data lands in a tenant, replicates to a read replica, fans out to a search index, syncs to the customer's CRM, drops into a support tool when a ticket opens, gets pulled into the analytics warehouse the customer asked for. You built every one of those paths on purpose. That is the product.
So the question a security review actually asks is not which path you forgot to lock. You did not forget. The question is what happens on a path you opened deliberately, used by an access you granted correctly, the day it behaves wrong.
Every move is permitted. The pattern is the breach.
Ask a SaaS vendor how they protect customer data and you get the permitted-access list back: encryption at rest, tenant isolation, scoped tokens, SSO, audit logs. Every item is real. Not one of them answers the thing the customer is afraid of, which is data leaving through an access that was granted correctly.
The damaging events in a multi-tenant platform rarely trip a permission. An integration token that has synced four thousand records a day for a year starts pulling a full export. A replication job that copies one tenant to a search index reaches a path it has never touched. The support session walks nineteen tenants. Each action is allowed. The log records each as a success. A permission check sees one event at a time. The breach is the shape of the sequence, and no permission check sees a shape.
This is where it leaks, and it is the same handful of places on almost every platform.
Shared tooling that reaches every tenant. The admin console, the impersonation feature, the data-fix script exist so your team can help customers, which means they hold the keys to all of them. The normal range of who-reads-what is wide and undocumented, so a read that walks ten customers looks exactly like ten ordinary tickets to your logs.
Integration and export paths. The connectors that make the platform sticky, the CRM sync and the webhook firehose and the warehouse export, are built to move customer data out of your boundary on the customer's behalf. A scoped token is a permission, not a baseline. The token moving ten times its usual volume is still a valid token.
The plumbing customers never see. Replicas, search indexes, caches, ETL jobs shuttle customer data between systems all day. These paths are internal and trusted, which is exactly why an off-pattern read along one of them is the quietest place a problem starts.
The controls you run check permission, not pattern
Each tool you own does its job, and the job is mostly permission. A CSPM tool like Wiz maps your cloud posture and flags a misconfigured bucket or an over-broad IAM role. Run it. It tells you whether a path could be reached, not what crossed the path once it was reached correctly. EDR watches process and endpoint behavior on a host. DLP inspects content against rules at the application boundary and asks whether this upload matches a pattern someone predicted in advance.
Notice what every one of them checks: permitted or not, content matches a rule or it does not, at a single layer. None builds a baseline for the movement of customer data itself, tied to the identity behind each move, read across the support path and the integration path and the replication path at the same time. That layer is where the breach forms. It sits in the seam between the tools you already own.
Watching the movement, at runtime, in your own cloud
This is the seam runtime Data Movement Governance covers. Your bank does not read what you bought to flag the charge that does not fit. Hilt does that for data movement.
Hilt watches data movement at the kernel, metadata only by default, off the path. One lightweight collector runs single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline. It does not stand between customer data and its destination, and it does not block, drop, or alter traffic. It does not read your customers' data to do its work. Content-aware inspection is there when you want it, but the default vantage is metadata, which is the answer most SaaS security and privacy teams have to give their own customers.
Every move resolves to a probabilistic identity: which workload or user, which job behind it, which destination, and whether this fits how that identity moves data. When the support session walks an unusual span of tenants, when the integration token's volume jumps, when the replication job reaches a new path, the deviation shows up across those layers at once. One signal alone is noise. The three together are a pattern, and a pattern is a case, not an alert. When the pattern is dangerous, the response is host-level network isolation, quarantine from the control plane, never an inline filter. Events never leave your account.
The answer that closes the review
A SaaS platform does not just carry this risk. It sells against it. Your enterprise buyers run security reviews and they ask the cross-tenant question, and most vendors answer with the permitted-access list because that is what the stack produces.
There is a second answer. One vendor says every path is permissioned. The next says every path is permissioned, and we watch the pattern across those paths while data moves, resolved to the job behind it, and we can show you the move that did not fit. The second vendor wins the review, because the buyer's real fear was never the lock. It was the read that looked legitimate until you put it next to the eighteen reads around it.
This replaces nothing you run. CSPM covers posture, EDR covers endpoints, DLP covers content rules, and they cover them well. It closes the one layer they were never built for: the behavioral pattern of customer-data movement across the permitted paths you put there yourself.
If you want to see how it reads against your own architecture, the next step is a 30-minute technical call, engineer to engineer, about where customer data actually moves in your platform and what a baseline on those paths would surface.