Isolation Policy Operations

platform.isolation_policy is the organization control for the execution fabric. Only an organization owner or admin can write it. Workflows, integrations, and service accounts cannot select a tier or change the policy.

Policy shape

type IsolationPolicy = {
  requireIsolatedExecution?: boolean
}

Absent or true means executable workloads require microvm. false permits the product resolver to fall back to a ready deployed managed_process backend when MicroVM is unavailable. It does not force managed process or deploy a backend.

Older rows may contain isolateUntrusted, requireTrueVm, or fallback. Scrydon reads those fields during rolling upgrades, but they no longer select a product execution tier. Saving the Compute settings page rewrites the row to the canonical shape above.

Create or update

Use Settings → Platform → Compute, or the authenticated Better Auth client from an owner/admin session:

const result = await authClient.organization.policy.update({
  organizationId,
  key: 'platform.isolation_policy',
  value: { requireIsolatedExecution: false },
})

if (result.error) throw result.error

Writes are session-only. There is no workflow, API-key, or service-to-service mutation path, so an execution service cannot change the policy that governs its own placement.

Inspect

const result = await authClient.organization.policy.get({
  organizationId,
  key: 'platform.isolation_policy',
})

if (result.error) throw result.error
console.log(result.data?.value ?? {})
console.log(result.data?.lastModifiedBy, result.data?.updatedAt)

get returns the stored organization value, not the effective deployment and readiness decision. Confirm the matching isolation.policy.updated event after each change; the write may succeed even if event delivery later fails.

Restore the fail-closed default

Write either { requireIsolatedExecution: true } or {}. An empty policy means the default requirement is active.

await authClient.organization.policy.update({
  organizationId,
  key: 'platform.isolation_policy',
  value: {},
})

Do not delete or edit the database row directly. That bypasses authorization and the policy lifecycle event.

Change procedure

1. Record the current organization row, deployed backends, backend readiness, and change ticket.
2. Confirm the intended workload profiles are ready on every tier the deployment may select.
3. Change the policy from an owner/admin session and retain lastModifiedBy and updatedAt.
4. Run canaries for Agent, Function/vendor implementation, and notebook jobs.
5. Test the negative case. With the requirement enabled, an unavailable microVM must refuse even when the managed actor is healthy. With relaxation enabled, an unavailable actor profile must also refuse rather than run in a product service.
6. Roll back by restoring the captured value or writing {}.

Backend deployment and IaC

Backend deployment belongs in Helm/GitOps:

executionFabric:
  managedProcess:
    enabled: true

runtimePlane:
  enabled: true

Operators can deploy microVM, managed process, or both. Product order is fixed: MicroVM first, then managed process only for an organization that permits it. If an organization requires isolation and MicroVM is unavailable, execution refuses even when the managed backend is ready.

The organization write endpoint requires a user session, so unattended Terraform/GitOps reconciliation of organization rows is not supported. Do not automate it with stored browser cookies or direct database writes.

Scope limits

The policy is organization-scoped. It does not support workspace bindings, scheduled activation, approval workflows, or per-block exceptions. A manifest may require microvm for its own capability, but cannot relax the organization floor.