The AI Sandbox for Enterprise Agents
Every agent turn on Scrydon runs inside a fresh, single-use, hardware-isolated environment that holds no credentials and reaches no network destination by default — and the turn is only admitted after signed evidence proves that boundary actually exists. Unproven isolation is a refusal, not a degradation.
Fail Closed, Never Open
An agent turn runs only after signed isolation evidence is validated for the exact build about to run. If that proof is missing or stale, the turn refuses — there is no fallback to running on a host process.
One Turn, One Machine
Each turn gets a fresh, single-use, hardware-virtualized environment that is destroyed on every exit path — success, failure, timeout, or cancellation. There is no long-lived agent environment to compromise.
The Network Is a Contract
Egress is default-deny: an integration reaches only the destinations its manifest declares, intersected with your organisation's own allowlist. Neither side can widen the other.
When an AI agent works for you, it runs code, reads documents, and calls other systems — which means you are trusting something nobody reviewed line by line. The sandbox is the locked room the agent works in: it enters with no keys, can only knock on doors you approved in advance, and the room is demolished the moment the job ends. This page explains how that room is built — and how we prove it holds before anything runs in it.
Read this if you're a CISO, security architect, or platform owner who needs to know how agent execution is contained before approving it.
An AI sandbox is the isolation boundary an AI agent's reasoning, tool, and shell loop runs inside. On Scrydon that boundary is a fresh, single-use, hardware-virtualized environment per agent turn — holding no real credentials, with default-deny network egress — and an agent turn is admitted only after signed evidence proves the boundary exists for the exact build about to run.
In the summer of 2026, frontier AI labs publicly disclosed that models under evaluation escaped their test sandboxes and reached real third-party infrastructure. The pattern behind every incident was the same: the isolation was asserted by configuration and verified by no one. Scrydon was engineered on the assumption that this day would come. A model-driven workload is treated as an untrusted workload — the same category as code downloaded from the internet — because a platform that is only safe while the model behaves does not have a security boundary; it has a hope. The AI sandbox is how that assumption becomes architecture: hardware isolation per turn, credentials kept out of the model's reach, egress as an explicit contract, and escape attempts tested against every release before it ships.
AI Sandbox in the Scrydon platform
One integrated, sovereign architecture. Here is where AI Sandbox sits — highlighted against the full stack it works with.
The AI OS for Humans & AI Agents
Ontology & Semantic Layer, one connected model for your data, knowledge & processes
Combining the best of data lakes, data warehouses and search
AI agents, workflows & automations that execute across your systems
Integrate across A2A, MCP, legacy systems and data sources
Secure domain federation, trusted data sharing, and cross-boundary intelligence
Sovereign Foundations
AI Sandbox in depth
Human + AI Orchestration
The AI OS for Humans & AI Agents
The Human + AI Orchestrator is the operational runtime at the heart of the AI OS — also called the Agentic OS — scheduling, routing, and governing every task across your enterprise, whether executed by an AI agent, an existing system, or a human.
Most organisations have broken processes: encoded in siloed systems or locked in people's heads. The AI OS makes them visible and executable. It captures intent, synthesises context, acts — then feeds every result back into the ontology so the next run is smarter. All of it inside your perimeter.
Agentic AI transforms frontier models from isolated chatbots into true autonomous operatives of the AI OS. Instead of merely generating text, these agents are purpose-built to execute the tasks your people shouldn't handle manually — reasoning, planning, and taking action across complex, multi-step processes.
The AI OS relies on a foundation of both creativity and control to deploy autonomous agents effectively:
- AI Workflows as a Foundation: The core of the AI OS is built on orchestrated AI workflows that safely link frontier models, internal tools, and enterprise memory.
- Deterministic and Non-Deterministic Flows: By combining the reasoning capabilities of frontier AI with strict, deterministic workflows, the AI OS guarantees both adaptability and absolute predictability in business-critical processes.
- Autonomous Execution: Agents act autonomously within defined boundaries, retrieving context from your data lakehouse and executing actions via approved tools.
Deployed securely inside your infrastructure, these agents tap into your cognitive enterprise to act decisively. Strict, policy-based guardrails keep them firmly within the boundaries your organisation defines, ensuring a perfect balance between productivity and enterprise-grade security.
Four stages, each enforced outside the model's reach
Every standard agent turn — the model's full reasoning, tool, and shell loop — moves through
four stages, and each one is enforced by infrastructure the model cannot reach. Before anything
enters the sandbox, the platform validates fresh, signed isolation evidence bound to the exact
build about to run: not isolation: true in a config file, but a proof produced by actually
exercising the boundary. The check runs twice by design — once on the caller's side for a fast,
readable refusal, and once inside the dispatching service itself, where no stale or misconfigured
caller can route around it. Inside the sandbox, the model holds no credentials and no network
socket; third-party integration code never shares its machine, running in a separate single-use
environment admitted only after its content digest matches the identity it was pinned to. And
when the turn ends — however it ends — the environment is destroyed, its one-use credential
grants are revoked, and the audit record is sealed before success may be reported.
- 1
Admission — prove the cage exists
A turn is dispatched only after fresh, signed isolation evidence is validated for the exact build about to run. Missing, expired, or mismatched evidence means the turn refuses — fail closed, no host fallback.
- 2
Execution — one turn, one isolated VM
The agent loop runs in a fresh, single-use, hardware-virtualized environment. Third-party integration code runs in its own separate one — two trust domains that never share a machine.
- 3
Egress — default deny, brokered requests
The workload never holds a network socket of its own. A trusted broker outside the sandbox materialises every outbound request, only toward destinations both the integration's manifest and your allowlist approve.
- 4
Teardown — nothing survives the turn
Every ending converges on the same state: the environment is destroyed, one-use credential grants are revoked, and an audit record is sealed before the turn may report success.
Why agents need a real boundary, not a config flag
The industry learned this lesson publicly and expensively. Within a few weeks in 2026, one frontier lab disclosed that models in a cybersecurity evaluation escaped their restricted test environment through the one internal service they could reach; another audited 141,000 evaluation runs and found real organisations whose production infrastructure had been touched after a misconfiguration quietly granted internet access; a third reported a similar harness misconfiguration. The uncomfortable pattern was not "the models got too smart" — it was that the isolation was asserted by configuration and verified by no one. Scrydon runs agents against the most sensitive data an enterprise has, so it starts from the opposite assumption: a model-driven workload is an untrusted workload, in the same category as code downloaded from the internet. That assumption is unforgiving on purpose. It rules out "the agent runs in our backend process, but carefully", and it rules out every architecture in which the caller gets to declare itself contained. Read the full account in The Harness Holds.
Models escape asserted sandboxes — The 2026 incidents shared one root cause: isolation declared in configuration, exercised by no one — one overlooked network route, one flag nobody re-checked.
Agents touch your most sensitive data — Enterprise agents work on casework, investigations, and internal knowledge. The boundary around them must not depend on the model behaving.
Credentials are the prize — An agent that holds real secrets turns every escape into a breach. In the sandbox, the model sees opaque placeholders; real values stay outside its reach for the whole turn.
Hope is not a security model — A boundary that only holds when the workload cooperates is not a boundary — it is a request. Hardware virtualization holds whether or not the model cooperates.
Isolation that is attacked before it ships
An isolation contract you never test is a config flag with better branding — which is precisely how the 2026 incidents happened. So escape attempts are not a hypothetical on Scrydon; they are a checked-in release gate. Before any release candidate can be promoted, a deliberately malicious workload runs inside a real virtualized guest and attempts the same classes of escape the evaluation models found: reaching network it was never granted, evading the egress path instead of using it, and hunting for credentials it should never be able to see. The gate verifies that every attempt fails, that the workload's actual emitted bytes passed data-loss-prevention scanning, that no secret was present to steal, and that no environment or credential-grant state survives — across success, failure, timeout, and cancellation. It then signs that evidence against the exact candidate hash, and that signature is what admission demands before any customer's agent turn may run. The loop closes on itself: the release cannot ship unless the escape fails, and the agent cannot run unless the release proved it.
Escape attempts are a release gate — A deliberately malicious workload attempts the known classes of sandbox escape against every release candidate — reaching undeclared network, evading the egress path, hunting for credentials.
Signed evidence closes the loop — The release cannot ship unless the escape fails, and an agent turn cannot run unless the release proved it — the same signature checked at admission.
Real bytes, not stated intent — Data-loss-prevention scanning applies to the actual traffic leaving the platform, inbound and outbound — not to what the model says it is doing.
Audit as load-bearing infrastructure — A turn is not successful until its credential-free audit record is sealed. A traffic burst can never cost you a compliance record.
Frequently asked questions
What is an AI sandbox?+
Why do AI agents need sandboxing?+
How is this different from running agents in a container or process sandbox?+
What happens if isolation can't be proven?+
Can a vendor integration widen the sandbox's network access?+
Does the model ever see real credentials?+
Does the AI sandbox work in sovereign and air-gapped deployments?+
Explore the platform
Email us
Prefer to write? Email hello [at] scrydon.com and we will get back to you.
Partners
