Untrusted Step Isolation

Scrydon's current Runtime Plane product path is the standard Agent block. Under the shipped Kata-first policy, one Agent block runs its complete bounded model/tool session in one fresh, single-use Kata exec pod. A deployment may explicitly opt into the weaker hardened tier, but that profile is not a Kata or true-VM claim.

What runs in the Agent pod

The Agent owns one ephemeral /workdir for its complete bounded session. Its built-in guest-local tools are:

• run_shell;
• read_file;
• write_file; and
• list_dir.

The image includes common command-line tools such as Git, curl, ripgrep, jq, Node.js, npm, Python, make, and archive/file utilities. A sequence such as clone → install → build → test observes the same filesystem.

Structured-output correction also stays in this same session. It does not allocate a second pod for one Agent block.

The pod and filesystem are destroyed after the block completes. Files do not persist into another block, workflow execution, or conversation turn.

What can call back to the platform

The Agent receives one short-lived root callback capability. It allows exactly:

• LLM completion; and
• credential-free web search.

Every selected platform or integration tool other than web search is rejected before the exec payload is built or a pod is submitted. The visible error is AGENT_PLATFORM_TOOL_UNSUPPORTED.

If the callback is not configured, execution stops before submission with AGENT_CALLBACK_UNAVAILABLE.

There is no per-tool action grant, connection reference, host-side action broker, or credential broker in this release. Provider API keys and OAuth tokens never enter the pod.

Network access

Git, npm, curl, Python package managers, and other guest-local commands use the pod network. Network access is still governed by the immutable organization egress snapshot and the trusted runtime enforcer.

Installing a client does not grant egress. Every repository, registry, package, or dependency host must be permitted by organization policy.

The control plane adds only the platform-owned callback transport host. Workflow input, model output, and shell commands cannot widen the snapshot.

Isolation and lifecycle

The platform—not the workflow author or integration—owns the isolation decision.

For the standard Agent path:

1. Agentic resolves the organization isolation and egress policy.
2. It validates that callback configuration is present.
3. It preflights all selected tools.
4. It builds one credential-free agent_turn envelope.
5. The Rust Runtime Plane authenticates the caller and provisions one exec pod at the resolved tier; the shipped default admits only a qualified Kata tier.
6. The runner executes the bounded model/tool loop in one /workdir.
7. The runtime records terminal status and tears the pod down.
8. The root callback grant is revoked; its TTL remains the final bound if revocation cannot be confirmed.

There is no workflow-author setting that turns this Agent back into host execution.

Credential boundary

The Agent pod has:

• no Dapr sidecar or mesh identity;
• no Kubernetes ServiceAccount token;
• no provider API key or OAuth token;
• no host, cloud, or source-control environment;
• no per-tool action grant; and
• one exec-scoped root callback bearer with a strict route allowlist, request/byte budgets, expiry, registration, and revocation.

Shell children receive an explicit credential-free environment. The per-pod transport token is removed from the runner environment before arbitrary commands execute.

Deferred runtime-plane surfaces

The following are intentionally not runner units in this release:

The Rust plane's opaque exec transport is not, by itself, proof that any deferred product surface has adopted it. Each future adopter needs its own producer, canonical runner schema, credential and egress contract, and end-to-end evidence.

Operational requirements

Deployment support

A deployment must provide:

• a Kata/KVM-capable node and the expected kata-vm-isolation RuntimeClass;
• immutable runner and enforcer images;
• the Agentic-to-plane authenticated control path;
• callback URL and secret configuration;
• organization isolation and egress policies; and
• network enforcement for the workload namespace.

If those requirements cannot be satisfied, the Agent fails closed rather than moving the session to the application host.

For deployment and tier details, see the deployment documentation.