Isolated execution

What it is

Your DataNivra agent already keeps production rows inside your network. Isolated execution adds an operating-system boundary inside the agent host: every stage that reads or transforms rows — discovery profiling and classification, subsetting, masking, synthesis, validation and provisioning — runs in its own fresh, short-lived worker instead of the agent process.

A worker sees only what its stage needs:

• the stage's input (read-only) and its output directory;
• this job's own connection details, for the stages that read a source or write a target;
• the pseudonymization keys this job's masking policy names, at the versions it names, one request at a time.

It never sees the agent's identity key, its control-plane token, your secret store, other jobs, the container runtime, or — for stages that need no source or target — any network.

The agent stays in charge of everything else: leases, checkpoints, certification, publication and reporting work exactly as before, and published data is byte-for-byte the same as without isolation.

Choose a level

gVisor and Firecracker both keep a stage's system calls away from the host kernel, by different means; if your policy needs one specifically, name it.

Turn it on for an agent

# on the agent host, after pulling the agent image by digest
export DATANIVRA_AGENT_ISOLATION_BACKEND=OCI          # or GVISOR, FIRECRACKER
export DATANIVRA_AGENT_ISOLATION_IMAGE=ghcr.io/manuelbomi/datanivra-agent@sha256:<digest>
export DATANIVRA_AGENT_ISOLATION_SOURCE_NETWORK=dn-sources   # only if stages read network sources
datanivra-agent isolation doctor                       # every check must pass

Restart the agent. While its runtime check passes, it advertises the backend to the control plane; datanivra-agent isolation status shows recent stage outcomes, start-up times and any running workers.

Require it for your organization

Organization administrators set a minimum in Organization → Execution isolation, with the CLI (datanivra org isolation-update --min-isolation CONTAINER), or through the API (PATCH /v1/organization/execution-isolation). Every change is audited.

• Jobs are sent only to agents whose isolation meets the minimum; any other agent never receives them, and the job reports AGENT_ISOLATION_UNSUPPORTED.
• Requests from the console, API, SDKs, CLI (--min-isolation), MCP clients and CI pipelines can ask for more isolation, never less.
• The requirement travels inside the signed job command, and the agent checks it again before it opens a source. A job is never run with weaker isolation than required.

Good to know

• Preview. Isolated execution is opt-in; Standard stays the default for every installation. Readiness per backend and the test evidence are published with the security documentation.
• Start-up cost. Each isolated stage starts a fresh worker, which adds about two seconds per stage; row processing itself runs at the usual speed.
• Where it runs. Per-stage isolation needs a Linux host with a container runtime (or KVM for Firecracker). On Kubernetes you can run the whole agent pod under a sandboxed runtime instead (runtimeClassName, for example GKE Sandbox).
• Firecracker microVMs have no network: use it with file sources and directory targets; use OCI or gVisor for network sources and targets.
• Compliance-guard scans and document-set builds keep running in the agent process for now, so an agent with an isolation backend does not offer them, and they are refused whenever an isolation minimum applies — never run unisolated. Run them on an agent with the Standard backend.

Every isolation code (ISOLATION_*, ISOLATED_*) has an entry with its fix in the support center.

← All documentation