Executable Workload Isolation
How Scrydon selects microVM or managed-process execution for Agent turns, functions, integration implementations, and notebook jobs.
Scrydon uses one execution fabric for executable workloads. A workload is bound to exactly one tier before it starts:
| Tier | What it provides |
|---|---|
microvm | A fresh workload with a dedicated guest kernel through the authenticated Runtime Plane. This is the isolated tier. |
managed_process | A fresh child process tree owned by a Dapr actor. It scales horizontally through Dapr placement, but shares the actor-host pod kernel and is therefore weaker than a microVM. |
There is no in-process fallback inside Agentic, API Platform, or Analytics, and an execution never changes tier after it has started.
Who controls the tier
Deployment operators choose which backends exist by deploying the Runtime Plane
and/or the managed actor host. Scrydon always prefers microvm. An organization
administrator controls Require isolated execution in
Settings → Platform → Compute:
- On or unset: only
microvmis eligible. If it is unavailable, the workload is refused. - Off:
microvmremains first; Scrydon may fall back tomanaged_processwhen its actor profile is ready.
An integration or capability can require microvm regardless of the
organization relaxation. Organization settings cannot make an undeployed or
unready backend available.
Managed process is an explicit relaxation, not another name for VM isolation. It gives every invocation a fresh process and workspace, but it shares the host kernel and pod identity with the actor host.
What runs where
The same platform-owned runners are used in both tiers:
- Agent turns use the bounded Agent bundle runner.
- Function blocks use the QuickJS profile in the vendor bundle runner.
- Vendor integration implementations use the vendor bundle runner and trusted egress broker.
- Notebook jobs use the Marimo job runtime and storage broker.
The execution tier changes placement and lifecycle ownership; it does not create a second implementation of the Agent, Function, integration, or notebook protocol.
Agent workspace and tools
One Agent turn owns one ephemeral /workdir for its complete bounded session.
Guest-local tools include shell execution and file read/write/list operations.
Common Git, curl, ripgrep, jq, Node.js, npm, Python, make, and archive utilities
are available in the runner image.
The workspace is destroyed after the turn. It does not persist into another block, workflow run, or conversation turn.
Tools this Agent cannot run
Not every integration tool can run inside an isolated Agent turn. When one is selected but unavailable here, the turn is refused before the model is called.
The refusal names affected tools using only their human-readable display labels; it never includes a scoped internal tool ID or organization UUID. Remove every unsupported selection from the Agent block, then run the workflow again. An integration enabled in Settings is not automatically available inside this isolated Agent.
Credentials and platform calls
Executable workloads do not receive reusable provider, OAuth, database, Dapr, or Kubernetes credentials.
- Agent calls use short-lived root and per-action grants.
- Function source receives no credential or egress grant.
- Vendor runner code receives invocation grants and a private broker socket; only the trusted broker receives the opaque credential grant.
- Notebook code receives execution-scoped storage capabilities through its broker.
Every grant is bound to the organization, workspace, execution, plan, operation, budgets, and expiry. The platform revokes it at terminal cleanup; its TTL remains the final bound if revocation cannot be confirmed.
Network access
Installing a network client does not grant network access. MicroVM workloads use the Runtime Plane egress wall. Managed vendor implementations route through the same trusted vendor broker contract. The organization egress snapshot and deployment-blocked networks remain authoritative.
Failure behavior
Selection checks deployed backends, the organization requirement, capability minimums, backend authentication, and workload-profile readiness before dispatch. Product order is MicroVM first, then managed process only when the organization permits it.
- If the organization requires isolation and MicroVM is not ready, execution is refused.
- If relaxation is allowed but the managed actor profile is unavailable, execution is refused.
- If a selected runner fails, the attempt fails on that tier. Scrydon does not retry it on a weaker backend.
- If the actor host restarts while a child is running, the result is reported as recovery-uncertain; arbitrary code is not silently replayed.
Deployment support
| Deployment target | Strongest supported boundary | Qualification requirement |
|---|---|---|
| AKS with Pod Sandboxing | microvm | Managed Kata node pool, matching Ready node, and exact-candidate proof |
| Self-managed Kubernetes or k3s on Linux/KVM | microvm | Kata/QEMU RuntimeClass, KVM, enforcing CNI, and native-node proof |
| Generic Kubernetes without Kata/KVM | managed_process | Dapr actor state, authenticated channels, fresh-child teardown, and workload smoke |
| EKS, GKE, OpenShift, and other managed Kubernetes | managed_process | Managed-process qualification; separate provider proof is required for microVM |
| Official Azure Marketplace offer | managed_process | Managed actor image and profile smoke |
| Official air-gapped Kubernetes package | microvm | Import pinned images and prove the complete offline Kata path |
| Docker Compose, Docker Desktop, and native macOS | managed_process | Local Dapr actor readiness and fresh-child smoke |
For local development:
bun run dev:allstarts the managed-process actor host and does not require KVM, Rust Runtime Plane, or Apple Container guests.bun run dev:all --mode=isolatedruns microVM-only development and starts the Runtime Plane path.
For Helm values and production qualification, see the deployment documentation.