The single biggest objection we hear from enterprise buyers is some version of: 'does this touch our production database?' The answer needs to be an unambiguous no, and the architecture needs to prove it, not just promise it.
Every Monstral sandbox runs in an ephemeral Tier-3 microVM with no network path to production credentials. When a buyer starts a session, we clone a synthetic seed dataset — thousands of realistic-looking records generated from anonymized schemas — into a fresh container that lives for the duration of the session and is destroyed afterward.
Generating that seed dataset is the part that looks simple from the outside and isn't. We don't copy real customer rows and scrub them — masking always leaks something, whether it's a name format, a referral pattern, or a numeric distribution that gives away real usage. Instead we model the shape of a schema — field types, foreign-key relationships, realistic value ranges — and generate fresh synthetic records from that model. The result looks like a real account because it follows the same structural rules a real account would, not because it's a disguised copy of one.
Session teardown is enforced at the infrastructure layer, not the application layer. When a sandbox session ends — whether the buyer closes the tab, the session times out, or they finish the guided tour — the microVM is terminated and its storage volume is discarded, not reset or archived. There's no "soft delete" step where a stale sandbox could be resumed with its data intact. If something goes wrong upstream of that boundary, there's nothing left downstream for it to expose.
This gives us two things at once: realism, because the data looks and behaves like a real account with real edge cases, and safety, because there is no code path that lets a sandbox read or write anything outside its own memory space.
We get asked why we didn't just stand up a shared staging environment instead. The honest answer is that shared staging is exactly the failure mode we're trying to avoid — one environment, reused across many prospects, accumulates real-looking state over time, and eventually someone forgets which parts of it were supposed to be fake. Per-session, per-tenant isolation is more infrastructure to run, but it means there is never a "shared" anything for a mistake to propagate through.
Every sandbox action is written to an append-only audit log that's separate from the sandbox itself — so even though the sandbox's own storage disappears at teardown, we retain a record of what happened during the session (which screens were viewed, which features were tested) without retaining any of the synthetic data that was on screen. That log is what actually powers the buyer-intent analysis we've written about separately.
We've published a deeper security overview in our trust center, but the short version is: the sandbox can't leak what it was never given access to.