Tutorial
Zero raw-production-data egress is a narrow, testable promise: raw production values never leave your environment for the DataNivra control plane. Not in messages, not in logs, not in error reports, not in metering or support bundles.
It is deliberately not “zero copy”. Test data management creates copies by definition — subsets, masked datasets, synthetic datasets. Those copies exist inside your boundary, in the environments you choose. What never happens is raw data flowing out.
Text description
- Your environment: Engine output (rows stay local) → Report builder (metadata only) → EgressGuard: schema + content checks
Connection: Allowed: metadata, aggregates, evidence & secret references — Blocked: rows, samples, credentials
- DataNivra Cloud: Ingress validation → Metadata store & audit
Why it matters
Privacy promises are only useful when they are precise enough to verify. A vague claim invites misunderstanding: a security reviewer who reads a bolder slogan may assume no copies exist anywhere, then discover masked subsets in QA and lose trust in everything else. A precise claim can be tested: you can inspect the message schemas, watch the network traffic and scan the vendor's stores for known canary values. It also shapes engineering. When every field that crosses the boundary must be classified, accidental leaks through a debug field or a verbose error message become build failures instead of incidents.
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
Example
Consider a synthetic discovery report for a table of invented member records.
| Field in the report | Class | Crosses the boundary? |
|---|---|---|
table: members, column: email | control metadata | yes |
null_ratio: 0.02, row_count: 48210 | aggregate metric | yes |
report_sha256: 9f1c… | evidence metadata | yes |
vault://secret/tdm#reader | secret reference | yes (the name only) |
a sample value such as jordan.b@example.test | raw data | never |
If a developer added a sample_values field to that report, the contract would refuse to build the model; if a value slipped into a text field, the egress guard would block the message and log the violation locally without the payload.
How DataNivra approaches it
Enforcement is layered:
- Contracts. Every field of every cross-boundary message is classified. Prohibited raw data cannot be declared on a message model or serialized into one, and unknown keys are rejected.
- Egress guard. The agent checks each outbound message against allow-listed schemas and content detectors for things like emails, card numbers and long free text, and fails closed.
- Ingress validation. The control plane validates the same contracts again and rejects anything non-conforming without echoing it.
- Architecture. Hosted code cannot import the engine or connectors.
- Verification. End-to-end tests seed synthetic canary values and check they never appear in control-plane storage, logs or responses.
Credentials travel only as secret references. See Security and the raw-data egress runbook.
Key takeaways
- The promise is about egress, not about copies inside your boundary.
- Classification makes the promise checkable field by field.
- Both sides validate; neither trusts the other blindly.