Customer-resident data processing

Customer-resident processing means that every operation touching a row of your data — reading it, profiling it, subsetting, masking, generating, validating and provisioning it — happens inside your own security boundary: your VPC, VNet, cluster or data centre.

The hosted service still has a job. It holds the people and policy side of test data management: who may request what, which policies are approved, what is scheduled, what happened and when. The trick is splitting the product so that the hosted part never needs your rows.

How DataNivra keeps production data in your environment

A three-minute tour of the boundary between the DataNivra control plane and your environment. 3:00

Keyboard: Space or K play/pause, ← → seek 5 s, M mute, C captions.

Narration is not available in this browser. The full transcript is below.

Transcript

In this walkthrough, we will look at one promise and how it is kept. Production data stays in your environment. Let us see what that means in practice.
DataNivra is split into two parts. The control plane is the service we host. It holds your organisation, users and roles, policies and approvals, dataset requests, job status, schedules and the audit trail. The data plane runs inside your own network. It is made up of the DataNivra agent, the test data engine and the industry packs.
Every operation that touches a row happens in the data plane. Connecting to sources, profiling, classification, subsetting, masking, synthesis, validation, certification and provisioning all run next to your data. The hosted service does not even contain the code that processes rows.
The agent connects outward to us, over HTTPS. We never connect inward to you. There are no inbound ports to open and no database to expose. The agent asks for work, receives a time-limited lease for one command, checks it, and runs it locally.
Credentials never travel. Your source and target passwords, and your masking keys, stay in your own secret store. DataNivra configuration only holds a secret reference, such as the name of a vault entry. The agent resolves the value on its own side.
Work is also bounded in time. A lease expires if the agent stops renewing it, and the job returns to the queue. Each command carries its own identifier, so it runs at most once. If the control plane cannot be reached, the agent finishes or stops in-flight work safely, never publishes uncertified output, and waits for a valid lease before starting anything new.
So what does cross the boundary? Only four kinds of information. Control metadata, like job identifiers, states and column names. Aggregate metrics, like row counts and durations. Evidence references, like a checksum and the location of a report that stays with you. And secret references. Raw rows, samples, query results and credentials are prohibited.
That rule is enforced in several layers. Message contracts refuse unclassified or prohibited fields. The agent has an egress guard that inspects every outbound message and blocks anything that looks like raw data. And the control plane validates again on arrival, without echoing what it rejects.
We call this zero raw-production-data egress, and customer-resident processing. Notice that it is not zero copy. The agent does create subsets and masked datasets, but only inside your boundary.
To see the boundary in action, try the synthetic interactive demo, where one panel shows everything the cloud receives.

Voice: Your browser's default speech voice (rendered on your device). Original script © DataNivra. No recorded or third-party audio; speech is synthesized locally by the visitor’s browser.

Control plane and customer-resident data plane. Two zones. The top zone is DataNivra Cloud: public website and console, control-plane API, a metadata and audit store, and the policy registry. The bottom zone is your environment: the DataNivra agent, the TDM engine, your source systems accessed read-only, and your test environments. The agent opens outbound-only HTTPS connections to the cloud and sends only control metadata, aggregate metrics, evidence references and secret references. Raw rows and secret values never cross the boundary.

Text description

DataNivra Cloud: Website & console → Control-plane API → Metadata & audit store → Policy registry & approvals
Connection: Outbound-only HTTPS, started by the agent — Metadata, aggregates, evidence references only. No raw rows, no secrets.
Your environment: DataNivra agent → TDM engine → Source systems (read-only) → DEV / QA / SIT / UAT / PERF targets

Why it matters

Most organisations are comfortable using software-as-a-service for coordination, but not for sending regulated production data to a vendor. Traditional options force a choice: install and operate everything yourself, or ship data to someone else's cloud. Both are costly — one in operational effort, the other in risk, review cycles and contractual complexity. A split architecture removes the dilemma. Security teams can review a small, well-defined boundary instead of a whole vendor platform, and data owners keep physical control of the data they are accountable for.

Outbound lease model. The control plane queues a declarative command and grants a time-bound lease when the agent asks for work. The agent validates the command and the policy checksum, executes locally and reports metadata. The control plane never opens a connection into your network.

Text description

DataNivra Cloud: Queue declarative command → Grant time-bound lease → Record status & audit
Connection: Agent-initiated HTTPS only; no inbound ports
Your environment: Agent polls for work → Verify command & policy checksum → Execute locally → Report metadata

Example

A synthetic walk-through of one dataset request:

A tester asks for a QA dataset of 500 synthetic-scenario members in the control plane.
The control plane records the request and queues a declarative command: which subset definition, which approved masking policy version, which target environment.
The Agent in the customer network, which only ever connects outbound, polls for work and receives a time-bound Lease.
The agent verifies the policy checksum, reads the source read-only, builds, masks and certifies the dataset, and provisions it to QA.
It reports back job state, row counts, durations and a checksum of the certification report — nothing else.

At no point does the control plane open a connection into the customer network or receive a row.

How DataNivra approaches it

DataNivra is built as two planes. The data plane — agent, engine and industry packs — is deployed in your environment. The control plane is hosted and stores metadata only. The control-plane code base cannot even import the engine or connectors; an automated architecture test enforces that, so the hosted service is structurally unable to process rows.

Connectivity is outbound-only HTTPS from the agent. Credentials are configured as secret references resolved locally. If the control plane is unreachable, the agent finishes or aborts safely and never publishes uncertified output. Read the architecture overview and the agent protocol for the full picture.

Questions a security review should ask

Which component touches rows, and where does it run? Only the agent and engine, inside your network.
What network access does the agent need? Outbound HTTPS to the control plane; no inbound ports, no VPN, no vendor access to your databases.
What exactly leaves? Identifiers, counts, ratios, gate outcomes, checksums and secret references. Small counts in discovery reports are raised to a floor so they cannot reveal tiny tables. Rows, samples, credentials and keys never leave.
How is that enforced? Classified message contracts, an egress guard in the agent that checks every outbound message, and the same checks again at the control plane's ingress.
What happens if the hosted service is unavailable? The agent keeps its local state, queues value-free reports and resumes when the control plane returns; it never falls back to sending more data.
Can we verify it ourselves? Yes: plant synthetic canary values, run a job, and search everything the control plane shows for them; inspect traffic through your own proxy.

The trust page describes these verification procedures, and the documentation covers deployment. See which sources the agent can read on the integrations page, browse the guides, use the free tools, or start free with the synthetic sandbox before installing anything.

Key takeaways

Row-level work lives where the data lives.
The hosted service coordinates with metadata and never dials in.
The boundary is enforced in code, not just in documentation.

Tutorial

Why it matters

Example

How DataNivra approaches it

Questions a security review should ask

Key takeaways