Script and Module Safety

WOML scripts are trusted project code, not a hostile multi-tenant sandbox.

Worker isolation

Each invocation runs in an isolated Bun worker under Rust supervision for timeout, cancellation, output limits, and crash classification. Isolation prevents accidental shared script state; it is not permission-safe execution for untrusted tenants.

Network and filesystem

Native Fetch and managed HTTP are not SSRF sandboxes. Bun imports may access capabilities available to the runtime account. Run WOML with least-privileged OS, network, filesystem, database, and provider credentials.

Local modules must stay inside the project and use static relative imports. Review imported code with the same care as workflow scripts.

Run with least privilege

The WOML process should have only the filesystem, network, database, and provider permissions required by its workflows. Do not run the runtime as root merely because one script needs to write a report.

Use operating-system ownership, container boundaries, network egress rules, database roles, and provider scopes as real security controls. Worker isolation improves fault containment but does not replace those controls.

Treat dynamic destinations carefully

Validate hosts before passing user-controlled URLs to Fetch or managed HTTP. The local profile permits reachable private and loopback addresses and is not an SSRF sandbox.

Validate filesystem paths before using Bun APIs. WOML constrains module source paths, but arbitrary script code can still use permissions available to the runtime account.

Review dependencies as code

Local module packaging is deterministic and project-bounded. It does not make copied third-party source trustworthy. Review licensing, update strategy, transitive behavior, and initialization side effects before including external code.

Do not execute untrusted user-generated JavaScript in a shared WOML runtime. WOML v1 is designed for trusted workflow projects.