Log inRequest a demoStart free

Learning center

Platform integrity

How a test data platform proves it behaves as configured — verified policies, at-most-once commands, revocable agents and fail-closed defaults.

Tutorial

Masking rules and certification gates only protect you if the platform actually runs the rules you approved, runs them once, and stops when something is uncertain. Platform integrity is the set of controls that make the platform's own behaviour trustworthy.

It covers questions such as: is this the policy version the data owner approved? Could a command be replayed? What happens if an agent is compromised or the network drops mid-job?

Platform integrity controlsIntegrity controls: versioned agents that can be revoked, policy checksums re-verified by the agent, at-most-once command execution, fail-closed behaviour on uncertain state, and a tamper-evident audit chain.IntegrityVersioned,revocable agentsPolicy checksumsre-verifiedAt-most-oncecommandsFail closed ondoubtTamper-evidentaudit
Platform integrity controls. Integrity controls: versioned agents that can be revoked, policy checksums re-verified by the agent, at-most-once command execution, fail-closed behaviour on uncertain state, and a tamper-evident audit chain.
Text description
  1. Integrity: Versioned, revocable agents → Policy checksums re-verified → At-most-once commands → Fail closed on doubt → Tamper-evident audit

Why it matters

A test data platform sits between sensitive sources and many downstream environments. If an attacker, a bug or a stale configuration could make it run an unapproved policy, the result is unmasked data in QA with a reassuring status next to it. Duplicate execution can provision the same dataset twice or overwrite a newer version. A lost network connection that leaves a half-built dataset published is just as bad. Integrity failures are dangerous precisely because they look like success; controls must make them detectable and, wherever possible, impossible.

Outbound lease modelThe 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.DataNivra CloudQueue declarativecommandGrant time-bound leaseRecord status & auditYour environmentAgent polls for workVerify command &policy checksumExecute locallyReport metadataAgent-initiated HTTPS only; no inbound ports
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
  1. DataNivra Cloud: Queue declarative command → Grant time-bound lease → Record status & audit

    Connection: Agent-initiated HTTPS only; no inbound ports

  2. Your environment: Agent polls for work → Verify command & policy checksum → Execute locally → Report metadata

Example

A synthetic sequence of events for one refresh job:

  1. The control plane issues command cmd-0042 with masking policy version 7 and its checksum, valid until a not_after time.
  2. The agent leases the command and recomputes the policy checksum. It matches, and version 7 is approved and not revoked, so work starts.
  3. The network drops during masking. The agent cannot renew its Lease, so it aborts, cleans its workspace and publishes nothing.
  4. The lease expires and the job returns to the queue. A new attempt receives a new lease; cmd-0042 is recorded as already handled, so it is never executed twice.
  5. Had the checksum not matched, the agent would have rejected the command with a policy-checksum error instead of guessing.

How DataNivra approaches it

  • Verified policies. Commands carry an approved policy snapshot with a checksum. The Agent re-verifies it and rejects unapproved, revoked or mismatched versions.
  • At-most-once execution. Commands have ids and expiry times; stale, duplicate or cross-tenant commands are refused.
  • Revocable identity. Agents use their own key pair and short-lived tokens. Revocation stops all work at the next exchange.
  • Fail closed. Uncertain privacy or integrity state stops the job. Failed or revoked datasets never provision.
  • Tamper evidence. Privileged actions are recorded in a hash-chained audit trail.

Read the agent protocol for the message-level details.

Key takeaways

  • Verify the policy at the point of execution, not only at approval.
  • Make every command single-use and time-bound.
  • When in doubt, stop and publish nothing.