Customer-resident processing — verify the agent you run

Use case

DataNivra splits test data management in two. The hosted control plane holds policies, approvals, schedules, metadata and evidence references. Everything that touches a row — reading the source, subsetting, masking, generating, validating and writing the result — runs in an agent you deploy inside your own network, which connects outbound to the control plane and never accepts inbound connections. That design moves the trust question: instead of "what does the vendor do with our data?", a security team asks "is the agent we run exactly the one that was published, and what can it reach?" This page answers the first half with a check anyone can run.

The scenario

A platform security engineer must approve the agent before it is installed in the network segment that can reach the claims database. Their checklist: the files come from the published release; the Helm values deploy the exact image that release built, pinned by digest rather than by a movable tag; the release names the build that produced it; and nothing in the deployment files carries a credential. The cryptographic signature check with cosign is a second step on the same files, documented in the release notes.

Run it

Python 3.10 or later, standard library only. It downloads four small files of agent release 0.3.0 from the website.

import hashlib
import json
import os
import urllib.request

BASE = os.environ.get("DATANIVRA_DOWNLOADS", "https://www.datanivra.com/downloads")
RELEASE = f"{BASE}/agent/0.3.0"
FILES = ["release-manifest.json", "datanivra-agent-0.3.0-helm-values.yaml", "RELEASE_NOTES.md"]


def fetch(name):
    with urllib.request.urlopen(f"{RELEASE}/{name}") as response:
        return response.read()


sums = dict(
    reversed(line.split("  ", 1)) for line in fetch("SHA256SUMS").decode("utf-8").splitlines() if line
)
for name in FILES:
    ok = hashlib.sha256(fetch(name)).hexdigest() == sums[name]
    print(f"{name}: {'OK' if ok else 'MISMATCH'}")
    if not ok:
        raise SystemExit(1)

manifest = json.loads(fetch("release-manifest.json"))
values = fetch("datanivra-agent-0.3.0-helm-values.yaml").decode("utf-8")
pinned = next(line.split(":", 1)[1].strip() for line in values.splitlines() if "digest:" in line)
print("version:", manifest["version"], "| platforms:", ", ".join(manifest["platforms"]))
print("image pinned by digest in the Helm values:", pinned == manifest["image_digest"])
print("built by:", manifest["certificate_identity"].split("/.github/")[1])
print(
    "credential keys in the Helm values:", any(k in values.lower() for k in ("token:", "password", "secret:"))
)

Expected output

release-manifest.json: OK
datanivra-agent-0.3.0-helm-values.yaml: OK
RELEASE_NOTES.md: OK
version: 0.3.0 | platforms: linux/amd64, linux/arm64
image pinned by digest in the Helm values: True
built by: workflows/release-agent.yml@refs/tags/agent-v0.3.0
credential keys in the Helm values: False

The release ships no enrollment token or password: an agent is enrolled with a one-time token created in the console, and every credential it uses afterwards is a reference into your own secret store.

Schema

What DataNivra does with your own data

The agent runs where your data is. It reads sources with credentials resolved locally from your secret store, performs every row-level step in memory or in storage you control, and writes datasets that passed its configured policy gates (DataNivra-certified) only to targets you registered. What crosses the boundary to the hosted control plane is classified field by field — control metadata, aggregate metrics, evidence metadata and secret references — and fields classified as raw data are refused by the contract models before anything is sent. The result is zero raw-production-data egress by design, with egress alerts and certification gates that fail closed when the boundary is not respected. Certification here means DataNivra-certified against configured policy gates; it is not a regulatory or third-party certification and does not make a system compliant with any regulation.

Limits to plan around

• A checksum match proves integrity against the published list, not who published it. Verify SHA256SUMS with its cosign bundle and the image signature with cosign verify, as the release notes show, before trusting either.
• The script checks three files; the release also contains packages, SBOMs and provenance attestations you should verify in the same way when you install from them.
• Customer-resident processing does not remove the need for your own controls: network policy around the agent, least-privilege source roles and review of the policies it executes remain your responsibility.

Next steps

Read customer-resident data processing and zero raw-production-data egress, then look at the agent packages on the downloads page.