Security isn't a feature here. It's the architecture.
This page is for the reviewer with the checklist. Every claim below maps to a concrete architectural fact, not a marketing adjective.
The most secure data is the data you never copied.
Because the platform leaves data at the source and persists nothing on disk, there's no second copy to breach, no extra store to govern and audit, and a markedly smaller attack surface. Less physical persistence is itself a security and governance control — and it shrinks compliance scope along with it. Everything below is how that architecture holds up to scrutiny.
See the system architectureIdentity chain
Entra ID → platform → auth translation → source. Every query runs as the actual user. Sign-in is via Microsoft Entra ID; the Agent translates that identity to whatever the source speaks — SAP Logon Ticket, SAML or legacy credentials — so existing source-system permissions do the filtering, end to end.
Roles & access model
- Privileged roles (VDP_ADMIN, VDP_ENTERPRISE_CREATOR) are assigned in your own Entra ID via the Virtual Data Platform Enterprise Application — standard app-role assignment, auditable there, with joiner/mover/leaver processes applying automatically.
- VDP_User and VDP_Creator licenses are managed by the admin in the Portal's License Management.
- Workspace read access is controlled through existing Entra ID groups — no parallel permission system.
Sandbox isolation
Each user gets a per-user, container-level, ephemeral sandbox. A high-performance secure in-memory database executes Models — combined data exists only in memory inside the user's sandbox, never on disk, and is destroyed after use.
Encryption model
TLS protects every connection, with hybrid payload encryption on top. The client generates an RSA-OAEP key pair (2048-bit, SHA-256) locally and sends only the public key — relayed via the user's sandbox — to the Agent. Payloads are encrypted with AES; the AES key is protected with the client's public key, and the private key never leaves the client.
Client-side key generation applies to the end-to-end-capable clients — Web Portal, Excel add-in, R and Python. TDS, OData and MCP clients connect via TLS, with the Agent → sandbox leg payload-encrypted regardless.
The decryption key is generated in your client and never leaves it; everything in between — including our routing and relay infrastructure — only ever sees ciphertext.
Key flow
The client's public key travels client → sandbox → Agent. The private key stays on the client.
What the platform sees — and cannot see
Sees
- Routing metadata
- Dataset identifiers
Cannot decrypt
- Payload data anywhere outside the user's own sandbox
Network model
Agents connect outbound only; the platform never reaches into customer networks, and no source data is held at rest on the platform. Every customer connects via their own per-tenant endpoint — yourtenant.eu01.virtualdataplatform.com — a visible isolation signal; only the Portal is central (portal.virtualdataplatform.com, requires a tenant).
Virtual Data Platform Dedicated
deployment tierFor the strictest environments: a dedicated backend cluster instead of the (still secure) shared multitenant environment, plus private networking via Azure Private Endpoints — no traffic over the public internet.
Compliance posture
GDPR-aligned, hosted in the EU on Microsoft Azure. We make no certification claims today and lean on the architectural facts instead; this section will be revisited as ISO 27001 / SOC 2 land.
For security reviewers
Nowhere on the platform. Results exist only in memory inside the requesting user's ephemeral sandbox and are destroyed after use.
See your own data live in 30 minutes.
Start with a live demo — we'll show your use case in Excel, Power BI, R, or through an AI assistant. Then take it further with a free trial in your own isolated tenant.