The Security Model Behind Runtime Rules

A runtime rule is generated code that runs against your codebase. That's a real thing to ask you to trust. It's the first question worth asking about runtime rules, so here's how Taskless earns it.

Trust matters at two moments: when a rule is written, and when it runs. Taskless handles them separately.

When a rule is written

Runtime rules are generated. A model writes the check.ts, and until it's proven, Taskless treats it as untrusted code. So we run it inside a locked-down sandbox.

That sandbox has no network access and no secrets. It holds the fixtures the check is tested against and nothing else. In the worst case, where the model wrote something it shouldn't have, there's nothing on that box to take and nowhere to send it. Output leaves one way: the container writes to its filesystem, and the service reads the result back. No outbound connections, no callbacks, no path out.

Inside the sandbox, the check has to prove itself. Taskless runs it against fixtures and confirms it does what the rule intended. Only then is it signed. That signature carries the trust forward.

We wrote up how this sandbox is built on Cloudflare Containers, including the parts that took a while to get right: What we learned building safe code execution on Cloudflare.

When a rule runs

The signature is what your machine checks. Verifying a rule means confirming it's one Taskless generated and signed, unchanged. taskless check reconciles the runtime rules in your repo against the Taskless service and runs only the ones it's verified. A rule it can't verify is skipped and reported, never run.

That leaves a few clear states:

Logged in: verifies each runtime rule against the service and runs the ones that pass. The default.

Offline: runtime rules don't run unless you pass --dangerously-run-scripts. The flag is named the way it is on purpose.

In CI: a token lets Taskless verify every rule and run exactly the set it blessed.

The trust boundary

Today's model is verification. It doesn't isolate a rule while it runs. A verified runtime rule runs as ordinary code on your machine, against your repo.

That's the same trust you already extend to eslint, prettier, and every other dev tool: code you didn't write, running on your machine, against a repo you own. Taskless adds a verification step those tools don't have.

The case Taskless doesn't cover yet is running against someone else's untrusted repo under hardened isolation: single-use environments, default-deny egress, no reachable credentials. That's on the roadmap, and it gets its own post when it's ready.

The short version

A runtime rule is proven against fixtures in a sandbox with nothing to steal, then signed. Your machine runs only what it can verify.

Read more about how Taskless handles runtime rule security in the docs.