Every analytics vendor says your data is isolated. It's the one claim a customer can almost never verify, so it's the one worth proving instead of asserting.

Event Horizon Data is multi-tenant: many customers' data lives in shared infrastructure, and the entire product's value rests on one customer never seeing another's rows. Here's how that holds, in the specific, and more importantly where you can check it yourself.

Two layers, not one

Isolation is enforced twice, deliberately. The two layers are not equal, though, and the useful thing to tell you is which one carries the weight.

The application choke-point. Every read that puts data in front of someone passes through one function that refuses, fail-closed, any query that does not carry the authenticated tenant's own scope. A read that cannot name whose data it is asking for does not compile. There is no code path around it.
The database row policy. Beneath that, the engine itself confines every read to the tenant's rows through a row policy the query runs under. This is a second layer, and it is not an independent one. The read identity has to be able to receive its tenant context on each request, and that is the same door an in-query override would use, which is precisely what our own red-team found and what we then closed at the checkpoint above. So the row policy raises the bar underneath the application layer rather than standing on its own, and the checkpoint is the control we ask you to judge us on.

The read connection is least-privilege by construction: it cannot read the server's own tables, cannot reach external systems, and cannot write. Crossing a tenant boundary would require writing a new database client, not forgetting an argument.

We red-team our own isolation, and publish it

Claims age badly. So we run an adversarial test of the tenant boundary against the live system, try to defeat it the ways an attacker would, and write down what we found, including the honest limits. We do it again whenever a surface is new: the SQL editor and the notebook API were attacked the day after they shipped, in their own run. Between the two most recent runs, seven findings, all closed the same day they were found, and none of them a way to read another customer's data. That report, the scale measurements, and a pre-filled security questionnaire live on our public security page. Read it before you trust us, not after.

That's the whole posture: check, don't just trust.

The new surfaces got the same treatment

We recently shipped two ways to run your own SQL over your data: an in-app SQL editor, and an HTTP API for notebooks (Python/R/Jupyter). Both were built to the same boundary:

You write SQL against your logical tables, blind to how the warehouse actually stores things. Your text never runs as-is: it is parsed, validated, and rebuilt on the server, always locked to your tenant.
Every query is cost-checked before it runs (like BigQuery's dry-run): one that would read too much is refused up front, with the estimate shown. Time, memory, join size and the number of tables joined are capped on top of that, and ad-hoc SQL yields to dashboards, so a heavy query degrades itself rather than the warehouse.
The notebook API authenticates with a revocable token, which can be given an expiry date; the tenant is taken from the token, never from the request. A token for one account cannot ask for another's data, and the test that proves it fails the build if that ever changes.

What we don't pretend

We're a small team, not a hundred-person org with a SOC 2 wall. We say so. What we offer instead is an interim assurance package boutique customers actually accept: the published red-team, a scale report, a DPA, a sub-processor list, and a business-continuity plan (backups, scripted restore, data export on exit), plus a founder on the other end of the line. SOC 2 comes when demand justifies it.

If you evaluate vendors on whether their security claims are checkable, start at the security page. The longer architectural argument is in the whitepaper.