Isolation

Least privilege applied to test scripts and environments.

Control scripts and protocols the client provides — whether a homegrown Test Pack, one adapted from a RestorSignal template, or even one partly generated by an LLM — are treated as untrusted code as a matter of principle. This caution is not a question of trust toward the client: it is standard security hygiene applied to any code executed inside a shared environment.

What the sandbox does not grant by default

By default, a client script has access to none of the following:

• root access to the host machine;
• the Docker socket;
• the underlying cloud provider's metadata service;
• outbound Internet access;
• secrets belonging to other tenants;
• data or results from other jobs, running or past.

Each of these restrictions closes off a classic escape route out of an isolated test environment. A script that genuinely needs a capability outside this default perimeter must explicitly request it, evaluated case by case — access is never opened implicitly.

Secrets are injected temporarily

When a test needs a secret — a database password, an application API key — it is injected right before it is used, for exactly as long as the relevant control requires. That secret must never appear in the Test Pack itself, in the produced report, in the normalized result sent onward, or in the data received by RestorSignal's central API. This rule applies regardless of the execution mode.

The produced result is not automatically trusted either

Since the restored artifact is by nature an uncontrolled input, what it produces is too. A test's technical result is validated against a strict schema before it ever enters the evidence package: bounded fields, no arbitrary text from the restored engine copied through verbatim, no business data extracted from the backup. Coming from the intended execution component never exempts a result from that validation.

The general principle: least privilege

All of these rules follow from a single principle: a test script should have only the access strictly necessary to run the controls it was designed for, nothing more. This principle applies the same way in Local mode and in a disposable environment. In the latter mode, isolation is reinforced by one additional element: the entire environment, with everything it contains, is destroyed once the test ends — see Disposable environment for the detail of the destruction process and its limits.