The shortest version: a run happens in a container with no route off the host, and the internet-facing process cannot start containers. The engine needs no network while it runs, which is what lets the hosted service give a run none. That is a property of a hosted run — it is not a private deployment, which does not exist yet.
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 | Original uploads are deleted after 30 days. Reports, models and predictions are kept until deleted. De-identified data may be retained for 18 months or more for model improvement, training and quality assurance. 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. Separately, de-identified data derived from uploads may be retained for model improvement, training and quality assurance under the data policy. This does not make the original uploaded dataset public.
If hosted is the wrong answer
For a lot of reviews it is, and we would rather you found that out here than three weeks into an evaluation. Be exact about what runs today, because this table used to describe an air-gapped enterprise build as a supported configuration and it is not one yet:
| Hosted preview | The free Research Preview at https://cloud.veox.ai. Your table is uploaded, the search runs on our hardware, and the isolation described above is what stands between one run and another. |
|---|---|
| Local workspace | The same workspace in Docker on your machine, bound to localhost. The interface is local; the search still runs on our hardware, so the table is still uploaded. It is not an offline mode — running locally says so on the page that installs it. |
| Private deployment | Designed, not shipped. Your VPC, your Kubernetes, on-prem or fully air-gapped, with no telemetry, the search on your own cluster, and per-deployment licensing. None of that is available, priced or scheduled here; it comes after the preview earns it. |
| Yours either way | The winning model exports as code and weights you own and deploy, with no runtime dependency on us. That does not wait on a deployment path. |
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. The fastest path right now is the hosted preview on a dataset you are already allowed to share: the deployment that would shorten your questionnaire is the one we have not built.
Reporting something
Email support@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.