Runtime boundary enforcement

Most workflow engines trust the host environment to enforce boundaries. That works fine when you control the host. It's a liability when you don't.

Opscotch's runtime treats the host as adversarial. It enforces the workflow's declared contract from inside, regardless of how the host is configured or what privileges the executing process has.

What the boundary enforces

• Declared inputs — the workflow can only consume inputs of the types and shapes it declared. Anything else is refused.
• Declared outputs — same, in reverse. The runtime won't write to anything outside the declared output surface.
• Declared side effects — network calls, file system writes, subprocess execution — all of it is gated by what the manifest declares. The runtime refuses to perform side effects outside that list.
• Commercial entitlements — runtime-enforced, not config-file-enforced. Customers can't grant themselves higher plans by editing configuration.

Why this is harder to bypass than typical sandboxing

Sandboxing typically relies on the OS or a hypervisor. Both can be misconfigured or patched. Opscotch's boundary enforcement lives inside the runtime binary itself. The customer would have to actually patch the binary — and any subsequent signed package would refuse to run because the binary hash doesn't match.

What this means for your customers

They get provable guarantees about what your workflow can and can't do on their systems. This matters for security-conscious customers, regulated industries, and anyone who's been burned by a vendor overstepping their bounds.

What this means for you

You don't have to write a separate compliance document promising "we won't access X" — the runtime literally can't, regardless of how it's configured. That conversation with your customer's security team gets shorter.