A sandbox, a target network and sovereign inference: three boundaries to review

Sources checked: 2 November 2026. FailSafe Research.

“The agent runs in a sandbox” answers an important question about local execution. An enterprise buyer still needs to know which systems the assessment can affect, and where its prompts, evidence and model processing travel.

A useful architecture review separates three boundaries: the runner that executes the agent’s work, the network around the target being tested, and the services that process assessment data. Treating them separately makes the safety argument easier to inspect.

Boundary one: the agent’s runtime

FailSafe’s agent-safety addendum describes unprivileged agents running in ephemeral sandboxes without ambient credentials. The local context is deliberately limited and short-lived. This reduces the authority available in that execution environment.

That statement should be read precisely. A sandbox does not demonstrate that every proposed action is permitted, and a credential-less runtime does not mean an authenticated assessment needs no target credentials. Test access must still be explicitly scoped and handled according to the engagement’s terms.

The execution gate addresses another part of this boundary by checking proposed commands and request content. Safe mode restricts recognized destructive operations and configured mutations. Those checks complement the runtime isolation.

Boundary two: the target’s network

Once a vulnerability causes execution on a target, the relevant network context can change. The target may have access to databases, internal services or external destinations that the runner does not. A boundary drawn around the runner cannot establish the restrictions on those target-side actions.

This is why FailSafe’s documented Cyber mode requires an isolated target with hard egress restrictions. Broader exploit validation belongs in an environment where those consequences have been considered and constrained. The execution sandbox does not itself restrict the target’s outbound traffic.

Before the run, identify the services the target must reach and the paths it must be unable to reach. Use approved verification methods and a representative environment to establish the chosen boundary. Preserve the environment configuration with the assessment record so later results can be interpreted correctly.

Boundary three: the model and evidence path

Assessment data can include source context, application behavior and findings that reveal sensitive business logic. A storage region alone does not explain where a model processes that material, what operational telemetry is produced, or how support access works.

FailSafe offers managed SaaS and sovereign deployment options. A fully local configuration can keep sensitive workloads, model processing and evidence inside the enterprise environment, with no external model calls in that configuration. Agree the complete design, including egress, telemetry, updates, support access and fallback behavior.

Customer assessment data is not used for model training or fine-tuning by default. Any such use requires explicit customer permission. Retention and deletion still need to be confirmed for the selected deployment.

Ask for three distinct demonstrations

• Execution: show the agent’s permissions and how a prohibited proposed action is rejected.
• Target containment: establish that the isolated validation environment has the agreed permitted and denied network paths.
• Data processing: review where inference and evidence handling take place, including any operational dependencies.

These are acceptance questions for a proposed configuration. They should produce concrete evidence and a list of limitations. Neither local inference nor a sandbox grants authorization to test another system.

Build the review around the deployment you will use

For a bank, government agency or critical infrastructure operator, the relevant decision is whether the complete assessment respects its environment and data requirements. Request a configuration review against those requirements rather than treating a general product label as approval.

The Trust Center explains FailSafe’s documented execution safeguards. The sovereign hosting page covers deployment options, and the production-readiness guide turns these boundaries into an assessment checklist.

Basis: FailSafe’s agent-safety addendum and first-party deployment documentation. The three-boundary review is FailSafe’s explanatory framework, published 2 November 2026; it is not an independent certification or a claim that all configurations provide the same isolation.