The shortest version: a run happens in a container with no route off the host, the internet-facing process cannot start containers, and the whole product is proven to run with no network at all — which is why the hosted version can afford to give a run none.
Isolation of a hosted run
| Egress | Each session gets its own internal bridge: no gateway, no NAT, no published port. The container cannot resolve a name or open a connection. The host can reach it; nothing else can, in either direction. |
|---|---|
| Tenancy | One container per session, destroyed after capture. No container is reused across sessions or accounts. |
| Privilege split | The internet-facing API never holds the Docker socket. Starting containers is a separate process with no public listener, so a flaw in the request path cannot become container control on the host. |
| Reaching your container | Every request is authorised against session ownership before it is proxied. An admin acting as your account is refused: impersonation exists to debug an account, not to read the data inside its workspace. |
| Container credentials | Each container is issued a fresh random access token that the proxy injects. The container is never exposed with its authentication disabled. |
| Sessions | A __Host--prefixed, SameSite=Lax cookie, plus a CSRF token on every state-changing request. Sign-in is a single-use emailed link that answers identically whether or not the address has an account. |
| Retention | 30 days for uploads and everything derived from them, then automatic deletion. Details on the your data page. |
What we can see
Operationally: that a run happened, for which account, how long it took, and whether it failed. We do not read your dataset, and results are not used to train anything shared. The hosted service exists so you do not have to run the appliance yourself — not so we can look at what you ran.
If hosted is the wrong answer
For a lot of reviews it is, and we would rather you deploy it yourself than run a pilot on data your policy does not allow to leave. The same container ships to you:
| Where | Your VPC, your Kubernetes, on-prem, or fully air-gapped. We do not hold your data. |
|---|---|
| Telemetry | None in the enterprise build. It is proven to run with no network, which is what makes air-gapped a supported configuration rather than an accident. |
| Compute | Search runs on your cluster, under your quota, with budget caps and scheduling you set. |
| Licensing | Per-deployment, not per-seat. Models the search finds are yours, with no runtime dependency on us. |
Being straight about maturity
We are a small company and this page describes engineering, not certification. If your review needs a completed questionnaire, a named audit, or a signed DPA, ask — we will tell you what exists today rather than imply more than there is. For most reviewers the fastest path is the air-gapped build, where most of the questionnaire stops applying.
Reporting something
Email hello@veox.ai with "security" in the subject. We will acknowledge it, and we will not argue with you about whether it counts before we have looked.